Carilah artikel Langkah-demi-Langkah tentang cara mengkonfigurasi DHCP di seluruh pusat data dan / atau tanpa penyimpanan bersama dalam waktu dekat menggunakan Windows Server Failover Clustering dan SteelEye DataKeeper Cluster Edition. Sementara itu, periksa video ini yang menunjukkan klaster DHCP yang menggunakan database DHCP yang direplikasi, bukan disk bersama di kluster.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2009/11/23/dhcp-cluster-without-shared-storage-andor-across-data-centers/

Baru-baru ini ada banyak pers, tentang menjalankan mesin virtual yang melakukan migrasi langsung di pusat data jarak jauh, yang memberi dukungan VMware terbatas untuk vMotion di Pusat Data, atau "vMotion jarak jauh" seperti yang saya lihat. Rincian solusinya dapat ditemukan di situs Cisco di sini. Sementara saya pikir itu bagus, saya ingin mengingatkan orang bahwa Microsoft Hyper-V memiliki fungsi yang sama hari ini dan memiliki persyaratan dan batasan yang jauh lebih sedikit daripada vMotion jarak jauh VMware.

Dimana VMware memiliki VMwareHA, vMotion dan Site Recovery Manager (SRM) untuk menjaga ketersediaan mesin virtual, Microsoft menyediakan fungsionalitas yang sama dengan Windows Server Failover Clustering dan sebenarnya dalam beberapa kasus melampaui apa yang dapat disediakan VMware dalam hal ketersediaan mesin virtual seperti Saya jelaskan di posting sebelumnya.

Yang ingin saya fokuskan pada hari ini adalah penawaran kompetitif Microsoft untuk "vMotion jarak jauh". Untuk mencapai fungsi yang sama di Hyper-V, Anda cukup menggunakan kumpulan Hyper-V multi-situs menggunakan Windows Server Failover Clustering dan host favorit Anda atau solusi replikasi berbasis penyimpanan yang disertifikasi untuk berfungsi dalam kluster multi-situs Windows Server 2008. Dengan melakukan ini, Anda dapat menggunakan infrastruktur jaringan yang ada dan infrastruktur penyimpanan yang ada untuk melakukan migrasi Langsung di seluruh pusat data. Sejauh persyaratan, mereka benar-benar sama dengan klaster multi-situs, kecuali saya akan merekomendasikan bahwa Anda menjangkau subnet Anda untuk menghindari masalah rekoneksi klien yang terjadi saat memindahkan mesin virtual ke subnet baru, karena klien dapat menyimpan ke lama Alamat IP hingga TTL kedaluwarsa.

Video demonstrasi Live Migration di seluruh pusat data menggunakan Windows Server 2008 R2 Hyper-V dan SteelEye DataKeeper Cluster Edition dapat dilihat di sini.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2009/09/17/hyper-v-live-migration-across-data-centers/

Membangun Konfigurasi Cluster Ketersediaan Tinggi

Ketika kami membangun Konfigurasi Cluster Ketersediaan Tinggi, ketersediaan aplikasi Anda hanya sebagus tautan terlemahnya. Apakah ini berarti bahwa jika Anda membeli server hebat dengan segala sesuatu yang berlebihan (CPU, kipas, daya, RAID, RAM, dll) dan SAN super mewah dengan konektivitas multi-jalur. Ditambah dengan beberapa switch SAN dan mengelompokkan aplikasi Anda dengan perangkat lunak pengelompokan favorit Anda. Anda mungkin memiliki aplikasi yang sangat andal – bukan? Yah, belum tentu. Apakah server terhubung ke UPS yang sama? Apakah mereka pada switch jaringan yang sama? Apakah mereka didinginkan oleh unit AC yang sama? Apakah mereka berada di gedung yang sama? Apakah SAN Anda benar-benar dapat diandalkan? Salah satu dari masalah ini antara lain adalah satu titik kegagalan dalam Konfigurasi Cluster Ketersediaan Tinggi.

Cari Dan Hapus Tautan Terlemah dalam Konfigurasi Cluster

Tentu saja, Anda harus tahu kapan "cukup baik" adalah "cukup baik". Anggaran dan SLA Anda akan membantu menentukan apa sebenarnya yang cukup baik. Namun, satu area dimana saya khawatir orang bisa skimping berada di area penyimpanan. Dengan munculnya solusi perangkat lunak iSCSI target murah atau gratis, saya melihat beberapa orang merekomendasikan agar Anda hanya membuang beberapa perangkat lunak target iSCSI di server cadangan dan voila – penyimpanan bersama instan.

