Dapatkah Saya Menempatkan File Saya Berbagi dengan Saksi Pada Pembagian DFS?

Dapatkah Saya Menempatkan File Saya Berbagi dengan Saksi Pada Pembagian DFS?

Saya selalu ditanyai pertanyaan ini – Di mana saja saya bisa menempatkan File Share Witness On A DFS Share. Orang-orang khawatir kehilangan saksi berbagi file mereka. Oleh karena itu seperti banyak dari saham mereka yang lain, mereka ingin memanfaatkan DFS untuk beberapa ketersediaan tambahan. Ini ide yang sangat buruk dan tidak didukung. Baru-baru ini Microsoft menerbitkan artikel blog hebat yang menjelaskan dengan tepat mengapa File Share Witness On A DFS Share tidak didukung. https://blogs.msdn.microsoft.com/clustering/2018/04/13/failover-cluster-file-share-witness-and-dfs/ Sebagian besar artikel ini juga akan berlaku untuk orang yang bertanya apakah mereka dapat menggunakan DataKeeper mereplikasi sumber daya volume sebagai Disk Share. Masuk akal. Anda dapat menggunakan sumber daya Volume DataKeeper sebagai pengganti sumber daya Disk Fisik untuk beban kerja lainnya, jadi mengapa tidak Disk Witness? Masalah ini sama dengan masalah DFS. Jika komunikasi antara kedua server hilang, tidak ada jaminan bahwa volume tidak akan online di kedua server. Ini akan menghasilkan kondisi otak split potensial. Sumber Disk Fisik mengatasi masalah ini dengan menggunakan pemesanan SCSI. Ini akan memastikan disk hanya dapat diakses oleh satu node cluster pada suatu waktu. Kabar baiknya adalah bahwa Microsoft sudah menghalangi Anda untuk mencoba menggunakan sumber DataKeeper Volume yang direplikasi. Dan datang di Windows Server 2019, sepertinya mereka juga akan memblokir Anda dari menggunakan berbagi DFS sebagai File Share Witness.

Ada pertanyaan seperti ini tentang menempatkan File Share Witness On A DFS Share? Baca melalui blog kami atau hubungi kami! Direproduksi dengan izin dari ClusteringForMereMortals.com

Kecepatan Jaringan Antara Daerah Azure Terhubung Dengan Peering Jaringan Virtual

Apa itu Kecepatan Jaringan Antara Daerah Azure Terhubung Dengan Peering Jaringan Virtual?

Ini adalah pertanyaan yang saya tanyakan pada diri saya hari ini. Tentu saja saya tidak dapat menemukan alasan di balik Kecepatan Jaringan Antara Daerah Azure Terhubung Dengan Peering Jaringan Virtual yang didokumentasikan di mana saja. Saya berasumsi tidak ada jaminan. Mungkin tergantung pada pemanfaatan saat ini, dll. Jika saya salah, seseorang tolong tunjuk saya ke dokumentasi yang menyatakan kecepatan yang tersedia. Saya terutama melihat di sini dan di sini. Jadi saya menyiapkan dua contoh Windows 2016 D4s v3 – satu di Amerika Tengah dan satu di AS Timur 2. Keduanya adalah wilayah berpasangan. Jika Anda tidak tahu apa yang mengintip, pada dasarnya memungkinkan Anda untuk dengan mudah menghubungkan dua jaringan virtual Azure yang berbeda. Mengintip sangat mudah diatur. Pastikan Anda mengonfigurasinya dari kedua Jaringan Virtual. Setelah dikonfigurasi dengan benar maka akan terlihat seperti ini.

Melakukan Tes

Sebuah jaringan yang berfungsi dengan benar di Azure [/ caption]

Saya kemudian mengunduh iPerf3 pada masing-masing server dan memulai pengujian saya. Pada awalnya saya mendapat hasil yang cukup mengecewakan. Tapi kemudian setelah melakukan penelitian, saya menemukan bahwa menjalankan beberapa utas dan meningkatkan ukuran jendela melaporkan pengukuran yang lebih akurat dari bandwidth yang tersedia. Saya mencoba beberapa pengaturan yang berbeda. Tampaknya maksimum hanya sekitar 1,9 Gbps, jauh lebih baik daripada 45 Mbps! Saya menggunakan parameter klien dan menghasilkan hasil terbaik. Lihat sebagai berikut:

