Windows Server 2012 | SIOS SANless clusters

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

September 10, 2018 by Jason Aw Leave a Comment

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^ake-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^tdata 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^kmempertahankan 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

Clustering Windows Server 2012 Langkah-demi-Langkah

Februari 8, 2018 by Jason Aw Leave a Comment

Langkah Dasar Dari Setiap Cluster

Artikel ini adalah yang pertama dari serangkaian artikel tentang Clustering Windows Server 2012. Artikel pertama ini membahas dasar-dasar langkah pertama dari setiap cluster, terlepas dari apakah Anda mengelompokkan Hyper-V, SQL Server Failover Clusters, File Servers, iSCSI Target Server atau lainnya. Artikel mendatang akan mencakup petunjuk yang lebih terperinci untuk setiap jenis sumber gugus cluster, namun informasi berikut berlaku untuk SEMUA kelompok.

Saya berasumsi bahwa Anda tahu sedikit tentang kelompok dan mengapa Anda ingin membangunnya, jadi saya tidak akan membahas rincian ini di pos ini. Saya juga menganggap Anda sudah familiar dengan Windows Server 2012 dan hal-hal mendasar seperti DNS, AD, dll. Perlu dicatat juga bahwa pada pengelompokkan failover Windows Server 2012 hadir dengan setiap edisi, tidak seperti Windows Server 2008 R2 dan sebelumnya dimana failover clustering hanya disertakan dalam Edisi Enterprise dan di atas.

Fokus pada cluster 2-node dasar

Seri khusus ini akan berfokus pada cluster 2-node dasar, di mana kita memiliki dua server (bernama PRIMARY and SECONDARY) yang menjalankan Windows Server 2012 di Domain Windows Server 2012 (pengontrol domain bernama DC). Ini juga mengasumsikan bahwa PRIMER dan SEKUNDER dapat berkomunikasi satu sama lain melalui dua koneksi jaringan yang telah saya beri label PUBLIK dan PRIBADI. Dalam skenario produksi, koneksi jaringan ini harus berjalan melalui peralatan jaringan yang sama sekali berbeda (switch, router, dll) untuk menghilangkan satu titik kegagalan.

Ayo mulai! Clustering Windows Server 2012, ini dia!

Seri ini akan ditulis dengan gaya langkah-demi-langkah yang sangat mendasar yang menuntun Anda melalui proses dalam daftar terurut dengan instruksi dasar dan banyak tangkapan layar untuk membantu menggambarkan prosedur bila diperlukan. Jadi mari kita mulai dari awal …