Ingatlah, saya tidak sedang berbicara tentang solusi OEM iSCSI yang memiliki teknologi failover dan / atau fitur ketersediaan lainnya; atau bahkan solusi virtualisasi penyimpanan seperti FalconStor. Saya sedang berbicara tentang orang yang memiliki server yang menjalankan Windows Server 2008 yang telah dimuatinya dengan penyimpanan dan ingin mengubahnya menjadi target iSCSI. Ini bagus di laboratorium. Tetapi jika Anda serius tentang HA, Anda harus berpikir lagi. Bahkan Microsoft hanya menyediakan perangkat lunak iSCSI target mereka kepada pembangun OEM berkualitas yang berpengalaman dalam memberikan array penyimpanan kelas enterprise.

Apa yang Sebenarnya Anda Dapatkan?

Pertama-tama, ini adalah Windows. Tidak beberapa OS yang dikeraskan dibangun untuk hanya melayani penyimpanan. Ini akan memerlukan perawatan, update keamanan, perbaikan perangkat keras, dll. Ini pada dasarnya memiliki keandalan yang sama dengan server aplikasi yang Anda coba lindungi. Apakah masuk akal untuk mengelompokkan server aplikasi Anda. Namun gunakan kelas server dan OS yang sama untuk meng-host penyimpanan Anda? Anda pada dasarnya telah memindahkan satu titik kegagalan Anda dari server aplikasi Anda dan memindahkannya ke server penyimpanan Anda. Ini bukan langkah yang cerdas sejauh yang saya ketahui.

Beberapa perangkat lunak target Enterprise Class iSCSI mencakup perangkat lunak replikasi sinkron dan / atau asinkron serta kemampuan snapshot. Fungsi ini tentu saja membantu dalam hal tujuan titik pemulihan (RPO) Anda. Meskipun itu tidak akan membantu tujuan waktu pemulihan Anda (RTO) kecuali jika failover otomatis dan mulus ke perangkat lunak pengelompokan Anda. Katakanlah array penyimpanan iSCSI utama gagal di tengah malam. Siapa yang akan ada di sana untuk mengaktifkan salinan yang direplikasi? Anda mungkin jatuh selama beberapa waktu sebelum Anda bahkan menyadari ada masalah. Sekali lagi, ini mungkin "cukup baik"; Anda hanya perlu menyadari apa yang Anda sign up. Apakah itu Konfigurasi Cluster Ketersediaan Tinggi yang Anda cari?

SIOS DataKeeper

Satu hal yang dapat Anda lakukan untuk meningkatkan keandalan server target iSCSI Anda adalah menggunakan produk replikasi seperti SteelEye DataKeeper Cluster Edition untuk menghilangkan satu titik kegagalan. Mari saya gambarkan.

Jika kami mengambil konfigurasi yang sama seperti ditunjukkan di atas dan menambahkan target siaga panas iSCSI menggunakan SteelEye DataKeeper Cluster Edition untuk melakukan replikasi DAN failover otomatis, Anda baru saja memberi Anda solusi target iSCSI tingkat ketersediaan yang sama sekali baru. Solusi itu akan terlihat sangat mirip dengan ini.

Perbedaan utama dalam solusi SteelEye DataKeeper Cluster Edition vs solusi replikasi yang diberikan oleh beberapa vendor target iSCSI adalah dalam integrasi dengan WSFC. Pertanyaan untuk meminta vendor solusi iSCSI Anda adalah ini …

Apa yang terjadi jika saya menarik kabel daya pada server target iSCSI yang aktif?

Jika proses pemulihan adalah prosedur manual, ini bukan solusi HA yang benar. Tetapi bagaimana jika itu otomatis dan sepenuhnya terintegrasi dengan WSFC? Kemudian Anda memiliki tingkat ketersediaan yang jauh lebih tinggi dan telah menghilangkan array iSCSI sebagai satu titik kegagalan.

Mengobrol dengan kami juga untuk mencapai Konfigurasi Cluster Ketersediaan Tinggi

Direproduksi dengan izin dari Clusteringformortals.

Dengan senang hati saya umumkan bahwa Windows IT Pro telah memberikan SteelEye DataKeeper Cluster Edition sebagai Produk Ketersediaan dan Pemulihan Bencana Terbaik dalam dua kategori; Penghargaan Emas Pilihan Komunitas dan Penghargaan Perak Terbaik dari para editor.

Saya sangat bangga menjadi bagian dari tim SteelEye DataKeeper dan saya menghargai semua komunitas Windows IT Pro yang memilih kami dalam penghargaan Community Choice!

Direproduksi dengan izin dari https://clusteringformeremortals.com/2009/11/20/steeleye-datakeeper-cluster-edition-wins-windows-it-pro-best-high-availabilitydisaster-recovery-awards/