iperf3.exe -c 10.0.3.4 -w32M -P 4 -t 30

Contoh dari output itu terlihat seperti ini.

- - - - - - - - - - - - - - - - - - - - - - - - -
 [4] 2,00-3,00 detik 34,1 MBytes 286 Mbits / dtk
 [6] 2,00-3,00 detik 39,2 MBytes 329 Mbit / detik
 [8] 2,00-3,00 detik 56,1 MBytes 471 Mbit / detik
 [10] 2,00-3,00 detik 73,2 MBytes 615 Mbits / dtk
 [SUM] 2,00-3,00 detik 203 MBytes 1,70 Gbits / detik
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [4] 3,00-4,00 detik 37,5 MBit 315 Mbit / detik
 [6] 3,00-4,00 detik 19,9 MBte 167 Mbits / detik
 [8] 3,00-4,00 detik 97,0 MBytes 814 Mbits / dtk
 [10] 3,00-4,00 detik 96,8 MBytes 812 Mbits / dtk
 [SUM] 3,00-4,00 dtk 251 MBtt 2,11 Gbits / dtk
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [4] 4,00-5,00 detik 34,6 MBytes 290 Mbit / detik
 [6] 4,00-5,00 detik 24,6 MBytes 207 Mbit / detik
 [8] 4,00-5,00 detik 70,1 MBytes 588 Mbits / dtk
 [10] 4,00-5,00 detik 97,8 MBytes 820 Mbit / dtk
 [SUM] 4,00-5,00 detik 227 MBytes 1,91 Gbit / detik
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [4] 5,00-6,00 detik 34,5 MBit 289 Mbit / detik
 [6] 5,00-6,00 detik 31,9 MBt 266 Mbit / detik
 [8] 5,00-6,00 detik 73,9 MBits 620 Mbit / detik
 [10] 5,00-6,00 detik 86,4 MBit 724 Mbit / detik
 [SUM] 5.00-6.00 detik 227 MBytes 1,90 Gbits / detik
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [4] 6,00-7,00 detik 35,4 MB 297 Mbit / detik
 [6] 6,00-7,00 detik 32,1 MBytes 269 Mbit / detik
 [8] 6,00-7,00 detik 80,9 MBte 678 Mbit / detik
 [10] 6,00-7,00 detik 78,5 MBytes 658 Mbits / dtk
 [SUM] 6,00-7,00 detik 227 MBytes 1,90 Gbits / detik

Saya melihat lonjakan setinggi 2,5 Gbps dan terendah serendah 1,3 Gbps.

Perbarui Dari Twitter

Jadi saya menerima beberapa umpan balik dari @jvallery yang harus saya coba. Hal pertama yang saya lakukan adalah menaikkan instance saya yang ada ke D64sv3 dan menggunakan -P 64. Saya melihat peningkatan yang signifikan

iperf3.exe -c 10.0.3.4 -w32M -P 64 -t 30

[SUM] 0,00-1,00 detik 2,55 GBt 21,8 GB / detik

Saya kemudian memunculkan beberapa contoh F72v2 seperti yang disarankan dan saya melihat hasil yang lebih baik.

iperf3.exe -c 10.0.2.5 -w32M -P 72 -t 30

[SUM] 0,00-1,00 detik 2,86 GBytes 24,5 Gbits / detik

  Saya tidak cukup paham di Linux. Bu tampaknya ada jumlah bandwidth yang wajar yang tersedia antara daerah Azure ketika menggunakan jaringan yang diintip. Jika seseorang ingin mengulang tes ini menggunakan Linux sebagai @jvallery disarankan, saya akan senang untuk memposting hasil Anda di sini! Tampaknya memang ada kemungkinan untuk memvariasikan Kecepatan Jaringan Antara Wilayah Azure Terhubung Dengan Peering Jaringan Virtual.

