Apa yang terjadi? Berikut Azure Outage Post Mortem Bagian 2 kami

Posting blog saya sebelumnya mengatakan bahwa Cloud-to-Cloud atau Hybrid-Cloud akan memberi Anda isolasi paling banyak dari hampir semua masalah yang dihadapi CSP. Namun sebagian besar downtime yang disebabkan oleh bencana alam ini bisa dihindari jika Zona Ketersediaan tersedia di wilayah Tengah Selatan. Microsoft menerbitkan RCA Pendahuluan tentang Penghentian Tengah Selatan 4 September. Bagian terpenting dari keseluruhan ringkasan itu adalah sebagai berikut …

“MENGGUNAKAN REDUMSI DITETAPKAN, ADA SKENARIO DI DALAM KEKURANGAN PENDINGINAN DATACENTER DAPAT MENGAKTIFKAN PELATIH PELANGGAN DI DATACENTER YANG TERKENA.”

Apa Arti Itu Bagi Anda?

Jika semua aplikasi Anda berjalan di pusat data yang sama, Anda rentan terhadap jenis pemadaman yang sama di masa mendatang. Dalam pembelaan Microsoft, ini benar-benar tidak boleh menjadi berita untuk Anda. Ini selalu benar apakah Anda menjalankan di Azure, AWS, Google atau bahkan datacenter Anda sendiri. Kegagalan untuk merencanakan ke depan dengan replikasi data ke pusat data yang berbeda dan rencana untuk memulihkan aplikasi Anda dengan cepat hanyalah kurangnya perencanaan di pihak Anda. Microsoft tidak mempublikasikan lokasi Zona Ketersediaan yang tepat. Jika Anda yakin peta ini diterbitkan di sini, Anda bisa menebak bahwa mereka mungkin di mana saja dari 2-10 mil terpisah satu sama lain. Dalam semua kasus kecuali yang paling ekstrim, mereplikasi data di Zona Ketersediaan harus cukup untuk perlindungan data. Beberapa aplikasi seperti SQL Server telah dibangun dalam teknologi replikasi. Namun untuk berbagai aplikasi, sistem operasi dan tipe data, lakukan selidiki replikasi replikasi level blok SANless. Solusi cluster SANless secara tradisional telah digunakan untuk cluster multisite. Namun teknologi yang sama juga dapat digunakan di cloud di Zona Ketersediaan, Wilayah, atau Hybrid-Cloud untuk ketersediaan tinggi dan pemulihan bencana. Menerapkan cluster SANless yang membentang Zona Ketersediaan, baik itu Azure, AWS atau Google, adalah proses yang sangat sederhana yang diberikan alat yang tepat. Sebagai bagian dari post mortal pemusnahan biru, berikut adalah beberapa sumber daya untuk membantu Anda memulai. Langkah-demi-Langkah: Mengonfigurasi Cluster Server File di Azure yang Membagi Zona Ketersediaan Cara Membuat Server Instan SQL Server Failover Cluster di Google Cloud Platform MS SQL Server v.Berikutnya di Linux dengan Replikasi dan Ketersediaan Tinggi #Azure #Cloud #Linux Menyebarkan Microsoft SQL Server 2014 Failover Cluster di #Airure Resource Manager (ARM) SANless SQL Server Cluster di AWS SANless Linux Cluster di AWS Quick Start

Pelajaran Dari Azure Outage Post Mortem

Jika Anda berada di Azure, Anda mungkin juga ingin mempertimbangkan Azure Site Recovery (ASR). ASR memungkinkan Anda mereplikasi seluruh VM dari satu wilayah Azure ke wilayah lain. ASR akan mereplikasi VM Anda secara real-time dan memungkinkan Anda untuk melakukan tes DR yang tidak mengganggu kapan pun Anda suka. Mendukung sebagian besar versi Windows dan Linux dan relatif mudah untuk diatur. Anda juga dapat membuat pekerjaan replikasi yang memiliki “Multi-VM Consistency”. Ini berarti bahwa server harus dipulihkan dari titik waktu yang sama dapat digabungkan dalam grup konsistensi ini dan mereka akan memiliki titik pemulihan yang sama persis. Pada dasarnya, jika Anda membangun cluster SANless dengan DataKeeper di satu wilayah untuk ketersediaan tinggi, Anda memiliki dua opsi untuk DR. Salah satunya adalah Anda dapat memperpanjang cluster SANless Anda ke node di wilayah yang berbeda, atau Anda bisa menggunakan ASR untuk mereplikasi kedua node dalam kelompok konsistensi.

