Mengintegrasikan Replikasi Penyimpanan Dengan Clustering Failover

Pada Bagian 1 dari seri ini, kami melihat langkah pertama yang diperlukan untuk membangun cluster multi-situs. Kami sampai pada titik di mana kami memiliki dua cluster simpul yang menggunakan kuota kuota simpang dan kuota file saham, tanpa sumber daya yang belum ditentukan.

Ayo lanjutkan

Pada bagian ini kita akan mulai dari mana kita tinggalkan dan melihat bagaimana solusi replikasi Anda akan berintegrasi dengan failover clustering Anda. Karena setiap solusi replikasi vendor akan diterapkan secara berbeda, sulit untuk memiliki satu dokumen yang menggambarkan semuanya. Yang penting untuk diingat adalah bahwa Anda ingin membeli solusi replikasi yang terintegrasi dengan pengelompokan failover dan disertifikasi oleh Microsoft. Pilihan Anda pada dasarnya didasarkan pada berbasis, berbasis alat atau solusi replikasi berbasis host. EMC membuat solusi replikasi berbasis alat dan berbasis array dan tampaknya melakukan pekerjaan yang bagus pada keduanya. John Toner dari EMC mengelola sebuah blog yang didedikasikan untuk Geographically Dispersed Clusters dan jika Anda menuju rute EMC, saya yakin dia bisa mengarahkan Anda ke arah yang benar. Semua vendor utama memiliki solusi, Anda hanya perlu menghubungi mereka untuk mendapatkan rinciannya.

SIOS DataKeeper

Untuk demonstrasi ini, saya akan menggunakan solusi replikasi berbasis host, SteelEye DataKeeper Cluster Edition, dari perusahaan saya, SteelEye Technology. Ini sangat mudah, yang saya pikir alih-alih mengerjakan artikel panjang, saya hanya akan mencatat langkah-langkahnya dan membaginya dengan Anda dalam sebuah video. Salah satu kelebihan replikasi berbasis host adalah Anda dapat memanfaatkan penyimpanan yang ada, apakah hanya disk lokal terpasang, iSCSI atau SAN yang mahal. Replikasi berbasis host dapat mereplikasi di semua perangkat penyimpanan.

Berikut adalah ringkasan dari apa yang akan Anda lihat di video.

• Luncurkan Snap-in MMC Snap-in SteelEye DataKeeper
  • Buat pekerjaan DataKeeper baru, tentukan titik akhir cermin, jaringan, kompresi, dll.
• Luncurkan Snap-in MMC Failover Cluster
  • Buat sumber Hyper-V
  • Tambahkan Sumber DataKeeper Volume Resource
  • Edit properti sumber Volume DataKeeper untuk mengaitkannya dengan cermin yang dibuat sebelumnya
  • Buatlah konfigurasi Mesin Virtual bergantung pada sumber volume DataKeeper yang baru

Itu dia! Kamu sekarang sudah selesai Duduklah kembali dan nikmati cluster multi-situs baru Hyper-V Anda.

KLIK UNTUK MENONTON VIDEO

Pada Bagian 3 dari seri ini, kita akan menangani cluster multi-situs SQL 2008 di Windows Server 2008 R2. Ada beberapa langkah lagi dan beberapa tip dan trik yang pasti perlu Anda ketahui, jadi pastikan Anda mengecek kembali untuk mendapatkan semua detailnya. Sementara itu, jika Anda membutuhkan bantuan, tinggalkan saya komentar atau hubungi saya melalui SIOS dan saya senang membantu Anda.

 PENGANTAR

Selamat Datang di Bagian 1 dari seri saya "Langkah demi Langkah: Mengonfigurasi cluster multi-situs 2-node di Windows Server 2008 R2". Sebelum kita terjun ke detail, mari luangkan waktu sejenak untuk mendiskusikan apa sebenarnya cluster multi-situs dan mengapa saya ingin menerapkannya. Microsoft memiliki halaman web dan kertas putih yang bagus yang ingin Anda download untuk mendapatkan semua detail, jadi saya tidak akan mengulangi semuanya di sini. Tapi pada dasarnya cluster multi-situs adalah solusi pemulihan bencana dan solusi ketersediaan tinggi semuanya digulirkan menjadi satu. Cluster multi-situs memberi Anda titik pemulihan tertinggi (RTO) dan tujuan waktu pemulihan (RTO) yang tersedia untuk aplikasi penting Anda. Dengan diperkenalkannya cluster failover Windows Server 2008 clustering multi-situs telah menjadi jauh lebih layak dengan diperkenalkannya failover subnet cross dan dukungan untuk komunikasi jaringan latency yang tinggi.