Tambahkan Failover Clustering Feature pada semua server yang ingin Anda tambahkan ke cluster
1. Buka Dasbor Pengelola Server (langkah pertama ini perlu diselesaikan pada PRIMARY dan SECONDARY)
2. Klik pada Add role and features
3. Pilih penginstalan berbasis peran atau berbasis fitur
4. Pilih server yang Anda inginkan untuk mengaktifkan fitur cluster failover
5. Lewati halaman Server Roles
6. Pada halaman Features pilih Failover Clustering dan klik Next lalu konfirmasikan pemasangannya
Sebelum kita mulai mengkonfigurasi cluster, kita perlu mempertimbangkan jenis penyimpanan yang akan digunakan cluster. Biasanya kluster akan menggunakan semacam SAN, namun dengan Windows 2012 tidak semua cluster akan menggunakan SAN. Misalnya, jika Anda sedang membangun sebuah cluster untuk mendukung SQL Server AlwaysOn Availability Groups penyimpanan Anda akan direplikasi oleh SQL Server, sehingga menghilangkan kebutuhan akan SAN. Selain itu, dengan SMB 3.0 didukung sebagai penyimpanan cluster untuk Hyper-V dan SQL Server, Anda mungkin tidak memiliki SAN tradisional untuk penyimpanan. Dan jangan lupa mengelompokkan Ruang Penyimpanan dengan drive SAS bersama juga kemungkinan terjadi pada Windows Server 2012. Selain pilihan yang disebutkan di atas, Anda juga bisa menggunakan disk lokal dan solusi replikasi berbasis host dari pihak ke-3 seperti DataKeeper Cluster Edition yang merupakan alternatif bagus yang saya blogkan cukup sering. Untuk keperluan posting ini untuk berbagi tentang Clustering Windows Server 2012 , Saya akan menganggap Anda tidak memiliki penyimpanan bersama. Namun, jika Anda memiliki penyimpanan bersama pada saat ini, Anda harus mengkonfigurasi penyimpanan Anda sehingga LUN Anda diukir dan dibagi dengan masing-masing node cluster dengan satu LUN digunakan sebagai saksi disk dan LUN yang tersisa dapat digunakan. untuk aplikasi yang ingin anda cluster. Sebagai pengganti kesaksian disk untuk kuorum kami, saya akan menggunakan sebuah simpul dan berkas berbagi jenis kuorum saksi yang akan saya jelaskan nanti.
Sekarang Failover Clustering diaktifkan pada setiap server, Anda dapat membuka Failover Cluster Manager di server PRIMER Anda. Hal pertama yang ingin kita lakukan adalah menjalankan "Validasi Konfigurasi" sehingga kita dapat mengidentifikasi setiap masalah potensial sebelum kita memulai. Klik pada Validasi Cluster
Langkah melalui Memvalidasi Wizard Konfigurasi seperti yang ditunjukkan pada langkah-langkah berikut.
1. Pilih server yang ingin dikelompokkan
2. Jalankan semua tes (tergantung pada peran apa yang telah Anda instal di server Anda mungkin mendapatkan lebih banyak atau sedikit tes. Misalnya, jika Hyper-V diaktifkan, ada tes spesifik Hyper-V yang baru untuk cluster)
3. Dengan asumsi klanda Anda "lulus" validasi Anda harus memiliki laporan yang terlihat serupa dengan saya. Anda akan melihat bahwa laporan saya berisi "peringatan" namun tidak ada kesalahan. Penting bagi Anda untuk melihat laporan dan memahami peringatan apa yang mungkin ada, tapi Anda selama Anda memahami peringatan dan mereka masuk akal untuk lingkungan khusus Anda yang dapat Anda pindahkan. Jika Anda validasi "gagal", Anda HARUS memperbaiki kegagalan sebelum melanjutkan. Klik Lihat Laporan untuk melihat laporan
4. Anda akan melihat semua peringatan saya terkait dengan penyimpanan, jadi saya tidak khawatir karena saya belum mengkonfigurasi penyimpanan bersama apa pun, jadi saya akan mengharapkan beberapa dari thests ini menghasilkan peringatan.

Setelah Validasi selesai tanpa kesalahan, Anda akan secara otomatis dilemparkan ke dalam Wizard Buat Cluster. Berjalanlah melalui wizard ini seperti yang ditunjukkan di bawah ini untuk membuat cluster dasar Anda.
1. Di layar pertama ini Anda akan memilih nama untuk cluster Anda dan memilih alamat IP yang akan dikaitkan dengan nama ini di DNS. Nama ini hanya nama yang digunakan untuk mengelola cluster Anda – ini BUKAN nama yang akan digunakan klien Anda untuk terhubung ke sumber berkerumun yang pada akhirnya akan Anda buat. Setelah Anda membuat jalur akses ini, objek komputer baru akan dibuat pada AD dengan nama ini dan sebuah record DNS A akan dibuat dengan nama dan alamat IP ini.
2. Pada layar konfirmasi Anda akan melihat nama dan alamat IP yang Anda pilih. Anda juga akan melihat opsi yang baru dengan pengelompokkan failover Windows Server 2012 … "Tambahkan semua penyimpanan yang layak ke cluster". Secara pribadi saya tidak yakin mengapa ini dipilih secara default, karena opsi ini benar-benar dapat membingungkan banyak hal. Secara default, pilihan ini akan menambahkan semua penyimpanan bersama (jika Anda memilikinya dikonfigurasi) ke cluster, tapi saya juga melihatnya menambahkan disk lokal dan non-shared ke cluster juga. Saya kira mereka ingin membuatnya mudah untuk mendukung penyimpanan simetris, namun umumnya solusi berbasis host atau berbasis array replikasi akan memiliki beberapa petunjuk yang cukup spesifik tentang bagaimana menambahkan penyimpanan simetris ke cluster dan umumnya opsi ini untuk menambahkan semua disk ke cluster lebih merupakan penghalang daripada bantuan ketika sampai pada penyimpanan asimetris. Untuk kasus kami, karena saya tidak memiliki penyimpanan bersama yang dikonfigurasi dan saya tidak ingin cluster menambahkan disk lokal ke cluster untuk saya secara otomatis, saya tidak mencentang penyimpanan Tambahkan semua yang memenuhi syarat ke opsi klaster.
3. Setelah Anda klik next, Anda akan melihat bahwa cluster telah menyelesaikan proses pembuatannya, namun mungkin ada beberapa peringatan. Dalam kasus kami, peringatan mungkin terkait dengan konfigurasi kuorum yang akan kami jaga pada langkah selanjutnya. Klik Lihat Laporan untuk melihat peringatan apa pun.
  
  Anda melihat bahwa peringatan itu digunakan untuk mengubah jenis kuorum.