Apa bedanya?

Trade off dengan ASR adalah bahwa RPO dan RTO tidak sebaik yang akan Anda dapatkan dengan cluster multi-situs SANless. Meskipun mudah dikonfigurasi dan berfungsi hanya dengan aplikasi apa pun. Hati-hati. Jika aplikasi Anda melebihi 10 MBps dalam aktivitas penulisan disk secara rutin, ASR tidak akan dapat mengikuti. Juga, klaster berdasarkan Storage Spaces Direct tidak dapat direplikasi dengan ASR dan secara umum tidak memiliki strategi DR yang baik ketika digunakan di Azure. Untuk sementara setelah Managed Disks dirilis, ASR tidak sepenuhnya mendukung mereka hingga sekitar satu tahun kemudian. Dukungan penuh untuk Managed Disks adalah rintangan besar bagi banyak orang yang ingin menggunakan ASR. Untungnya sejak sekitar Februari 2018, ASR sepenuhnya mendukung Managed Disks. Namun, ada masalah lain yang baru saja diperkenalkan. Dengan diperkenalkannya Zona Ketersediaan, ASR sekali lagi tertangkap di belakang waktu. Mereka saat ini tidak mendukung VM yang telah diterapkan di Zona Ketersediaan.

Saya pergi ke depan dan mencobanya. Tampaknya mungkin untuk mengkonfigurasi replikasi dan saya bisa melakukan uji failover.

Saya menggunakan ASR untuk mereplikasi SQL1 dan SQL3 dari Central ke Timur US 2 dan melakukan uji failover. Selain tidak menempatkan VM dalam AZs di AS Timur 2 tampaknya berfungsi. [/ Caption] Saya berharap untuk mengetahui lebih lanjut tentang batasan ini di konferensi Ignite. Meskipun keterbatasan ini tidak sama pentingnya dengan Managed Disk. Karena Zona Ketersediaan belum tersedia secara luas. Jadi semoga ASR akan mengambil dukungan untuk Zona Ketersediaan karena wilayah lain menerangi Zona Ketersediaan dan mereka lebih banyak diadopsi.

Baca lebih lanjut tentang analisis saya tentang Pos Mortal Azure Outage yang direproduksi dengan izin dari Clusteringformeremortals.com

Langkah-Demi Langkah: Konfigurasikan Cluster Server File Di Azure Spanning Availability Zones

Dalam posting ini, kita akan detail langkah-langkah spesifik yang diperlukan untuk menyebarkan 2-node File Server Failover Cluster di Azure yang membentang Zona Ketersediaan baru. Saya akan menganggap Anda akrab dengan konsep Azure dasar serta konsep Failover Cluster dasar. Saya akan fokus pada apa yang unik tentang penggelaran File Server Failover Cluster di Azure di Zona Ketersediaan. Jika wilayah Azure Anda belum mendukung Zona Ketersediaan, Anda harus menggunakan Domain Fault sebagai gantinya seperti yang dijelaskan di pos sebelumnya. Dengan DataKeeper Cluster Edition Anda dapat mengambil Disk Terkelola yang dilampirkan secara lokal, apakah itu Disk Premium atau Standar, dan mereplikasi disk tersebut secara serentak, asinkron atau campuran atau keduanya, antara dua atau lebih node klaster. Selain itu, sumber daya DataKeeper Volume terdaftar di Windows Server Failover Clustering yang mengambil tempat dari sumber Disk fisik. Alih-alih mengontrol pemesanan SCSI-3 seperti Physical Disk Resource, Volume DataKeeper mengontrol arah cermin. Ini memastikan simpul aktif selalu menjadi sumber cermin. Sejauh Failover Clustering yang bersangkutan, terlihat, terasa dan bau seperti Disk Fisik dan digunakan dengan cara yang sama Sumber Daya Disk Fisik akan digunakan.

Prasyarat

• Anda telah menggunakan Portal Azure sebelumnya dan nyaman menggunakan mesin virtual di Azure IaaS.
• Telah memperoleh lisensi atau lisensi eval dari SIOS DataKeeper