Menggunakan SIOS DataKeeper For Disaster Recovery

Untuk salah satu klien saya, saya memilih untuk menggunakan dua jaringan ini untuk mengatasi pemulihan bencana SQL Server menggunakan SIOS DataKeeper untuk secara asynchronous mereplikasi data SQL antar wilayah untuk pemulihan bencana.

Dalam skenario khusus ini, kami mengukur RPO yang diukur dalam milidetik. Seperti yang Anda lihat dalam video di bawah ini, selama tes DISKSPD dimaksudkan untuk mensimulasikan beban kerja SQL Server yang khas, RPO <1 detik. Saya ingin mendengar pendapat Anda tentang pengalaman Anda mengenai kecepatan jaringan apa pun yang Anda ukur di Azure dan bagaimana Anda menggunakan jaringan yang diintip di Azure. Punya pertanyaan tentang Kecepatan Jaringan Antara Daerah Azure Terhubung Dengan Peering Jaringan Virtual? Baca melalui blog kami atau hubungi kami! Direproduksi dengan izin dari ClusteringForMereMortals.com

Cara Bertahan Hidup A Azure Cloud Outage

Lightning Never Strikes Twice: Surviving A Azure Cloud Outage

Kemarin pagi saya membuka umpan Twitter saya untuk menemukan bahwa banyak orang terkena dampak pemadaman Azure Cloud. Hampir setiap halaman sumber daya tentang pemadaman tidak tersedia. Untungnya, @AzureSupport terus memberikan pembaruan melalui Twitter. Pembaruan asli dari @AzureSupport datang pada pukul 7:12 pagi. Melihat kembali pada umpan Twitter, sepertinya masalah awalnya dimulai satu atau dua jam sebelum itu. Dengan cepat menjadi jelas bahwa pemadaman memiliki dampak penyebaran yang lebih luas daripada hanya wilayah AS Tengah Selatan seperti yang dilaporkan semula. Sepertinya layanan yang bergantung pada Azure Active Directory dapat berdampak juga dan pelanggan yang mencoba menyediakan langganan baru mengalami masalah. Dan 24 jam kemudian masalah belum sepenuhnya teratasi dan sesuai dengan pembaruan terakhir pagi ini … Jadi apa yang bisa Anda lakukan untuk meminimalkan dampak dari gangguan awan biru ini? Tidak ada yang bisa menyalahkan Microsoft atas bencana alam seperti sambaran petir. Tetapi pada akhir hari jika satu-satunya rencana pemulihan bencana Anda adalah menelepon, men-tweet, dan mengirim email ke Microsoft hingga masalah teratasi, Anda baru saja menerima kebangkitan yang kasar. Terserah Anda untuk memastikan bahwa semua basis tercakup ketika datang ke rencana pemulihan bencana Anda.

Waktu Untuk Menjelajahi Beberapa Alternatif?

Sementara debu masih menempel pada apa yang terkena dampak dan apa yang dapat dilakukan pelanggan untuk meminimalkan waktu henti, inilah beberapa pemikiran awal saya.

Sets Ketersediaan (Domain Fault / Perbarui Domain)

Dalam skenario ini, bahkan jika Anda membangun Failover Clusters, atau leveraged Azure Load Balancers dan Availability Sets, Anda masih akan kurang beruntung karena seluruh wilayah menjadi offline. Meskipun masih disarankan untuk memanfaatkan Sets yang Tersedia, terutama untuk downtime yang direncanakan, dalam hal ini Anda masih akan offline.

Zona Ketersediaan

Ini belum tersedia di wilayah AS Tengah Selatan. Namun tampaknya konsep Zona Ketersediaan yang diluncurkan di Azure dapat meminimalkan dampak pemadaman listrik. Dengan asumsi sambaran petir hanya berdampak pada satu pusat data, maka pusat data lain di Zona Ketersediaan lainnya harus tetap beroperasi. Namun, pemadaman layanan non-regional lainnya seperti Azure Active Directory (AAD) tampaknya telah mempengaruhi beberapa wilayah. Saya pikir Zona Ketersediaan tidak akan mengisolasi Anda sepenuhnya.