Karena kita tidak memiliki penyimpanan bersama, kita tidak akan menggunakan kuota Node dan Disk Majority seperti yang disarankan. Sebagai gantinya, kita akan menggunakan dan Node dan File Share Majority quorum. Langkah-langkah berikut akan membantu kita mengkonfigurasi Node dan File Majority Quorum
1. File Share Witness perlu dikonfigurasi pada server yang bukan bagian dari cluster. Saksi berbagi file adalah file sharing dasar bahwa nama komputer cluster (MYCLUSTER dalam kasus kami) telah membaca / menulis akses. Langkah pertama melibatkan pembuatan file share ini. Dalam contoh kita, kita akan membuat file share di DC kita dan memberi MYCLUSTER akses baca / tulis untuknya.
2. Berbagi file tidak perlu berada pada server Windows 2012, namun perlu berada di Server Windows di domain yang sama dengan cluster. Yang penting untuk diingat adalah bahwa nama komputer cluster yang kita buat membutuhkan akses baca / tulis baik pada level share maupun level NTFS. Berikut adalah beberapa screen shot yang memandu Anda melalui proses ini di server DC yang menjalankan Windows Server 2012 di lab saya.
3. Sekarang kita memiliki share file yang dibuat di DC, kita akan kembali ke PRIMARY dan menggunakan Failover Cluster Manager untuk mengubah tipe kuorum seperti yang ditunjukkan pada langkah-langkah berikut.
  
  Jika kebetulan wizard ini gagal, kemungkinan besar terkait dengan hak akses pada file share. Pastikan Anda memberi nama komputer cluster baca / tulis izin di KEDUA tingkat berbagi file dan keamanan (NTFS) dan coba lagi.
Anda sekarang memiliki cluster 2-node dasar dan siap untuk beralih ke langkah berikutnya dari seri Clustering Windows Server 2012 yang menciptakan sumber daya cluster Anda. Saya akan menerbitkan serangkaian artikel tentang cara mengelompokkan sumber daya yang berbeda, dimulai dengan SQL 2012 di posting berikutnya.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2012/12/31/windows-server-2012-clustering-step-by-step/

Datakeeper Cluster Edition 7.5 Sekarang Mendukung Windows Server 2012

Februari 7, 2018 by Jason Aw Leave a Comment

Manfaat Menggunakan Data Cluster DataKeeper

Berita bagus untuk Anda pengadopsi awal Windows Server 2012 – Anda sekarang dapat menggunakan DataKeeper Cluster Edition dengan Windows Server 2012. Saya akan memposting beberapa artikel Step-by-Step Windows Server 2012 sebelum akhir tahun dan pasti akan menyertakan beberapa contoh cluster multisite juga. Sementara itu, jika Anda ingin membangun cluster berdasarkan Windows Server 2012 dan ingin menghilangkan penyimpanan bersama sebagai satu titik kegagalan atau Anda ingin meregangkan cluster Anda melintasi lokasi geografis, Anda dapat melakukannya dengan DataKeeper Cluster Edition v7.5.