Menyebarkan File Server Failover Cluster Di Azure

Untuk membangun 2-node File Server Failover Cluster Instance di Azure, kita akan menganggap Anda memiliki Virtual Network dasar berdasarkan Azure Resource Manager. Anda memiliki setidaknya satu mesin virtual dan berjalan dan dikonfigurasi sebagai Pengontrol Domain. Setelah Anda memiliki Jaringan Virtual dan Domain yang dikonfigurasi, Anda akan menyediakan dua mesin virtual baru yang akan bertindak sebagai dua node dalam kelompok kami. Lingkungan kita akan terlihat seperti ini: DC1 – Pengontrol Domain dan File Share Witness SQL1 dan SQL2 – Dua node dari File Server Cluster kami. Jangan biarkan nama-nama itu membingungkan Anda. Kami sedang membangun File Server Cluster di panduan ini. Dalam posting saya berikutnya saya akan menunjukkan konfigurasi cluster SQL Server.

Penyediaan Dua Cluster Nodes

Dengan menggunakan Azure Portal, kami akan menyediakan SQL1 dan SQL2 dengan cara yang sama.  Ada banyak pilihan untuk dipilih termasuk ukuran instan, opsi penyimpanan, dll. Panduan ini tidak dimaksudkan sebagai panduan lengkap untuk menerapkan Server di Azure. Ada beberapa sumber daya yang sangat bagus di luar sana dan lebih banyak diterbitkan setiap hari. Namun, ada beberapa hal penting yang perlu diingat saat membuat instance Anda, terutama di lingkungan yang padat. Ketersediaan Zona – Penting bahwa baik SQL1, SQL2 berada di Zona Ketersediaan yang berbeda. Demi panduan ini, kami akan menganggap Anda menggunakan Windows 2016 dan akan menggunakan Cloud Witness untuk Kuorum Kluster. Jika Anda menggunakan Windows 2012 R2 atau Windows Server 2008 R2, bukan Windows 2016, Anda harus mengonfigurasi File Share Witness di 3rd Availability Zone. Cloud Witness tidak diperkenalkan hingga Windows Server 2016. Dengan menempatkan node cluster di Zona Ketersediaan yang berbeda, kami memastikan bahwa setiap node cluster berada di pusat data Azure yang berbeda di wilayah yang sama. Memanfaatkan Ketersediaan Zona daripada Domain Kesalahan lama bermanfaat. Ini mengisolasi Anda dari jenis pemadaman terjadi hanya beberapa minggu yang lalu yang meruntuhkan seluruh wilayah Tengah Selatan selama beberapa hari. Pastikan untuk menambahkan setiap node cluster ke Zone Ketersediaan yang berbeda. Jika Anda memanfaatkan File Share Witness, ia harus berada di 3rd Availability Zone. [/ Caption]

Alamat IP Statis

Setelah setiap VM disediakan, Anda akan ingin masuk ke pengaturan dan mengubah pengaturan sehingga alamat IP adalah Statis. Kami tidak ingin alamat IP dari node cluster kami berubah. Pastikan setiap node cluster menggunakan IP statis [/ caption]

Penyimpanan

Sejauh menyangkut Storage, Anda akan ingin berkonsultasi Praktik terbaik kinerja untuk SQL Server di Azure Virtual Machines. Bagaimanapun, Anda akan minimal perlu menambahkan setidaknya satu Managed Disk tambahan ke setiap node cluster Anda. DataKeeper dapat menggunakan Disk Dasar, Penyimpanan Premium, atau bahkan beberapa disk bergaris bersama di Ruang Penyimpanan lokal. Jika Anda ingin menggunakan Ruang Penyimpanan lokal, berhati-hatilah untuk membuat Ruang Penyimpanan sebelum konfigurasi kluster. Hal ini disebabkan masalah yang diketahui dengan Failover Clustering dan Space Storage lokal. Semua disk harus diformat NTFS.

Buat Cluster