Saya sebutkan "cross-subnet failover" sebagai fitur baru yang hebat dari Windows Server 2008 Failover Clustering, dan ini adalah fitur baru yang hebat. Namun, SQL Server belum memeluk fungsi ini, yang berarti Anda masih perlu untuk membagi subnet Anda di seluruh situs di cluster multi-situs SQL Server. Pada Tech-Ed 2009, tim SQL Server melaporkan bahwa mereka berencana untuk mendukung fitur ini, namun mereka mengatakan akan datang suatu saat setelah SQL Server 2008 R2 dilepaskan. Untuk masa yang akan datang Anda akan terjebak dengan mencakup subnet Anda di situs dalam cluster multi-situs SQL Server. Ada beberapa masalah terkait jaringan lain yang perlu Anda pertimbangkan juga, seperti jalur komunikasi yang berlebihan, penempatan sampel bandwidth dan file share.

PERTIMBANGAN JARINGAN

Semua cluster failover Microsoft harus memiliki jalur komunikasi jaringan yang berlebihan. Hal ini memastikan bahwa kegagalan salah satu jalur komunikasi tidak akan menghasilkan failover palsu dan memastikan bahwa cluster Anda tetap sangat tersedia. Sebuah cluster multi-situs memiliki persyaratan ini juga, jadi Anda pasti ingin merencanakan jaringan Anda dengan itu. Biasanya ada dua hal yang harus dilakukan antar node: lalu lintas replikasi dan detak jantung cluster. Selain itu, Anda juga perlu mempertimbangkan konektivitas klien dan aktivitas pengelolaan cluster. Anda pasti ingin memastikan bahwa jaringan apa pun yang Anda miliki, Anda tidak terlalu banyak menggunakan jaringan atau Anda akan memiliki perilaku yang tidak dapat diandalkan. Lalu lintas replikasi Anda kemungkinan besar memerlukan jumlah bandwidth paling banyak; Anda perlu bekerja sama dengan vendor replikasi Anda untuk menentukan berapa banyak bandwidth yang dibutuhkan.

Dengan jalur komunikasi berlebihan Anda, hal terakhir yang perlu Anda pertimbangkan adalah model kuorum Anda. Untuk konfigurasi cluster multi-situs 2-node, konfigurasi yang direkomendasikan Microsoft adalah kuota Node dan File Share Mayity. Untuk penjelasan rinci tentang jenis kuorum, lihat artikel ini.

Penyebab kerancuan yang paling umum dengan kuota Node dan File Share Mayity adalah penempatan File Share Witness. Di mana saya harus meletakkan server yang menjadi tuan rumah berbagi file? Mari kita lihat pilihannya.

OPSI 1 – TEMPAT FILE BERBAGI DI SITUS UTAMA.

Ini tentu opsi yang valid untuk pemulihan bencana, namun tidak begitu banyak untuk ketersediaan tinggi. Jika seluruh situs gagal (termasuk node Primer dan saksi berbagi file) node Sekunder di situs sekunder tidak akan masuk ke layanan secara otomatis, Anda perlu memaksa kuorum secara online secara manual. Ini karena akan menjadi satu-satunya suara yang tersisa di cluster. Satu dari tiga tidak membuat mayoritas! Sekarang jika Anda dapat hidup dengan langkah manual yang terlibat dalam pemulihan jika terjadi bencana, maka konfigurasi ini mungkin baik untuk Anda.

OPSI 2 – TEMPAT FILE BERBAGI DI SITUS SEKUNDER.