Global Load Balancers, Cross Failover Cluster, dll.

Apakah Anda sedang membangun cluster SANLess yang melintasi wilayah, atau menggunakan load balancer global untuk menyebarkan beban di beberapa wilayah, Anda mungkin telah meminimalkan dampak pemadaman di AS Tengah Selatan. Tetapi Anda mungkin masih rentan terhadap pemadaman AAD.

Hybrid-Cloud, Cross Cloud

Ketahanan yang terjamin dalam skenario kegagalan luas awan adalah memiliki rencana DR yang termasuk memiliki replikasi data secara real-time ke target di luar penyedia cloud primer Anda dan rencana di tempat untuk membawa aplikasi online dengan cepat di lokasi lain ini. Kedua lokasi ini harus sepenuhnya independen. Seharusnya tidak bergantung pada layanan dari lokasi utama Anda untuk tersedia, seperti AAD. Lokasi DR bisa menjadi penyedia cloud lain. Dalam hal ini AWS atau Google Cloud Platform tampak seperti alternatif logis, atau bisa juga datacenter Anda sendiri. Namun hal semacam itu mengalahkan tujuan berlari di awan di tempat pertama.

Perangkat Lunak sebagai Layanan

Meskipun Perangkat Lunak sebagai layanan seperti Azure Active Directory (ADD), Azure SQL Database (Database-as-Service) atau salah satu dari banyak tawaran SaaS dari penyedia cloud mana pun dapat terlihat menarik, Anda benar-benar perlu merencanakan skenario terburuk . Anda mungkin memiliki kontrol yang sangat kecil karena Anda mempercayai aplikasi bisnis penting untuk satu vendor. Ingat itu dalam hal opsi DR yang mencakup pemulihan di luar penyedia layanan cloud saat ini. Saya tidak memiliki kata-kata bijak di sini selain menyelidiki opsi DR Anda sebelum menerapkan layanan SaaS apa pun. Jika pemulihan di luar awan bukan pilihan, maka berpikirlah lama dan keras sebelum Anda mendaftar untuk layanan itu. Informasikan kepada pemilik saham bisnis bahwa jika layanan cloud sedang offline, mungkin tidak ada yang dapat Anda lakukan selain menelepon dan mengeluh.

Tren masa depan

Saya pikir dalam waktu dekat, Anda akan mulai mendengar lebih banyak tentang ketersediaan lintas awan. Juga tentang bagaimana orang memanfaatkan solusi seperti SIOS DataKeeper untuk membangun strategi HA dan DR yang kuat yang melintasi penyedia cloud. Model cloud cross atau cloud cloud yang sesungguhnya adalah satu-satunya cara untuk benar-benar melindungi diri Anda dari gangguan awan yang paling mungkin terjadi. Jika Anda terkena dampak dari penghentian terbaru ini, saya akan senang mendengar dari Anda. Katakan padaku apa yang terjadi, berapa lama kamu turun, dan apa yang kamu lakukan untuk pulih. Apa yang akan Anda lakukan agar di masa depan pengalaman Anda menjadi lebih baik? Baca lebih banyak artikel seperti Cara Bertahan Hidup A Azure Cloud Outage? Direproduksi dengan izin dari Clusteringformeremortals.com

Konversi Azure Cluster ke Managed Disk

Mengapa Anda Harus Mengkonversi Cluster Azure ke Managed Disk

Anda mungkin pernah mendengar tentang penghentian penyimpanan baru-baru ini yang berdampak pada beberapa contoh di wilayah Timur AS pada 16 Maret. Analisis akar masalah dari pemadaman itu diposting di sini. 16 Maret Penghentian Penyimpanan Timur AS

Dampak Pelanggan