Dengan asumsi kedua node cluster (SQL1 dan SQL2) telah ditetapkan seperti yang dijelaskan di atas dan ditambahkan ke domain Anda yang ada, kami siap untuk membuat cluster. Sebelum kami membuat gugus, ada beberapa Fitur yang harus diaktifkan. Fitur-fitur ini. Net Framework 3.5 dan Failover Clustering. Fitur-fitur ini harus diaktifkan pada kedua node cluster. Anda juga harus mengaktifkan Peran Server FIle. Aktifkan fitur .Net Framework 3.5 dan Failover Clustering dan File Server pada kedua node cluster. [/ caption] Setelah peran itu dan fitur-fitur tersebut telah diaktifkan , Anda siap membangun kluster Anda. Sebagian besar langkah yang akan saya tunjukkan dapat dilakukan melalui PowerShell dan GUI. Namun, saya akan merekomendasikan bahwa untuk langkah pertama ini Anda menggunakan PowerShell untuk membuat kluster Anda. Jika Anda memilih untuk menggunakan GUI Failover Cluster Manager untuk membuat kluster Anda akan menemukan bahwa Anda berakhir dengan klaster yang dikeluarkan alamat IP duplikat. Tanpa masuk ke detail besar, apa yang akan Anda temukan adalah bahwa Azure VM harus menggunakan DHCP. Dengan menetapkan "Static IP" ketika kita membuat VM di portal Azure, yang kita lakukan hanyalah membuat semacam reservasi DHCP. Ini bukan reservasi DHCP karena reservasi DHCP yang benar akan menghapus alamat IP dari kumpulan DHCP. Sebaliknya, ini menentukan IP Statis di portal Azure hanya berarti bahwa jika alamat IP tersebut masih tersedia ketika VM memintanya, Azure akan mengeluarkan IP itu padanya. Namun, jika VM Anda offline dan host lain datang online di subnet yang sama, maka akan dikeluarkan alamat IP yang sama.

Efek Samping Lain Untuk Bagaimana Azure Diimplementasikan DHCP

Saat membuat klaster dengan Windows Server Failover Cluster GUI, tidak ada opsi untuk menentukan alamat IP kluster. Alih-alih bergantung pada DHCP untuk mendapatkan alamat. Yang aneh adalah, DHCP akan mengeluarkan alamat IP duplikat. Biasanya alamat IP yang sama dengan tuan rumah yang meminta alamat IP baru. Pemasangan kluster akan selesai, tetapi Anda mungkin memiliki beberapa kesalahan aneh. Anda mungkin perlu menjalankan Windows Server Failover Cluster GUI dari node yang berbeda untuk membuatnya berjalan. Setelah Anda menjalankannya, Anda perlu mengubah alamat IP gugus inti ke alamat yang saat ini tidak digunakan di jaringan. Anda dapat menghindari kekacauan itu hanya dengan membuat gugus melalui Powershell dan menentukan alamat IP klaster sebagai bagian dari perintah PowerShell untuk membuat kluster. Anda dapat membuat kluster menggunakan perintah New-Cluster sebagai berikut:

Cluster Baru -Name cluster1 -Node sql1, sql2 -StaticAddress 10.0.0.100 -NoStorage

Setelah pembuatan klaster selesai, Anda juga akan ingin menjalankan validasi klaster dengan menjalankan perintah berikut. Anda seharusnya mengharapkan untuk melihat beberapa peringatan tentang penyimpanan dan jaringan, tetapi itu diharapkan di Azure dan Anda dapat mengabaikan peringatan tersebut. Jika ada kesalahan yang dilaporkan, Anda harus mengalaminya sebelum Anda melanjutkan.

Uji-Cluster

Buat Cluster Quorum

jika Anda menjalankan Windows 2016 atau 2019 Anda perlu membuat Cloud Witness untuk kuorum klaster. Jika Anda menjalankan Windows Server 2012 R2 atau 2008 R2, Anda harus membuat File Share Witness. Instruksi rinci tentang pembuatan saksi dapat ditemukan di sini.

Instal DataKeeper

Setelah cluster dibuat, sekarang saatnya untuk menginstal DataKeeper. Penting untuk menginstal DataKeeper setelah cluster awal dibuat sehingga jenis sumber daya cluster khusus dapat didaftarkan dengan klaster. Jika Anda menginstal DataKeeper sebelum gugus dibuat, Anda hanya perlu menjalankan penginstalan lagi dan melakukan instalasi perbaikan. Instal DataKeeper setelah cluster dibuat [/ caption] Selama instalasi, Anda dapat mengambil semua opsi default.  Akun layanan yang Anda gunakan harus merupakan akun domain dan berada di grup administrator lokal pada setiap node dalam gugus. Akun layanan harus merupakan akun domain yang ada di grup admin lokal pada setiap node. Setelah DataKeeper diinstal dan dilisensikan pada setiap node, Anda harus mereboot server.