Ini bukan ide bagus. Meskipun memecahkan masalah pemulihan otomatis jika terjadi kehilangan situs secara lengkap, hal itu akan menghadapkan Anda pada risiko failover palsu. Pertimbangkan ini … apa yang terjadi jika situs sekunder Anda turun? Dalam kasus ini, server utama Anda (Node1) juga akan pergi offline karena sekarang hanya ada satu node di situs utama dan tidak akan lagi memiliki mayoritas simpul. Saya tidak melihat alasan bagus untuk menerapkan konfigurasi ini karena terlalu banyak risiko yang terlibat.

OPSI 3 – TEMPAT SAHAM SAHAM FILE DI LOKASI GEOGRAFI 3RD

Ini adalah konfigurasi pilihan karena memungkinkan failover otomatis jika terjadi kehilangan situs secara lengkap dan menghilangkan kemungkinan kegagalan situs sekunder yang menyebabkan simpul utama offline. Dengan memiliki host situs 3, saksi berbagi file Anda telah menghapus satu situs sebagai satu titik kegagalan, jadi sekarang cluster akan bertindak seperti yang Anda harapkan dan failover otomatis jika terjadi kehilangan situs. Mengidentifikasi lokasi geografis ke-3 dapat menjadi tantangan bagi beberapa perusahaan, namun dengan munculnya komputasi utilitas berbasis awan seperti Amazon EC2 dan GoGrid, ada baiknya menjangkau semua perusahaan untuk memberi kesaksian berbagi file di awan dan memiliki ketahanan yang diperlukan. untuk cluster multi-situs yang efektif. Sebenarnya, Anda mungkin menganggap awan itu sendiri sebagai pusat data sekunder Anda dan hanya gagal menuju awan jika terjadi bencana. Saya pikir kemungkinan komputasi berbasis cloud dan konfigurasi pemulihan bencana sangat menarik dan sebenarnya saya berencana untuk melakukan keseluruhan posting blog dengan cara yang tepat dalam waktu dekat.

CONFIGURE CLUSTER

Sekarang kita memiliki dasar-dasarnya, mari kita mulai dengan konfigurasi cluster yang sebenarnya. Anda ingin menambahkan fitur Failover Clustering ke kedua simpul cluster Anda. Demi kesederhanaan, saya telah memanggil node saya PRIMER dan SEKUNDER. Hal ini dilakukan dengan sangat mudah melalui Add Features Wizard seperti yang ditunjukkan di bawah ini.

Selanjutnya Anda akan ingin melihat koneksi jaringan Anda. Sebaiknya Anda mengganti nama koneksi di masing-masing server untuk mencerminkan jaringan yang mereka wakili. Ini akan membuat segalanya lebih mudah diingat nanti.

Anda juga ingin masuk ke Pengaturan Lanjutan Sambungan Jaringan Anda (tekan Alt untuk melihat menu Setelan Tingkat Lanjut) dari masing-masing server dan pastikan Jaringan publik pertama ada dalam daftar.

Jaringan pribadi Anda hanya boleh berisi alamat IP dan subnet mask. Tidak ada Gateway atau server DNS default yang harus didefinisikan. Simpul Anda harus dapat berkomunikasi di seluruh jaringan ini, jadi pastikan server dapat berkomunikasi di jaringan ini; tambahkan rute statis jika perlu.

Setelah Anda mengkonfigurasi jaringan Anda, Anda siap untuk membangun cluster Anda. Langkah pertama adalah "Validasi Konfigurasi". Buka Failover Cluster Manager dan klik Validasi a Configuration.

Wisaya Validasi meluncurkan dan menampilkan layar pertama seperti yang ditunjukkan di bawah ini. Tambahkan dua server di cluster Anda dan klik Next untuk melanjutkan.

Cluster multi-situs tidak perlu melewati validasi penyimpanan (lihat artikel Microsoft). Toskip proses validasi penyimpanan, klik "Jalankan hanya tes yang saya pilih" dan klik Continue.

Di layar uji coba, batalkan pilihan Penyimpanan dan klik Berikutnya

Anda akan disuguhkan dengan layar konfirmasi berikut. Klik Next untuk melanjutkan.