Sebagian pelanggan yang menggunakan Penyimpanan di wilayah AS Timur mungkin mengalami kesalahan dan waktu tunggu saat mengakses akun penyimpanan mereka dalam satu unit skala Penyimpanan. Anda mungkin bertanya, "Apa itu unit skala Penyimpanan tunggal". Nah, Anda dapat menganggapnya sebagai kluster penyimpanan tunggal, atau SAN tunggal, atau bagaimanapun Anda ingin memikirkannya. Saya tidak berpikir Azure menerbitkan infrastruktur yang tepat. Meskipun Anda mungkin bisa berasumsi bahwa di balik layar mereka menggunakan Scale Out File Server untuk penyimpanan backend.

Bertahan dari Kegagalan Dengan Waktu Henti Minimal

Jadi pertanyaannya adalah, bagaimana saya bisa selamat dari pemadaman ini dengan downtime minimal? Jika Anda membaca lebih jauh bahwa analisis akar penyebab Anda menemukan nugget kecil ini.

Mesin Virtual menggunakan Managed Disks dalam Set Ketersediaan akan mempertahankan ketersediaan selama insiden ini. Oleh karena itu, sekarang saatnya untuk Mengkonversi Azure Cluster ke Managed Disks

Apa itu Disk Terkelola?

Pada 8 Februari Corey Sanders mengumumkan GA dari Managed Disks. Managed Disks akan membantu dalam pemadaman ini. Karena dengan memanfaatkan Kumpulan Ketersediaan yang dikombinasikan dengan Managed Disks, setiap instance dalam Kumpulan Ketersediaan Anda terhubung ke "unit skala Penyimpanan" yang berbeda. Jadi dalam kasus khusus ini, hanya satu dari node cluster yang gagal, meninggalkan node yang tersisa untuk mengambil alih beban kerja. Sebelum Managed Disks tersedia (apa pun yang digunakan sebelum tanggal 2/8/2016), tidak ada cara untuk memastikan bahwa penyimpanan yang terhubung ke server Anda berada pada unit skala Penyimpanan yang berbeda. Tentu, Anda dapat menggunakan akun penyimpanan yang berbeda untuk setiap instance. Namun dalam kenyataannya itu tidak menjamin bahwa Penyimpanan Akun Penyimpanan tersebut menyediakan penyimpanan pada unit skala Penyimpanan yang berbeda. Lebih banyak alasan untuk Konversi Azure Cluster ke Managed Disk. Jadi sementara Kumpulan Ketersediaan memastikan bahwa instance Anda berada di Domain Fault yang berbeda dan Perbarui Domain untuk memastikan ketersediaan instance itu sendiri, penyimpanan tambahan yang melekat pada setiap instance benar-benar mewakili satu titik kegagalan. Meskipun penyimpanan itu sendiri sangat tangguh, dengan tiga salinan data Anda dan opsi geo-redundan tersedia, dalam hal ini dengan kegagalan daya, seluruh unit skala Penyimpanan turun bersama dengan semua server yang melekat padanya. Singkat cerita… Mengkonversi Azure Cluster ke Managed Disks sesegera mungkin untuk membantu meminimalkan downtime https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to -managed-disks Dan jika Anda benar-benar ingin meminimalkan downtime Anda harus mempertimbangkan Hybrid Cloud Deployment yang menjangkau penyedia cloud atau on-prem ke cloud! Direproduksi dengan izin dari Clusteringformeremortals.com

Cloud Witness Untuk Membangun Multi-Instance SQL Server Failover Cluster Di Azure

Fitur Azure ILB Baru Memungkinkan Anda Untuk Membangun Multi-Instance SQL Server Failover Cluster Di Azure

Fitur baru, Cloud Witness adalah favorit saya saat ini. Sebelum kami melihat fitur kuorum baru di Windows Server 2016, saya pikir penting untuk mengetahui dari mana kami berasal. Dalam posting saya sebelumnya Memahami Kuorum Kluster Failover Windows Server di Windows Server 2012 R2 Saya membahas beberapa detail besar mengenai sejarah dan evolusi kuorum klaster. Saya sarankan Anda meninjau posting itu untuk memahami bagaimana kuorum bekerja di Windows Server 2012 R2. Juga, bagaimana fitur-fitur baru dari Windows Server 2016 akan membuat penyebaran klaster Anda bahkan lebih tangguh.