Buat Sumber Daya Volume DataKeeper

Untuk membuat DataKeeper Volume Resource Anda harus memulai UI DataKeeper dan terhubung ke kedua server. Terhubung ke SQL1 [/ caption] Terhubung ke SQL2 [/ caption] Setelah Anda terhubung ke setiap server, Anda siap untuk membuat Volume DataKeeper Anda. Klik kanan pada Jobs dan pilih "Buat Pekerjaan" Berikan pekerjaan nama dan deskripsi. Pilih server sumber Anda, IP dan volume. Alamat IP adalah apakah lalu lintas replikasi akan bepergian. Pilih server target Anda. Pilih opsi Anda. Untuk tujuan kami di mana kedua VM berada di wilayah geografis yang sama, kami akan memilih replikasi yang sinkron. Untuk replikasi jarak yang lebih jauh, Anda akan ingin menggunakan asynchronous dan mengaktifkan beberapa kompresi. Dengan mengklik ya pada pop-up terakhir, Anda akan mendaftarkan Sumber Daya Volume DataKeeper Baru dalam Penyimpanan Tersedia dalam Failover Clustering. Anda akan melihat Sumber Daya Volume DataKeeper baru dalam Penyimpanan Tersedia.

Buat Sumber Daya Cluster Server File

Untuk membuat File Server Cluster Resource, kita akan menggunakan Powershell sekali lagi daripada antarmuka Failover Cluster. Alasannya adalah karena sekali lagi karena mesin virtual dikonfigurasi untuk menggunakan DHCP, wizard berbasis GUI tidak akan meminta kita untuk memasukkan alamat IP klaster dan sebagai gantinya akan mengeluarkan alamat IP duplikat. Untuk menghindari ini kita akan menggunakan perintah powershell sederhana untuk membuat Sumber Daya Cluster Server FIle dan menentukan Alamat IP

Add-ClusterFileServerRole -Storage "DataKeeper Volume E" -Name FS2 -StaticAddress 10.0.0.101

Catat alamat IP yang Anda tentukan di sini. Itu harus alamat IP unik di jaringan Anda. Kami akan menggunakan alamat IP yang sama nanti ketika kami membuat Penyeimbang Beban Internal kami.

Buat Penyeimbang Beban Internal

Di sinilah tempat failover clustering di Azure berbeda dari infrastruktur tradisional. Tumpukan jaringan Azure tidak mendukung ARPS serampangan, sehingga klien tidak dapat terhubung langsung ke alamat IP klaster. Sebaliknya, klien terhubung ke load balancing internal dan dialihkan ke node cluster aktif. Yang perlu kita lakukan adalah membuat penyeimbang muatan internal. Ini semua bisa dilakukan melalui Portal Azure seperti yang ditunjukkan di bawah ini. Anda dapat menggunakan Penyeimbang Beban Publik jika klien Anda terhubung melalui internet publik. Tetapi dengan asumsi klien Anda berada di vNet yang sama, kami akan membuat Penyeimbang Beban Internal. Hal penting yang perlu diperhatikan di sini adalah bahwa Jaringan Virtual sama dengan jaringan di mana node cluster Anda berada. Juga, alamat IP Pribadi yang Anda tentukan akan sama persis dengan alamat yang Anda gunakan untuk membuat Sumber Daya Cluster Server File. Selain itu, karena kami menggunakan Zona Ketersediaan, kami akan membuat Pengatur Muatan Standar Berlebih Zona seperti yang ditunjukkan pada gambar di bawah ini. Setelah Internal Load Balancer (ILB) dibuat, Anda harus mengeditnya. Hal pertama yang akan kita lakukan adalah menambahkan kumpulan backend. Melalui proses ini Anda akan memilih dua node cluster. Hal berikutnya yang akan kita lakukan adalah menambahkan Probe. Probe yang kami tambahkan akan memeriksa Port 59999. Probe ini menentukan node mana yang aktif di kluster kami. Dan akhirnya, kita membutuhkan aturan load balancing untuk mengarahkan trafik SMB, port TCP 445. Yang penting untuk diperhatikan dalam screenshot di bawah ini adalah Direct Server Return Enabled. Pastikan Anda melakukan perubahan itu.

