Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Amazon EC2 untuk SQL Server
Amazon EC2 mendukung database SQL Server yang dikelola sendiri. Artinya, ini memberi Anda kontrol penuh atas pengaturan infrastruktur dan lingkungan database. Menjalankan database di Amazon EC2 sangat mirip dengan menjalankan database di server Anda sendiri. Anda memiliki kontrol penuh atas database dan akses tingkat sistem operasi, sehingga Anda dapat menggunakan alat pilihan Anda untuk mengelola sistem operasi, perangkat lunak database, tambalan, replikasi data, pencadangan, dan pemulihan. Opsi migrasi ini mengharuskan Anda menyiapkan, mengonfigurasi, mengelola, dan menyetel semua komponen, termasuk instans EC2, volume penyimpanan, skalabilitas, jaringan, dan keamanan, berdasarkan praktik terbaik AWS arsitektur. Anda bertanggung jawab atas replikasi dan pemulihan data di seluruh instans Anda di Wilayah yang sama atau berbeda AWS .
## Kapan memilih Amazon EC2
Amazon EC2 adalah opsi migrasi yang baik untuk database SQL Server Anda saat:
+ Anda memerlukan kontrol penuh atas database dan akses ke sistem operasi yang mendasarinya, instalasi database, dan konfigurasi.
+ Anda ingin mengelola database Anda, termasuk backup dan recovery, patch sistem operasi dan database, tuning sistem operasi dan parameter database, mengelola keamanan, dan mengkonfigurasi ketersediaan tinggi atau replikasi.
+ Anda ingin menggunakan fitur dan opsi yang saat ini tidak didukung oleh Amazon RDS. Untuk detailnya, lihat [Fitur yang tidak didukung dan fitur dengan dukungan terbatas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport) dalam dokumentasi Amazon RDS.
+ Anda memerlukan versi SQL Server tertentu yang tidak didukung oleh Amazon RDS. Untuk daftar versi dan edisi yang didukung, lihat [versi SQL Server di Amazon RDS dalam dokumentasi Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport).
+ Ukuran database dan kebutuhan kinerja Anda melebihi penawaran Amazon RDS for SQL Server saat ini. Untuk detailnya, lihat [Penyimpanan instans Amazon RDS DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) dalam dokumentasi Amazon RDS.
+ Anda ingin menghindari patch perangkat lunak otomatis yang mungkin tidak sesuai dengan aplikasi Anda.
+ Anda ingin membawa lisensi Anda sendiri alih-alih menggunakan Amazon RDS for SQL Server model yang disertakan lisensi.
+ Anda ingin mencapai IOPS dan kapasitas penyimpanan yang lebih tinggi daripada batas saat ini. Untuk detailnya, lihat [Penyimpanan instans Amazon RDS DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) dalam dokumentasi Amazon RDS.
Untuk daftar fitur dan versi SQL Server yang saat ini didukung di Amazon EC2, [lihat Memilih antara Amazon EC2 dan Amazon](comparison.md) RDS nanti dalam panduan ini.
# Ketersediaan tinggi
Anda dapat menggunakan teknologi replikasi yang didukung SQL Server dengan database SQL Server Anda di Amazon EC2 untuk mencapai ketersediaan tinggi, perlindungan data, dan pemulihan bencana. Beberapa solusi umum adalah pengiriman log, pencerminan basis data, grup ketersediaan Always On, dan Instans Cluster Always On Failover.
Diagram berikut menunjukkan bagaimana Anda dapat menggunakan SQL Server di Amazon EC2 di beberapa Availability Zone dalam satu AWS Region. Database utama adalah database baca-tulis, dan database sekunder dikonfigurasi dengan pengiriman log, pencerminan database, atau grup ketersediaan Always On untuk ketersediaan tinggi. Semua data transaksi dari database utama ditransfer dan dapat diterapkan ke database sekunder secara asinkron untuk pengiriman log, dan secara asinkron untuk grup ketersediaan Always On dan mirroring.
![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png)
# Pengiriman log
Pengiriman log memungkinkan Anda secara otomatis mengirim cadangan log transaksi dari instance database utama ke satu atau lebih database sekunder (juga dikenal sebagai *siaga hangat) pada instans DB* terpisah. Pengiriman log menggunakan pekerjaan SQL Server Agent untuk mengotomatiskan proses pencadangan, penyalinan, dan penerapan cadangan log transaksi. Meskipun pengiriman log biasanya dianggap sebagai fitur pemulihan bencana, itu juga dapat memberikan ketersediaan tinggi dengan memungkinkan instans DB sekunder untuk dipromosikan jika instans DB primer gagal. Jika RTO dan RPO Anda fleksibel, atau database Anda tidak dianggap sangat penting, pertimbangkan untuk menggunakan pengiriman log untuk menyediakan ketersediaan yang lebih baik untuk database SQL Server Anda.
Pengiriman log meningkatkan ketersediaan database dengan menyediakan akses ke database sekunder untuk digunakan sebagai salinan read-only dari database utama bila diperlukan. Anda dapat mengonfigurasi penundaan jeda (waktu tunda yang lebih lama) di mana Anda dapat memulihkan data yang diubah secara tidak sengaja pada database utama sebelum perubahan ini dikirim ke database sekunder.
Sebaiknya jalankan instans DB primer dan sekunder di Availability Zone terpisah, dan menerapkan instance monitor untuk melacak semua detail pengiriman log. Pencadangan, salin, pemulihan, dan peristiwa kegagalan untuk grup pengiriman log tersedia dari instance monitor. Konfigurasi pengiriman log tidak secara otomatis gagal dari server utama ke server sekunder. Namun, salah satu database sekunder dapat dibawa online secara manual jika database utama menjadi tidak tersedia.
Pengiriman log sering digunakan sebagai solusi pemulihan bencana tetapi juga dapat digunakan sebagai solusi ketersediaan tinggi, tergantung pada kebutuhan aplikasi Anda. Gunakan pengiriman log saat:
+ Anda memiliki persyaratan RTO dan RPO yang fleksibel. Pengiriman log menyediakan RPO menit, dan RTO menit hingga jam.
+ Anda tidak memerlukan failover otomatis ke database sekunder.
+ Anda ingin membaca dari database sekunder, tetapi Anda tidak memerlukan keterbacaan selama operasi pemulihan.
Untuk informasi selengkapnya tentang pengiriman log, lihat [dokumentasi Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server).
# Pencerminan basis data
Pencerminan database mengambil database yang ada pada instance EC2 dan menyediakan salinan read-only (mirror) yang lengkap atau hampir lengkap pada instance DB terpisah. Amazon RDS menggunakan mirroring database untuk memberikan dukungan Multi-AZ untuk Amazon RDS for SQL Server. Fitur ini meningkatkan ketersediaan dan perlindungan database, dan menyediakan mekanisme untuk menjaga database tetap tersedia selama peningkatan.
**catatan**
Menurut [dokumentasi Microsoft](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server), mirroring database akan dihapus dalam versi SQL Server yang akan datang. Anda harus berencana untuk menggunakan grup ketersediaan Always On sebagai gantinya.
Dalam mirroring database, server SQL dapat mengambil salah satu dari tiga peran:
+ Server utama, yang meng-host read/write versi utama database.
+ Server cermin, yang menampung salinan database utama.
+ Server saksi opsional. Server ini hanya tersedia dalam mode keamanan tinggi. Ini memonitor keadaan cermin database dan mengotomatiskan failover dari database utama ke database mirror.
Sesi mirroring dibuat antara server utama dan server cermin. Selama mirroring, semua perubahan database yang dilakukan dalam database utama juga dilakukan pada database mirror. Pencerminan basis data dapat berupa operasi sinkron atau asinkron. Ini ditentukan oleh dua mode operasi mirroring: mode keamanan tinggi dan mode kinerja tinggi.
+ **Mode keamanan tinggi: Mode** ini menggunakan operasi sinkron. Dalam mode ini, sesi pencerminan database menyinkronkan operasi penyisipan, pembaruan, dan penghapusan dari database utama ke database cermin secepat mungkin. Segera setelah database disinkronkan, transaksi dilakukan di database prinsipal dan cermin. Kami menyarankan Anda menggunakan mode operasi ini ketika database cermin berada di Availability Zone yang sama atau berbeda, tetapi dihosting dalam AWS Wilayah yang sama.
+ **Mode kinerja tinggi: Mode** ini menggunakan operasi asinkron. Dalam mode ini, sesi pencerminan database menyinkronkan operasi penyisipan, pembaruan, dan penghapusan dari database utama ke database cermin, tetapi mungkin ada jeda antara waktu database utama melakukan transaksi dan waktu database mirror melakukan transaksi. Kami menyarankan Anda menggunakan mode ini ketika database cermin berada di AWS Wilayah yang berbeda.
Gunakan pencerminan basis data saat:
+ Anda memiliki persyaratan RTO dan RPO yang ketat, dan tidak dapat memiliki penundaan antara database primer dan sekunder. Pencerminan basis data menyediakan RPO nol detik (dengan komit sinkron) dan RTO detik hingga menit.
+ Anda tidak memiliki persyaratan untuk membaca dari database sekunder.
+ Anda ingin melakukan failover otomatis ketika Anda memiliki server saksi yang dikonfigurasi dalam mode sinkronisasi.
+ Anda tidak dapat menggunakan grup ketersediaan Selalu Aktif, yang merupakan opsi yang lebih disukai.
Pembatasan:
+ Hanya one-to-one failover yang didukung. Anda tidak dapat memiliki beberapa tujuan database yang disinkronkan dengan database utama.
Untuk informasi selengkapnya tentang mirroring, lihat dokumentasi [Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server).
# Selalu Aktif pada grup ketersediaan
Grup ketersediaan SQL Server Always On menyediakan ketersediaan tinggi dan solusi pemulihan bencana untuk database SQL Server. Grup ketersediaan terdiri dari satu set database pengguna yang gagal bersama-sama. Ini mencakup satu set read/write database primer dan beberapa (satu hingga delapan) set database sekunder terkait. Anda dapat membuat database sekunder tersedia untuk tingkat aplikasi sebagai salinan hanya-baca dari database utama (edisi SQL Server Enterprise saja), untuk menyediakan arsitektur scale-out untuk beban kerja baca. Anda juga dapat menggunakan database sekunder untuk operasi pencadangan.
Grup ketersediaan SQL Server Always On mendukung mode komit sinkron dan asinkron. Dalam mode sinkron, replika utama melakukan transaksi database setelah perubahan dilakukan atau ditulis ke log replika sekunder. Dengan menggunakan mode ini, Anda dapat melakukan failover manual yang direncanakan dan failover otomatis jika replika disinkronkan. Anda dapat menggunakan mode komit sinkron antara instance SQL Server dalam lingkungan yang sama (misalnya, jika semua instance berada di lokasi atau semua instance berada di). AWS
Dalam mode komit asinkron, replika utama melakukan transaksi database tanpa menunggu replika sekunder. Anda dapat menggunakan mode komit asinkron antara instance SQL Server yang berada di lingkungan yang berbeda (misalnya, jika Anda memiliki instance di tempat dan di). AWS
Anda dapat menggunakan grup ketersediaan Selalu Aktif untuk ketersediaan tinggi atau pemulihan bencana. Gunakan metode ini ketika:
+ Anda memiliki persyaratan RTO dan RPO yang ketat. Grup ketersediaan Selalu Aktif menyediakan RPO detik, dan RTO detik hingga menit.
+ Anda ingin mengelola dan gagal melalui sekelompok database. Grup ketersediaan Selalu Aktif mendukung 0-4 replika sekunder dalam mode komit sinkron untuk SQL Server 2019.
+ Anda ingin menggunakan failover otomatis dalam mode komit sinkron, dan Anda tidak memerlukan server saksi.
+ Anda ingin membaca dari database sekunder.
+ Anda ingin menyinkronkan beberapa tujuan database dengan database utama Anda.
Dimulai dengan SQL Server 2016 SP1, edisi Standar SQL Server menyediakan ketersediaan tinggi dasar untuk database sekunder tunggal yang tidak dapat dibaca dan pendengar per grup ketersediaan. Ini juga mendukung maksimal dua node per grup ketersediaan.
# Selalu Pada Instans Failover Cluster
SQL Server Always On Failover Cluster Instances (FCIs) menggunakan Windows Server Failover Clustering (WSFC) untuk menyediakan ketersediaan tinggi di tingkat instans server. FCI adalah contoh tunggal SQL Server yang diinstal di seluruh node WSFC untuk menyediakan ketersediaan tinggi untuk seluruh instalasi SQL Server. Jika node yang mendasari mengalami kegagalan perangkat keras, sistem operasi, aplikasi, atau layanan, semua yang ada di dalam instance SQL Server dipindahkan ke node WSFC lain. Ini termasuk database sistem, login SQL Server, pekerjaan Agen SQL Server, dan sertifikat.
FCI umumnya lebih disukai daripada grup ketersediaan Selalu Aktif ketika:
+ Anda menggunakan edisi Standar SQL Server bukan edisi Enterprise.
+ Anda memiliki sejumlah besar database kecil per instance.
+ Anda terus-menerus memodifikasi objek tingkat instance seperti pekerjaan SQL Server Agent, login, dan sebagainya.
Ada empat opsi untuk menerapkan FCIs pada AWS:
+ Amazon EBS Multi-Lampirkan dengan reservasi persisten
+ Amazon FSx untuk Server File Windows
+ Amazon FSx untuk NetApp ONTAP
+ Solusi dari AWS Mitra
## Menggunakan Amazon EBS Multi-Attach dengan reservasi persisten
[Amazon EBS Multi-Attach dengan NVMe reservasi](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html) mendukung pembuatan SQL Server dengan `io2` volume FCIs Amazon EBS sebagai penyimpanan bersama pada cluster failover Windows Server. Fitur ini menyederhanakan proses penyiapan kluster failover dengan memungkinkan Anda membuat klaster failover dengan menggunakan volume Amazon EBS. `io2` Volume ini hanya dapat dilampirkan ke instance yang berada di Availability Zone yang sama. Untuk menyebarkan cluster failover Windows Server dengan menggunakan `io2` volume Amazon EBS, Anda harus menggunakan driver terbaru. AWS NVMe
Volume Amazon EBS dan volume penyimpanan instans diekspos sebagai perangkat NVMe blok pada instans [berbasis Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances). Anda harus menginstal [AWS NVMe driver](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html) dengan [fitur reservasi persisten SCSI](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations) yang dikonfigurasi saat Anda menggunakan `io2` volume Amazon EBS untuk membentuk WSFC dan SQL Server. FCIs
Untuk informasi selengkapnya tentang fitur ini, lihat posting AWS blog [Cara menerapkan cluster failover SQL Server dengan Amazon EBS Multi-Attach](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/) di Windows Server.
## Menggunakan Amazon FSx untuk Windows File Server
[Amazon FSx untuk Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) menyediakan penyimpanan file bersama yang dikelola sepenuhnya. Ini secara otomatis mereplikasi penyimpanan secara sinkron di dua Availability Zone untuk memberikan ketersediaan tinggi. Menggunakan FSx for Windows File Server untuk penyimpanan file membantu menyederhanakan dan mengoptimalkan penerapan ketersediaan tinggi SQL Server di Amazon EC2.
Dengan Microsoft SQL Server, ketersediaan tinggi biasanya digunakan di beberapa node database dalam WSFC, dan setiap node memiliki akses ke penyimpanan file bersama. Anda dapat menggunakan FSx untuk Windows File Server sebagai penyimpanan bersama untuk penyebaran ketersediaan tinggi SQL Server dalam dua cara: sebagai penyimpanan untuk file data aktif dan sebagai saksi berbagi file SMB.
Untuk informasi tentang bagaimana Anda dapat mengurangi kompleksitas dan biaya menjalankan penerapan SQL Server FCI dengan menggunakan FSx untuk Windows File Server, lihat posting blog Menyederhanakan [penerapan ketersediaan tinggi Microsoft SQL Server Anda](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) menggunakan Amazon untuk Windows File Server. FSx Posting blog juga memberikan step-by-step instruksi untuk menyebarkan SQL Server FCIs dengan menggunakan sistem file Amazon FSx Multi-AZ sebagai solusi penyimpanan bersama. Untuk informasi selengkapnya, lihat dokumentasi [Amazon FSx untuk Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html).
## Menggunakan Amazon FSx untuk NetApp ONTAP
Amazon FSx untuk NetApp ONTAP adalah layanan terkelola penuh yang menyediakan penyimpanan file yang sangat andal, terukur, berkinerja tinggi, dan kaya fitur yang dibangun di atas sistem file ONTAP. NetApp FSx untuk ONTAP menggabungkan fitur, kinerja, kemampuan, dan operasi API sistem NetApp file yang sudah dikenal dengan kelincahan, skalabilitas, dan kesederhanaan layanan yang dikelola sepenuhnya. AWS
FSx untuk ONTAP menyediakan akses multi-protokol ke data melalui protokol NFS, SMB, dan iSCSI untuk sistem Windows dan Linux. Anda dapat membangun arsitektur SQL Server Always On FCI yang sangat tersedia, seperti yang dijelaskan secara rinci dalam posting blog [SQL Server High Availability Deployment Menggunakan](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/) Amazon untuk ONTAP. FSx NetApp FSx untuk ONTAP juga dapat menyediakan cara cepat untuk gagal di lingkungan SQL Server Anda ke yang berbeda Wilayah AWS untuk memenuhi persyaratan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). Untuk informasi lebih lanjut, lihat posting blog [Menerapkan HA dan DR untuk SQL Server Always-On Failover Cluster Instance](https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/) menggunakan ONTAP. FSx
Anda juga dapat menggunakan AWS Launch Wizard untuk menerapkan solusi SQL Server AWS, dengan dukungan untuk Always On Availability Groups dan single-node deployment. Launch Wizard mendukung penerapan SQL Server Always on FCI di Amazon EC2 dengan ONTAP sebagai FSx penyimpanan bersama. Layanan ini menghemat waktu dan tenaga Anda dengan mengganti proses penerapan manual yang kompleks dengan panduan berbasis konsol terpandu yang mempercepat migrasi beban kerja SQL Server lokal yang bergantung pada penyimpanan bersama. Untuk informasi selengkapnya tentang bagaimana Launch Wizard dapat membantu Anda menyediakan dan mengkonfigurasi SQL Server FCIs dalam hitungan jam, lihat posting blog [Sederhanakan SQL Server Always On deployment with](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/) dan Amazon. AWS Launch Wizard FSx Launch Wizard juga mendukung penerapan untuk SQL Server Always FCIs On dengan menggunakan [Amazon FSx untuk Windows File Server](https://aws.amazon.com/fsx/windows/) sebagai solusi penyimpanan bersama.
## Menggunakan solusi dari AWS Mitra
+ [SIOS DataKeeper](https://us.sios.com/) menyediakan dukungan failover cluster ketersediaan tinggi di seluruh Wilayah AWS dan Availability Zones. SIOS DataKeeper tersedia di [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=3c91e2f7-fc8d-4cce-a8aa-1e37abcb4408).
+ [DxEnterprise](https://dh2i.com/dxenterprise-high-availability/)from DH2i mengaktifkan failover otomatis dari Grup Ketersediaan SQL Server di Kubernetes dan failover instance terpadu untuk Windows dan Linux. D2HI tersedia di. [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b)
# FSx untuk Windows File Server
FSx untuk Windows File Server menyediakan penyimpanan file yang dikelola sepenuhnya, sangat andal, dan dapat diskalakan yang dapat diakses dengan menggunakan protokol Server Message Block (SMB). Ini dibangun di atas Windows Server dan memberikan berbagai fitur administratif seperti kuota pengguna, pemulihan file pengguna akhir, dan integrasi Microsoft Active Directory (AD). Ini menawarkan opsi penyebaran Single-AZ dan multi-AZ, pencadangan yang dikelola sepenuhnya, dan enkripsi data saat istirahat dan dalam perjalanan. Anda dapat mengoptimalkan biaya dan kinerja untuk beban kerja Anda dengan opsi penyimpanan solid-state drive (SSD) dan hard disk drive (HDD), dan Anda dapat menskalakan penyimpanan dan mengubah kinerja throughput sistem file Anda kapan saja. Penyimpanan FSx file Amazon dapat diakses dari Windows, instans komputasi Linux yang berjalan di AWS, dan di tempat.
Amazon FSx mempermudah penerapan penyimpanan Windows bersama untuk penyebaran SQL Server dengan ketersediaan tinggi melalui dukungannya untuk berbagi file (CA) yang tersedia secara terus menerus dan sistem file yang lebih kecil. Opsi ini cocok untuk kasus penggunaan ini:
+ Sebagai penyimpanan bersama yang digunakan oleh node SQL Server dalam instance WSFC.
+ Sebagai saksi berbagi file SMB yang dapat digunakan dengan cluster SQL Server apa pun dengan WSFC.
Amazon FSx memberikan kinerja cepat dengan throughput dasar hingga 2 GB/second per sistem file, ratusan ribu IOPS, dan latensi sub-milidetik yang konsisten.
Untuk memberikan kinerja yang tepat untuk instans SQL Anda, Anda dapat memilih tingkat throughput yang independen dari ukuran sistem file Anda. Tingkat kapasitas throughput yang lebih tinggi juga datang dengan tingkat IOPS yang lebih tinggi yang dapat disajikan oleh server file ke instance SQL Server yang mengaksesnya.
Kapasitas penyimpanan tidak hanya menentukan berapa banyak data yang dapat Anda simpan, tetapi juga berapa banyak IOPS yang dapat Anda lakukan pada penyimpanan. Setiap gigabyte penyimpanan menyediakan 3 IOPS. Anda dapat menyediakan setiap sistem file berukuran hingga 64 TB.
Untuk informasi tentang mengonfigurasi dan menggunakan Amazon FSx untuk mengurangi kompleksitas dan biaya penerapan ketersediaan tinggi SQL Server Anda, lihat Menyederhanakan [penerapan ketersediaan tinggi Microsoft SQL Server Anda menggunakan FSx ](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) Windows File Server di blog Penyimpanan. AWS Untuk mempelajari selengkapnya tentang membuat berbagi CA baru, lihat [dokumentasi FSx untuk Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share).
# Pemulihan bencana
Banyak organisasi menerapkan ketersediaan tinggi untuk database SQL Server mereka, tetapi itu tidak cukup untuk organisasi yang membutuhkan ketahanan TI sejati. Kami menyarankan Anda menerapkan solusi pemulihan bencana untuk menghindari kehilangan data dan downtime database mission-critical. Mengadopsi arsitektur pemulihan bencana Multi-wilayah untuk penerapan SQL Server Anda membantu Anda:
+ Mencapai kelangsungan bisnis
+ Tingkatkan latensi untuk basis pelanggan Anda yang didistribusikan secara geografis
+ Memenuhi persyaratan audit dan peraturan Anda
Opsi untuk pemulihan bencana termasuk [pengiriman log](ec2-log-shipping.md), [grup ketersediaan Selalu Aktif](ec2-always-on.md), [snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html) yang disimpan di Amazon S3 dan direplikasi di AWS seluruh Wilayah[, Instans Kluster Failover Selalu Aktif FCIs (](ec2-fci.md)) dikombinasikan dengan grup ketersediaan Selalu Aktif, dan grup ketersediaan terdistribusi.
## Grup ketersediaan terdistribusi
Arsitektur dengan grup ketersediaan terdistribusi adalah pendekatan optimal untuk penyebaran SQL Server Multi-wilayah. Grup ketersediaan terdistribusi adalah jenis grup ketersediaan khusus yang mencakup dua grup ketersediaan terpisah. Anda dapat menganggapnya sebagai grup ketersediaan grup ketersediaan. Grup ketersediaan yang mendasarinya dikonfigurasi pada dua cluster WSFC yang berbeda.
Grup ketersediaan terdistribusi digabungkan secara longgar, yang berarti bahwa mereka tidak memerlukan satu cluster WSFC dan dikelola oleh SQL Server. Karena cluster WSFC dipertahankan secara individual dan transmisi terutama tidak sinkron antara dua kelompok ketersediaan, lebih mudah untuk mengkonfigurasi pemulihan bencana di situs lain. Replika utama di setiap grup ketersediaan menyinkronkan replika sekunder mereka sendiri.
Grup ketersediaan terdistribusi hanya mendukung failover manual saat ini. Untuk memastikan bahwa tidak ada data yang hilang, hentikan semua transaksi pada database primer global (yaitu, pada database grup ketersediaan primer). Kemudian atur grup ketersediaan terdistribusi ke komit sinkron.