Jika Anda telah melakukan semuanya dengan benar, Anda harus melihat halaman ringkasan yang terlihat seperti berikut ini. Perhatikan bahwa tanda seru kuning menunjukkan bahwa tidak semua tes dijalankan. Ini diharapkan terjadi di cluster multi-situs karena tes penyimpanan dilewati. Selama semuanya beres OK, Anda bisa melanjutkan. Jika laporan menunjukkan adanya kesalahan lain, perbaiki masalah, jalankan kembali tes, dan lanjutkan.

Anda sekarang siap untuk membuat cluster Anda. Di Failover Cluster Manager, klik Create a Cluster.

Langkah selanjutnya bertanya apakah Anda ingin memvalidasi cluster Anda atau tidak. Karena Anda telah melakukannya, Anda bisa melewati langkah ini. Catatan ini akan menimbulkan sedikit masalah di kemudian hari jika menginstal SQL karena akan mengharuskan cluster tersebut lolos validasi sebelum melanjutkan. Ketika kita sampai pada titik itu, saya akan menunjukkan cara untuk melewati pemeriksaan ini melalui opsi baris perintah di setup SQL Server. Untuk saat ini, pilih No dan Next.

Langkah selanjutnya adalah Anda harus membuat nama untuk cluster dan IP ini untuk mengelola cluster ini. Ini akan menjadi nama yang akan Anda gunakan untuk mengelola cluster, bukan nama sumber cluster SQL yang akan Anda buat nanti. Masukkan nama dan alamat IP yang unik dan klik Next.

Catatan: Ini juga nama komputer yang memerlukan izin ke File Share Witness seperti yang dijelaskan kemudian dalam dokumen ini.

Konfirmasikan pilihan Anda dan klik Next.

Selamat, jika Anda telah melakukan semuanya dengan benar, Anda akan melihat halaman Ringkasan berikut. Perhatikan tanda seru kuning; Jelas sesuatu tidak sempurna. Klik Lihat Laporan untuk mencari tahu apa masalahnya.

Jika Anda melihat laporannya, Anda harus melihat beberapa baris yang terlihat seperti ini.

Jangan resah; Hal ini diharapkan terjadi dalam cluster multi-situs. Ingat kita katakan sebelumnya bahwa kita akan menerapkan kuota Node dan File Share Mayity. Kami akan mengubah tipe kuorum dari Cluster Node Mayoritas saat ini (bukan ide bagus di cluster dua node) ke kuota Node dan File Share Mayity.

MELAKSANAKAN KINERJA NAMA DAN FILE

Pertama, kita perlu mengidentifikasi server yang akan menahan saksi File Share kita. Ingat, seperti yang telah kita bahas sebelumnya, saksi File Share ini harus berada di lokasi ke-3, dapat diakses oleh kedua node cluster. Setelah Anda mengidentifikasi server, bagikan folder seperti biasanya Anda akan berbagi folder. Dalam kasus saya, saya membuat share yang disebut MYCLUSTER di server bernama DEMODC.

Hal utama yang harus diingat tentang bagian ini adalah Anda harus memberi nama komputer cluster untuk membaca / menulis izin ke bagian di tingkat Share dan izin tingkat NTFS. Jika Anda ingat kembali pada Gambar 13, saya membuat cluster saya dan memberikannya nama "MYCLUSTER". Anda perlu memastikan bahwa Anda memberi izin akun baca / tulis komputer cluster seperti yang ditunjukkan pada gambar layar berikut.

Sekarang dengan folder bersama di tempat dan izin yang sesuai ditugaskan, Anda siap untuk mengubah jenis kuorum Anda. Dari Failover Cluster Manager, klik kanan pada cluster Anda, pilih More Action dan Configure Cluster Quorum Settings.

Pada layar berikutnya pilih Node dan File Share Mayoritas dan klik Next.

Di layar ini, masukkan path ke file sharing yang telah Anda buat sebelumnya dan klik Next.

Konfirmasikan bahwa informasinya benar dan klik Next.

Dengan asumsi Anda melakukan segalanya dengan benar, Anda harus melihat halaman Ringkasan berikut.

Sekarang ketika Anda melihat cluster Anda, Konfigurasi Kuorum harus mengatakan "Node and File Share Mayity" seperti yang ditunjukkan di bawah ini.