Perbaiki Sumber Daya IP Server File

Langkah terakhir dalam konfigurasi adalah menjalankan skrip PowerShell berikut di salah satu simpul klaster Anda. Ini akan memungkinkan Cluster IP Address untuk menanggapi probe ILB. Juga untuk memastikan bahwa tidak ada konflik alamat IP antara Cluster IP Address dan ILB. Mohon dicatat; Anda perlu mengedit skrip ini agar sesuai dengan lingkungan Anda. Subnet mask diatur ke 255.255.255.255. Ini bukan kesalahan, biarkan saja apa adanya. Ini membuat rute khusus host untuk menghindari konflik alamat IP dengan ILB.

# Definisikan variabel
$ ClusterNetworkName = “” 
# nama jaringan klaster (Gunakan Get-ClusterNetwork di Windows Server 2012 lebih tinggi untuk menemukan nama)
$ IPResourceName = “” 
# Nama sumber alamat IP 
$ ILBIP = “” 
# Alamat IP Penyeimbang Beban Internal (ILB)
Import-Module FailoverClusters
# Jika Anda menggunakan Windows Server 2012 atau lebih tinggi:
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255"; Jaringan = $ ClusterNetworkName; EnableDhcp = 0}
# Jika Anda menggunakan Windows Server 2008 R2, gunakan ini: 
#cluster res $ IPResourceName / priv diaktifkanhcp = 0 alamat = $ ILBIP probeport = 59999 subnetmask = 255.255.255.255

Membuat File Saham

Anda akan menemukan bahwa menggunakan File Share Wizard di Failover Cluster Manager tidak berfungsi. Sebagai gantinya, Anda cukup membuat file yang dibagikan di Windows Explorer pada simpul aktif. Failover clustering secara otomatis mengambil bagian-bagian itu dan menempatkannya di dalam cluster. Perhatikan bahwa opsi "Ketersediaan Berkelanjutan" dari pembagian file tidak didukung dalam konfigurasi ini.

Kesimpulan

Anda sekarang harus memiliki File Server Failover Cluster yang berfungsi di Azure yang menjangkau Zona Ketersediaan. Jika Anda membutuhkan kunci evaluasi DataKeeper, isi formulir di http://us.sios.com/clustersyourway/cta/14-day-trial dan SIOS akan mengirimkan kunci evaluasi yang dikirimkan kepada Anda.

Windows Server 2008 R2 tetap hidup di awan. Jadi, inilah panduan mulai cepat untuk semua orang yang membutuhkan bantuan dengan SQL Server Cluster Pada Windows Server 2008 R2. Ya, Azure mendukung Windows Server 2008 R2 dan versi lama dari SQL Server termasuk 2008 R2 dan 2012. Tentu saja Always On Availability Groups tidak diperkenalkan hingga SQL 2012 dan bahkan Anda mungkin ingin menghindari Ketersediaan Grup karena beberapa masalah kinerja yang terkait dengan versi itu. Perlu mendukung versi lama dari SQL Server atau Windows? Membangun cluster SANless berdasarkan SIOS DataKeeper sebagaimana disebutkan dalam dokumentasi Azure.

SQL Server Cluster Pada Windows Server 2008 R2 – Bagaimana Cara Mengatasinya?

Singkatnya di sini adalah langkah-langkah untuk SQL Server Cluster Pada Windows Server 2008 R2

• Penyediaan dua server cluster dan saksi berbagi file dalam Set Ketersediaan yang sama. Ini menempatkan ketiga suara quorum di Domain Fault dan Update yang berbeda.
• Ada perbaikan terbaru untuk gugus SQL 2008 R2 di Azure untuk mengaktifkan pendengar yang digunakan oleh AGs dan FCI. https://support.microsoft.com/en-us/help/2854082/update-enables-sql-server-availability-group-listeners-on-windows-serv
• Instal itu dan semua pembaruan OS lainnya.
• Menyediakan penyimpanan di setiap server.
• Format NTFS dan berikan huruf drive.
• Setiap node cluster membutuhkan penyimpanan yang identik. Aktifkan Kerangka Failover Clustering dan .Net 3.5 pada setiap server
• Tambahkan server ke domain
• Buat klaster dasar, tetapi GUNAKAN POWERSHELL dan tentukan alamat IP kluster. Jika Anda menggunakan GUI untuk membuat kluster, itu akan membingungkan dan menyediakan alamat IP duplikat. Menghubungkan melalui GUI akan memungkinkan Anda untuk terhubung ke kluster dari salah satu simpul. Jika Anda terhubung, Anda dapat memperbaiki masalah dengan menentukan alamat IP statis untuk digunakan oleh sumber gugus. Berikut ini contoh penggunaan Powershell untuk membuat kluster

  Cluster Baru -Name cluster1 -Node sql1, sql2 -StaticAddress 10.0.0.101 -NoStorage-