Cloud Witness

Cloud Witness memungkinkan Anda memanfaatkan Penyimpanan Azure Blob untuk bertindak sebagai saksi bagi kluster Anda. Saksi ini akan menjadi saksi Disk Witness atau File Share Witness. Konfigurasi Cloud Witness sangat mudah. Dari pengalaman saya biaya hampir tidak ada untuk menjadi tuan rumah di Azure. Satu-satunya downside adalah bahwa node cluster perlu dapat berkomunikasi melalui internet dengan Storage Azure Blob Anda. Sangat sering node klaster dilarang untuk berkomunikasi ke internet publik. Jadi Anda perlu berkoordinasi dengan tim keamanan Anda jika Anda ingin mengaktifkan Cloud Witness. Ada banyak alasan kuat untuk menggunakan Cloud Witness untuk membangun Multi-Instance SQL Server Failover Cluster In Azure. Tapi bagi saya itu sangat masuk akal dalam tiga lingkungan yang sangat spesifik: Failover Cluster di Azure, Cabang Kantor Cluster, dan Cluster Multisite.

Pada Pandangan Lebih Dekat

Mari kita lihat masing-masing skenario ini untuk melihat bagaimana seorang Cloud Witness dapat membantu. Gambar 1 – Ketika Anda mencoba untuk membangun Multi-Instance SQL Server Failover Cluster Di Azure, akun penyimpanan saksi cloud harus selalu dikonfigurasi Lokal Redundant Storage (LRS) [/ caption]

Penyebaran yang Sangat Tersedia

Jika Anda pindah ke Azure (atau benar-benar penyedia cloud apa pun), Anda akan ingin memastikan penyebaran Anda sangat tersedia. Jika Anda mengambil tentang SQL Server, File Server, SAP atau beban kerja lainnya yang secara tradisional bergerombol dengan Windows Server Failover Clustering, Anda harus menggunakan File Share Witness atau Cloud Witness, karena Disk Witness tidak mungkin di Azure. Dengan Windows Server 2012 R2 atau Windows Server 2008 R2, Anda harus menggunakan File Share Witness. Windows Server 2016 memungkinkan untuk menggunakan Cloud Witness. Keuntungan dari Cloud Witness adalah Anda tidak perlu mempertahankan instance Windows lainnya di Azure untuk menghosting File Share. Sebaliknya, Microsoft memungkinkan Anda untuk memanfaatkan Blob Storage.  Ini memberi Anda solusi yang lebih murah, yang jauh lebih mudah dikelola, dan lebih tangguh.

Lokasi

Ketika melihat penyebaran cluster di kantor cabang, biaya dan pemeliharaan selalu menjadi pertimbangan. Untuk jaringan ritel dengan ratusan atau ribuan lokasi, memiliki SAN di setiap lokasi dapat menjadi penghalang biaya. Setiap lokasi mungkin untuk menjalankan dua node Hyper-V cluster pada konfigurasi S2-Hyper-converged at^au solusi replikasi pihak ke-3 untuk meng-host sejumlah mesin virtual. Sekarang yang dilakukan Cloud Witness adalah membantu bisnis menghindari biaya penambahan server fisik tambahan di setiap lokasi untuk bertindak sebagai File Share Witness atau biaya penambahan SAN ke setiap lokasi.

Menghilangkan Kebutuhan Akan P^usat Data Ketiga

Dan akhirnya, ketika menggelar cluster multisite, Cloud Witness menghilangkan kebutuhan untuk pusat dat^a ke-3 untuk menjadi tuan rumah File Share Witness. Sebelum pengenalan Cloud Witness, praktik terbaik akan menentukan bahwa Saksi Berbagi Berkas berada di lo^kasi ketiga. Akses ke pusa^t data ke-3 hanya untuk menghosting saksi berbagi file tidak selalu layak dan tentu saja memperkenalkan lapisan kompleksitas lain. Dengan menggunakan Cloud Witness Anda menghilangkan kebutuhan untu^k mempertahankan lokasi ketiga dan akses ke saksi dilakukan melalui internet publik, meminimalkan persyaratan jaringan juga.