Bagaimana Replikasi Asinkron Bisa Digunakan dalam Cluster Multi-Situs? Bukankah Data Out Of Sync?

Saya telah mengajukan pertanyaan ini lebih dari beberapa kali, jadi saya pikir saya akan menjawabnya di posting blog pertama saya.  Jawaban dasarnya adalah ya, Anda bisa kehilangan data dalam kegagalan yang tak terduga saat menggunakan replikasi asinkron dalam cluster multi-situs.  Dalam dunia ideal, setiap perusahaan akan memiliki koneksi serat gelap ke situs DR mereka dan menggunakan replikasi sinkron dengan cluster multi-situs mereka, sehingga menghilangkan kemungkinan kehilangan data.  Namun, kenyataannya adalah bahwa dalam banyak kasus, konektivitas WAN ke situs DR memiliki latency terlalu banyak untuk mendukung replikasi sinkron.  Dalam kasus tersebut, replikasi asinkron adalah alternatif yang sangat baik.

Apa Pilihan Saya?

Ada lebih dari beberapa opsi ketika memilih solusi replikasi asinkron untuk digunakan dengan klaster multi-situs WSFC Anda. Ini termasuk solusi berbasis array dari perusahaan seperti EMC, IBM, HP, dll. dan solusi berbasis host, seperti yang dekat dan saya sukai, "SteelEye DataKeeper Cluster Edition".  Karena saya mengenal DataKeeper dengan baik, saya akan menjelaskan bagaimana semua ini bekerja dari calon DataKeeper.

Bagaimana dengan SteelEye DataKeeper?

Saat menggunakan SteelEye DataKeeper dan replikasi asinkron, kami mengizinkan sejumlah penulisan untuk disimpan dalam antrian asinkron.  Jumlah penulisan yang dapat antri ditentukan oleh "tanda air tinggi". Ini adalah nilai yang dapat disesuaikan yang digunakan oleh DataKeeper untuk menentukan berapa banyak data yang bisa berada dalam antrian sebelum kondisi mirror diubah dari "mirroring" menjadi "dijeda".  Status "dijeda" juga dimasukkan kapan saja ada kegagalan komunikasi antara server sekunder dan primer. Sementara dalam keadaan berhenti, failover otomatis di cluster multi-situs dinonaktifkan, sehingga membatasi jumlah data yang dapat hilang dalam kegagalan yang tidak terduga.  Jika kumpulan data asli dianggap "hilang selamanya", maka data yang tersisa pada server target dapat dibuka secara manual dan node cluster kemudian dapat dibawa ke layanan.

Saat berada dalam keadaan "berhenti sejenak", DataKeeper mengizinkan antrian asinkron mengalir sampai mencapai "tanda air rendah", dan pada saat mana cermin memasuki keadaan "resync" sampai semua data sekali lagi sinkron.  Pada saat itu, cermin sekali lagi berada dalam keadaan "mirroring" dan failover otomatis sekali lagi diaktifkan.

Selama link WAN Anda tidak jenuh atau rusak, Anda seharusnya tidak pernah melihat lebih dari beberapa menulis pada waktu tertentu dalam antrian asinkron ini.   Dalam kegagalan yang tak terduga (pikirkan kabel daya yang ditarik) Anda akan kehilangan tulisan yang ada di antrian asinkron.  Ini adalah trade off yang Anda buat ketika Anda menginginkan tujuan titik pemulihan yang mengagumkan (RPO) dan tujuan waktu pemulihan (RTO) yang Anda capai dengan cluster multi-situs, namun tautan WAN Anda memiliki latensi terlalu banyak untuk mendukung replikasi sinkron secara efektif.

Coba The SteelEye DataKeeper

Luangkan waktu untuk memantau Antrian DataKeeper Async melalui Windows Performance Logs and Alerts. Saya pikir Anda akan terkejut menemukan bahwa sebagian besar waktu antrian async kosong karena efisiensi mesin replikasi DataKeeper.  Bahkan di masa-masa penulisan yang berat, antrian async jarang tumbuh sangat besar dan selalu terkuras segera. Jadi jumlah data yang berisiko pada waktu tertentu minimal.  Dibandingkan dengan alternatif dalam bencana untuk dipulihkan dari cadangan semalam, jumlah penulisan yang bisa Anda hilangkan dalam kegagalan tak terduga menggunakan replikasi asinkron sangat minim!

Tentu saja, ada beberapa kasus di mana bahkan kehilangan satu menulis pun tidak dapat ditolerir.  Dalam kasus tersebut, disarankan untuk menggunakan opsi replikasi sinkron SteelEye DataKeeper di koneksi LAN latency berkecepatan tinggi dan rendah.

Diproduksi ulang dengan izin dari Clusteringformeremortals.com