• Tambahkan File Bagikan Saksi ke kluster
• Instal DataKeeper di kedua node cluster
• Buat Sumber Daya Volume DataKeeper dan pastikan mereka Penyimpanan Tersedia
• Instal SQL ke dalam kluster seperti biasanya di kluster penyimpanan bersama.
• Konfigurasikan Azure ILB dan jalankan skrip powershell untuk memperbarui sumber daya IP Cluster SQL untuk mendengarkan di Probe Port.

Semua ini sepenuhnya didokumentasikan pada halaman dokumentasi SIOS, Menyebarkan DataKeeper Cluster Edition di Azure Jika Anda memiliki pertanyaan tentang ketersediaan tinggi untuk SQL Server atau pemulihan bencana di Azure, AWS atau Google Cloud, lakukan kunjungi halaman kami di pengelompokan dan topik terkait lainnya . Direproduksi dengan izin dari Clusteringformeremortals.com

Strip Bersama Beberapa Disk Dalam Ruang Penyimpanan Sederhana

Anda sedang membangun cluster SANless SQL Server dengan SIOS DataKeeper. Atau mungkin Anda mengonfigurasi Always On Availability Groups untuk SQL Server. Bagaimana dengan mencoba mengupas beberapa disk dalam Ruang Penyimpanan Sederhana (RAID 0) untuk kinerja? Ini sangat umum dilakukan di awan di mana setiap instance biasanya didukung oleh ketahanan perangkat keras, sehingga RAID 0 tidak terlalu berisiko. Misalnya, saya memiliki pelanggan baru di AWS yang ingin memaksimalkan IOPS-nya menjadi 80.000 – IOPS maksimum yang saat ini tersedia untuk satu instance. Sekarang perlu diingat, hanya ukuran contoh EBS yang dioptimalkan terbesar yang mendukung 80.000 IOPS. Jadi, pastikan Anda tahu apa IOPS maksimum ukuran contoh khusus Anda mendukung. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html Dalam hal ini kami memiliki instance ac5.18xlarge yang mendukung 80.000 IOPS. Namun, setiap volume IOPS IBS yang disediakan hanya mendukung hingga 32.000 IOPS. Satu-satunya cara untuk mencapai 80.000 IOPS saat menulis ke volume tunggal adalah dengan melucuti tiga volume ini bersama-sama dalam Ruang Penyimpanan Sederhana. Di sinilah letak gosok. Jika Anda mencoba melakukan Strip Together Multiple Disk dalam Ruang Penyimpanan Sederhana dalam kluster yang ada, semuanya akan menjadi rusak dengan cepat. Rekan MVP Joey D’Antoni baru-baru ini menulis blog tentang masalah ini. Tampaknya masih ada masalah di pratinjau Windows Server 2019. Sama seperti saran Joey, saya selalu menyarankan pelanggan saya untuk membangun simpul dan Ruang Penyimpanan apa pun sebelum mereka memulai proses pengelompokan. Ini membuat proses untuk Menggabungkan Beberapa Disk Bersama dalam Ruang Penyimpanan Sederhana menjadi lebih lancar. Ini juga memungkinkan pelanggan memiliki waktu untuk mengukur kinerja server sebelum mereka menambahkan replikasi apa pun. Dan juga untuk memastikan semuanya berjalan sesuai harapan. Ingin tahu lebih banyak kiat cepat seperti cara Menggabungkan Beberapa Disk Bersama di Ruang Penyimpanan Sederhana, lihat posting kami lainnya tentang pengelompokan Direproduksi dengan izin dari Clusteringformeremortals.com