Kesadaran Situs

Ketika membangun klaster multisite, selalu ada masalah umum lainnya. Mengontrol failover untuk selalu memilih situs lokal tidak mungkin dilakukan. Meskipun Anda dapat menentukan Pemilik Pilihan, pengaturan Pemilik Pilihan umumnya salah dimengerti. Administrator mungkin tidak menyadari hal ini. Tetapi tahukah Anda bahwa meskipun mereka tidak mencantumkan server sebagai Pemilik Pilihan, server secara otomatis ditambahkan ke bagian akhir daftar Pemilik Pilihan yang dikelola oleh kluster. Hasil dari kesalahpahaman ini adalah bahwa meskipun Anda mungkin hanya mendaftarkan server lokal sebagai Pemilik Pilihan, Anda berpotensi memiliki failover sumber gugus ke situs DR. Dan ini bahkan ketika ada node yang sangat baik yang tersedia di situs lokal. Tentunya ini bukan apa yang Anda harapkan dan gunakan Kesadaran Situs akan menghilangkan masalah ini bergerak maju. Kesadaran Situs memperbaiki masalah ini dengan selalu lebih memilih situs lokal ketika memutuskan node mana yang akan online. Jadi dalam keadaan normal beban kerja yang berkelompok akan selalu failover ke simpul lokal kecuali Anda memiliki situs lengkap pemadaman. Dalam hal mana salah satu DR node akan datang online. Hal yang sama berlaku saat Anda menjalankan di situs DR. Cluster akan memulihkan beban kerja pada server di situs DR jika sebelumnya berjalan pada node di situs DR. Kesadaran Situs akan selalu lebih memilih simpul lokal.

Domain Kesalahan

Membangun berdasarkan kesadaran situs adalah Domain Kesalahan. Fault Domains melangkah lebih jauh dan memungkinkan Anda menentukan lokasi Node, Chasse, dan Rack selain Situs. Domain Fault memiliki tiga manfaat: Penyimpanan Affinity dalam Cluster Stretch, meningkatkan ketahanan Storage Spaces. Ini meningkatkan peringatan Layanan Kesehatan dengan memasukkan data meta tentang lokasi sumber daya terkait yang meningkatkan alarm. Penyimpanan Afinitas akan membantu memastikan bahwa beban kerja dan penyimpanan gugus Anda berjalan di lokasi yang sama. Anda tentu tidak ingin membaca dan menulis data VM Anda yang ada di CSV di kota yang berbeda. Namun, saya pikir pemenang terbesar di sini adalah skenario Storage Spaces Direct (S2D). SD2 akan memanfaatkan informasi yang Anda berikan tentang lokasi node klaster Anda (Situs, Rak, Chassis) untuk memastikan bahwa beberapa salinan data yang ditulis untuk redundansi semua tinggal di Domain Kesalahan yang berbeda. Ini membantu memastikan bahwa penempatan data dioptimalkan sehingga kegagalan Node, Chassis, Rak, atau Situs tunggal tidak menurunkan seluruh penempatan S2D Anda.  Cosmos Darwin memiliki video yang luar biasa di Saluran 9 yang menjelaskan konsep ini dengan sangat terperinci.

Ringkasan

Windows Server 2016 menambahkan beberapa perangkat tambahan baru ke kuorum klaster yang akan memberikan beberapa manfaat langsung ke penyebaran klaster Anda. Selain itu, periksa beberapa peningkatan klaster baru lainnya seperti peningkatan sistem rolling, Ketahanan Virtual Machine, Workgroup dan Multi-Domain Cluster dan lain-lain. Untuk membaca tentang tips lain seperti membangun Multi-Instance SQL Server Failover Cluster Di Azure dengan Cloud Witness, baca di posting kami. Direproduksi dengan izin dari Clusteringformeremortals.com