Langkah-langkah yang telah saya sampaikan sampai titik ini berlaku untuk cluster multi-situs, apakah itu SQL, Exchange, File Server atau jenis failover cluster lainnya. Langkah selanjutnya dalam membuat cluster multi-situs melibatkan integrasi solusi penyimpanan dan replikasi Anda ke dalam cluster failover. Langkah ini akan bervariasi tergantung pada solusi replikasi Anda, jadi Anda benar-benar perlu berhubungan dekat dengan vendor replikasi Anda untuk melakukannya dengan benar. Dalam Bagian 2 dari seri saya, saya akan menggambarkan bagaimana SteelEye DataKeeper Cluster Edition terintegrasi dengan Windows Server Failover Clustering untuk memberi gambaran tentang bagaimana salah satu solusi vendor replikasi bekerja.

Bagian lain dari seri ini akan menjelaskan secara rinci bagaimana menginstal SQL, File Server dan Hyper-V di cluster multi-situs. Saya juga akan memiliki sebuah posting mengenai pertimbangan untuk cluster multi-node dari tiga atau lebih node.

Dengan diluncurkannya Windows Server 2008 R2, salah satu perangkat tambahannya adalah meningkatkan performa file VHD dinamis. Sebelum R2, menulis untuk secara dinamis memperluas file VHD bisa menjadi 3x lebih lambat daripada menulis ke file VHD ukuran tetap karena keterbatasan data metadata. Secara keseluruhan, Microsoft mengklaim kinerja file VHD dinamis vs ukuran tetap file VHD hampir identik. Disk-through disk adalah pilihan lain saat mengkonfigurasi VM Hyper-V. Menurut hasil saya, kinerja disk pass-through sedikit lebih baik daripada file VHD. Namun, jika Anda menggunakan disk pass-through Anda kehilangan semua manfaat file VHD seperti portabilitas, snap-shotting dan thin provisioning. Mengingat trade-off ini, dengan menggunakan disk pass-through seharusnya benar-benar dipertimbangkan jika Anda memerlukan disk berukuran lebih besar dari 2 TB atau jika aplikasi Anda I / O terikat dan Anda benar-benar bisa mendapatkan keuntungan dari yang lain .1 ms dicukur waktu respon rata-rata anda

Saya pikir daripada mengambil kata Microsoft untuk itu, saya akan menempatkan jenis disk yang berbeda ini untuk ujian bagi diri saya sendiri. Saya membuat mesin virtual Hyper-V Windows Server 2008 R2 yang berjalan di atas Windows Server 2008 R2. Untuk Hypervisor saya, saya menggunakan server Dell PowerEdge 1950 yang terpasang pada SAN Dell AX150 dan mengukir tiga lagu LEM 10 GB untuk digunakan dalam pengujian saya. Di Hyper-V Manager, saya menambahkan tiga disket baru, satu pass-through, satu VHD dinamis dan satu VHD ukuran tetap. Saya kemudian menggunakan IOMeter untuk menguji kinerja disk. Parameter uji dan data mentah dapat ditemukan di file CSV ini.

Bagan di bawah ini meringkas hasil saya. Seperti yang dapat Anda lihat, pada tingkat ekstrem (Maksimum / Minimum), disk pass-through menang dalam banyak kasus. Namun, rata-rata, hampir tidak ada perbedaan antara kinerja dari tiga jenis disk yang berbeda.

 

Manfaat thin provisioning, yang berarti membangun file VHD atau beberapa file VHD dengan ukuran gabungan yang lebih besar dari ruang disk yang tersedia, dan portabilitas file VHD membuat file VHD yang berkembang secara dinamis pilihan yang jelas untuk sebagian besar mesin virtual Windows Server 2008 R2. .

Singkatnya, saya akan sangat mempertimbangkan penggunaan file VHD yang berkembang secara dinamis untuk penyebaran Hyper-V berikutnya pada Windows Server 2008 R2.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2009/09/25/hyper-v-pass-through-disk-performance-vs-fixed-size-vhd-files-and-dynamic-vhd-files-in- windows-server-2008-r2 /