Apakah Replicated Clusters Dengan DataKeeper lebih baik?

Mengapa Cluster Replikasi dengan DataKeeper Lebih Baik dari pada Single Copy SAN Based Clusters?

Jika Anda telah mengikuti sejarah pengelompokan sedekat yang saya miliki selama 10 tahun terakhir sebagai Microsoft Cluster MVP, Anda akan melihat bahwa Microsoft telah terus bergerak menjauh dari kelompok salinan tunggal. Ini dimulai dengan Windows Server 2003 dengan penghapusan kuorum disk bersama dan pengenalan kuorum simpul mayoritas dan saksi berbagi file. Keluhan dengan kelompok berdasarkan kuorum disk bersama adalah bahwa jika kuorum menjadi tidak tersedia atau rusak, seluruh kelompok akan gagal. Ini adalah keluhan utama dan terutama yang memberi pengelompokan nama buruk pada hari-hari awal.

Setelah kuorum disk bersama dieliminasi, orang masih tertinggal dengan data aplikasi mereka yang berada di cluster yang juga menjadi masalah karena SAN masih satu titik kegagalan dalam sebuah cluster, hambatan kinerja dan manajemen sakit kepala. Microsoft telah mulai menangani masalah tersebut dengan diperkenalkannya Exchange 2007 CCR and Exchange 2010 DAGs serta SQL Server 2008 R2 Database Mirroring. Microsoft telah menghapus cluster duplikasi Exchange 2010 sepenuhnya dan cluster duplikat SQL Server hanya masih ada karena mereka belum menyempurnakan replikasi SQL Server.

Pengenalan DataKeeper SIOS

Hyper-V adalah sumber cluster terbaru yang didukung oleh Microsoft clustering yang belum memiliki solusi replikasi terpadu cluster asli. Di sinilah letak SIOS DataKeeper. Kami pertama kali menunjukkan solusi replikasi DataKeeper Hyper-V kami pada peluncuran Microsoft Virtualization pada bulan September tahun 2008 dan telah menyediakan solusi HA dan DR untuk Hyper-V sejak Hyper-V diperkenalkan pertama kali. Solusi kami adalah logo yang disertifikasi untuk Windows Server 2008 R2 dan juga Hyper-V.

Mengapa DataKeeper?

DataKeeper mengisi celah yang ditinggalkan oleh cluster fotokopi tunggal seperti ditunjukkan pada tabel di bawah dan paragraf berikut. Cerita pelanggan berikut juga menyoroti beberapa alasan mengapa orang mengadopsi DataKeeper sebagai pengganti solusi berbasis SAN.

http://www.computerweekly.com/news/2240177361/University-shuns-HP-array-features-for-SIOShost-based-replication

Menghilangkan satu titik kegagalan

SAN adalah entitas tunggal yang terdiri dari potongan-potongan yang berlebihan. Untuk memiliki SAN yang benar-benar berlebihan, Anda memerlukan pengendali berlebihan, catu daya, sakelar CPU, switch, UPS, RAM dan klien yang terhubung dengannya harus memiliki solusi NIC atau HBA yang berlebihan dan solusi multi-jalur yang dikonfigurasi. Bahkan sekali Anda telah menghilangkan perangkat keras sebagai satu titik kegagalan, SAN masih dikendalikan oleh firmware yang merupakan satu titik kegagalan. Dan kemudian karena SAN berada di satu lokasi, setiap bencana fisik (pikirkan air, api, dll.) Juga merupakan risiko.

Kinerja I / O

Dengan spesifikasi disk yang sama, disk yang terpasang secara lokal akan berkinerja lebih baik daripada disk yang tersimpan di SAN yang diakses melalui iSCSI. Selain itu, dengan menggunakan penyimpanan lokal, membuka kemungkinan untuk menggunakan solusi penyimpanan kecepatan lebih tinggi seperti penyimpanan PCIe berbasis flash yang melebihi jumlah SAN yang harganya ratusan ribu dolar di sebagian kecil dari biaya.

Biaya

Anda tidak hanya harus memperhitungkan investasi awal, dimana solusi DataKeeper menang dengan persentase yang signifikan, Anda harus mempertimbangkan biaya yang terus berlanjut yang terkait dengan pemeliharaan, daya dan pendinginan yang diperlukan untuk SAN kelas enterprise manapun.

Mendukung ekspansi masa depan untuk Disaster Recovery

Jika solusi pemulihan bencana menjadi persyaratan di masa depan, solusi DataKeeper dapat dengan mudah mengakomodasi penambahan node Hyper-V tambahan di lokasi yang jauh dalam konfigurasi cluster multisite untuk solusi pemulihan bencana yang kuat termasuk RTO dan RPO terbaik yang tersedia. Solusi SAN akan memerlukan pembelian SAN tambahan, perangkat lunak replikasi dan mungkin bahkan tidak menyertakan integrasi cluster karena hanya ada sedikit solusi yang benar-benar terintegrasi dengan failover clustering dan juga DataKeeper.

Menghilangkan Waktu Mulai Terencana

Dengan solusi cluster berbasis SAN, pemeliharaan pada SAN memerlukan downtime yang direncanakan. Solusi DataKeeper memungkinkan peningkatan rolling, yang berarti downtime yang direncanakan untuk perawatan perangkat keras dieliminasi.

Meringankan manajemen

Administrasi SAN biasanya melibatkan administrator SAN yang terbiasa dengan fitur dan fungsionalitas SAN. Solusi DataKeeper di sisi lain adalah solusi perangkat lunak sederhana yang dikelola oleh administrator Windows Server dan dilengkapi integrasi lengkap dengan Windows Server Failover Clustering, yang berarti manajemen dikendalikan melalui failover cluster, alat yang harus terbiasa dengan sebagian besar Administrator Windows.

Ringkasan

Singkatnya, DataKeeper mampu menyediakan solusi cluster yang jauh lebih tangguh di sebagian kecil dari biaya solusi berbasis SAN.

SQL Server 2012 Alwayson Multisite Failover Cluster Instance White Paper

Membangun SQL Server Multisite Clusters

Berikut adalah kertas putih yang sangat bagus pada SQL Server Multisite Clusters, namun mereka lupa menyebutkan bahwa Anda juga dapat melakukan ini dengan replikasi berbasis host. Sebagai gantinya, mereka menganggap Anda memiliki “dua array penyimpanan enterprise EMC Symmetrix VMAX, satu di setiap situs. Array keduanya dikonfigurasi dengan dua mesin penyimpanan VMAX dan 240 disk drive “.

Bagaimana dengan solusi biaya lebih efektif?

Jika Anda memiliki anggaran satu juta dolar untuk penyimpanan, maju dan bunuh diri. Jika tidak, lihatlah beberapa penyimpanan Fusion-io PCIe Flash dan replikasi berbasis host dengan edisi cluster DataKeeper. Ini lebih cepat daripada SAN di sebagian kecil dari biaya dengan semua ketersediaan. Simak bagaimana Polaris Industries melakukan hal ini http://www.fusionio.com/blog/polaris-sios/

Direproduksi dengan izin dari https://clusteringformeremortals.com/2013/02/05/sql-server-2012-alwayson-multisite-failover-cluster-instance-white-paper/

DataKeeper Cluster Edition untuk Ketersediaan Tinggi SQL Server Di AWS Cloud

Potensi penghematan biaya untuk pindah ke awan hampir tidak mungkin untuk tidak dipertimbangkan. Namun, setelah Anda berhenti menghitung uang yang akan Anda hemat, Anda mulai memikirkan hal-hal seperti keamanan dan ketersediaan dan bertanya-tanya apakah awan itu untuk Anda. Tapi jangan takut, kita punya solusi yang tepat – SIOS Datakeeper Cluster Edition.

Di pusat data tradisional, Anda memiliki kontrol dan dapat menerapkan keamanan dan ketersediaan solusi yang Anda inginkan. Namun, begitu Anda memutuskan untuk memindahkan server Anda ke awan, pilihan Anda bisa menjadi jauh lebih terbatas. Tidak masalah apakah Anda bersama Amazon, Google atau Microsoft, padam di awan bisa dan memang terjadi dan Anda perlu melakukan apapun yang Anda bisa untuk mengurangi risiko tersebut.

Layanan Web Amazon

Mari kita lihat lebih dekat Amazon Web Services (AWS) misalnya. Apa saja pilihan yang Anda miliki untuk memastikan bahwa database SQL Server Anda dapat bertahan dari pemadaman tak terduga? Sementara beberapa aplikasi dapat digunakan dalam konfigurasi seimbang beban di beberapa zona ketersediaan, SQL Server pada umumnya tidak digunakan dalam konfigurasi beban yang seimbang. Apa artinya ini adalah bahwa SQL Server sendiri berada di zona ketersediaan tunggal dan jika zona itu tidak tersedia, keseluruhan tumpukan aplikasi Anda bisa terhenti.

SQL Server 2008 R2 dan keterbatasannya

Jika Anda membaca artikel ini oleh Miles Ward, Anda akan melihat bahwa dengan SQL Server 2008 R2, pilihan ketersediaan Anda cukup terbatas. Dalam artikel di halaman 11, ada bagan bagus yang menjelaskan pilihan HA Anda. Seperti yang akan Anda lihat, pilihannya sangat terbatas dan sebagian besar berada di luar kategori yang akan digambarkan sebagai HA. Log pengiriman, mirroring dan replikasi transaksional cukup banyak satu-satunya pilihan yang Anda miliki, dan mereka lebih merupakan opsi perlindungan data daripada opsi HA. Jika Anda ingin Microsoft failover clustering, Anda akan menemukan diri Anda kurang beruntung karena keterbatasan beberapa jaringan (klien tidak dapat terhubung ke alamat IP yang berkerumun) di AWS dan kurangnya sumber disk bersama yang dibutuhkan untuk cluster SQL tradisional.

AWS

Jika Anda ingin menerapkan SQL Server 2012, pilihan Anda akan sedikit lebih baik. Seperti yang dijelaskan oleh Jeremy Peschka, dengan sedikit intervensi manual, Anda dapat menyebarkan AlwaysOn Availability Groups di AWS untuk melakukan replikasi asinkron dari pusat data Anda ke AWS, atau bahkan di antara kelompok ketersediaan AWS. Tentu ini mengasumsikan Anda memiliki lisensi SQL 2012 Enterprise yang diperlukan untuk AlwaysOn Availability Groups. Satu-satunya "masalah" adalah AWS benar-benar tidak mendukung perpindahan alamat IP cluster dari satu server ke server lainnya, jadi redireksi klien harus dilakukan secara manual menggunakan alamat ec2-unassign-private-ip-address dan ec2-assign-private-ip -menetapkan perintah setelah peralihan yang Peschka jelaskan dalam artikelnya. All-in-all ini adalah proses yang sangat manual, yang sekali lagi tidak sesuai dengan deskripsi sistem yang sangat tersedia.

Solusi untuk Keterbatasannya

Jika Anda dapat hidup tanpa pemulihan otomatis dan dengan keterbatasan AlwaysOn Availability Groups yang saya jelaskan di posting blog sebelumnya, Anda mungkin hanya ingin terus maju dan mencoba penyebaran AlwaysOn Availability Group di AWS. Namun, jika Anda mencari solusi HA yang lebih mudah, lebih terjangkau, lebih kuat, saya memiliki beberapa kabar bagus. SIOS Technology Corp telah melihat masalah ini dan telah mengembangkan solusi yang mengatasi semua keterbatasan yang telah dijelaskan sebelumnya dan akan tersedia sebagai AMI untuk penyebaran yang mudah. Solusi ini saat ini dalam versi beta pribadi, namun akan banyak tersedia akhir tahun ini.

Edisi Cluster Pengumpul Data SIOS

Solusi SIOS didasarkan pada server SQL dalam Microsoft Failover Clustering menggunakan replikasi berbasis DataKeeper Cluster Edition. Dengan menggunakan replikasi berbasis host, mereka telah mengatasi hambatan pertama pengelompokan di EC2 – kurangnya penyimpanan bersama. Hambatan kedua yang harus diatasi SIOS adalah masalah redireksi klien yang dideskripsikan oleh Peschka; jalur akses klien perlu dimanipulasi dari dalam EC2, bukan failover clustering. SIOS telah membangun kecerdasan ke dalam solusi AMI mereka sehingga penugasan kembali alamat IP otomatis sebagai bagian dari proses failover cluster, yang secara efektif mensimulasikan perilaku yang biasanya Anda harapkan dari sebuah cluster.

Dan karena semua ini dibangun di atas failover clustering, ini bisa digunakan menggunakan SQL 2008/2008 R2 atau 2012. Bahkan Edisi Standar SQL Server akan mendukung cluster 2-node sehingga penghematan biaya versus penggelaran SQL 2012 AlwaysOn Availability groups bisa menjadi substansial.

Biarkan aku tahu apa yang Anda pikirkan. Apakah SIOS Datakeeper Cluster Edition terdengar menarik? Apa yang Anda lakukan hari ini untuk memastikan ketersediaan instance SQL Server EC2 Anda?

Direproduksi dengan izin dari https://clusteringformeremortals.com/2013/01/11/sql-server-high-availability-in-aws-cloud/

Clustering SQL Server 2012 Pada Windows Server 2012 dengan DataKeeper

Rekap Kecil

Di posting saya sebelumnya, saya berjalan melalui proses membangun cluster 2-node sampai ke titik di mana kita siap untuk mulai mengelompokkan SQL Server 2012 di Windows Server 2012. Jika Anda telah menyelesaikan langkah-langkah tersebut, Anda siap untuk melanjutkan dan benar-benar membuat aplikasi berkerumun Anda sesuai dengan yang saya sarankan dari SIOS Datakeeper Cluster Edition.

Langkah selanjutnya, clustering SQL Server 2012

Pertama, kita memiliki SQL Server 2012. Instalasi cluster SQL Server 2012 cukup mirip dengan instalasi cluster SQL 2008/2008 R2, jadi sebagian besar akan berlaku meskipun Anda menggunakan SQL 2008/2008 R2. Terminologi seputar SQL Server 2012 Clustering menjadi sedikit berbelit-belit. Anda akan mendengar penyebutan SQL Server AlwaysOn, yang pada dasarnya bisa berarti salah satu dari dua hal yang berbeda: AlwaysOn Availability Groups atau AlwaysOn Failover Cluster Instance. Kebingungan muncul karena kedua solusi memerlukan beberapa tingkat integrasi dengan Windows Server Failover Clustering dan bahkan semakin bingung oleh kenyataan bahwa Anda dapat menerapkan kombinasi AlwaysOn Availability Groups dan AlwaysOn Failover Clustering, tapi itu adalah topik untuk hari lain!

Breaking It Down In Easy-Untuk-Memahami Persyaratan

Intinya AlwaysOn Availability Groups inilah yang biasa disebut Database Mirroring di SQL 2008 R2 dan sebelumnya. Ini memiliki beberapa lonceng baru dan peluit yang mengatasi beberapa keterbatasan versi sebelumnya dari mirroring database, jadi pasti perlu dicoba. AlwaysOn Failover Cluster Instance adalah apa yang biasa disebut SQL Server Failover Cluster. Ini adalah edisi terbaru dari teknologi clustering yang sama yang telah tersedia sejak versi awal dari SQL Server. Salah satu fitur baru terbaik dari SQL Server 2012 AlwaysOn Failover Cluster Instance adalah kemampuan untuk memiliki node pada subnet yang berbeda. Ini adalah batasan utama pada versi sebelumnya dari SQL Server. Dalam entri blog sebelumnya saya membahas beberapa keterbatasan AlwaysOn Availability Groups, Anda harus memeriksanya sebelum membuat keputusan mengenai teknologi mana yang akan digunakan.

Ayo mulai

Dengan mengatakan bahwa, artikel ini akan berfokus pada petunjuk Langkah-demi-Langkah untuk menerapkan SQL Server 2012 AlwaysOn Failover Cluster Instance.

Langkah 1

Pastikan penyimpanan cluster Anda sudah siap. Jika Anda mengikuti petunjuk di posting saya sebelumnya, Anda akan tahu bahwa alih-alih sumber disk bersama, kami akan menggunakan sumber disk yang direplikasi menggunakan perangkat DataCeeper Cluster Edition pihak ke-3. Jika Anda menggunakan penyimpanan bersama dan telah menambahkan penyimpanan daripada yang dapat Anda lewati tepat ke Langkah 2, tempat kami memulai pemasangan SQL. Jika tidak, ikuti langkah-langkah di bawah ini untuk mengkonfigurasi perangkat lunak untuk mereplikasi disk lokal untuk digunakan dalam cluster SQL.

Mengkonfigurasi Data Cluster Cluster

1. Instal dan konfigurasikan DataKeeper Cluster Edition
   1. Jalankan Setup DK
      
   2. Pergi melalui seluruh proses instalasi memilih semua nilai default.
      
      
      
      
      
      
      
      
      
   3. Restart komputer setelah instalasi selesai saat diminta dan ulangi prosesnya di server SECONDARY
   4. Luncurkan UI DataKeeper pada PRIMARY dan klik Connect to Server. Sambungkan ke PRIMARY dan kemudian sambungkan ke SECONDARY
      
      
   5. Klik Create Job dan berjalanlah melalui wizard Create Job untuk membuat cermin dari drive E
      
      
      Pilihlah volume sumber cermin dan alamat IP NIC yang akan membawa lalu lintas replikasi.
      
      Pilih target cermin dan klik Next
      
      Di sini Anda akan memilih pilihan cermin Anda:
      Kompresi – hanya memungkinkan untuk replikasi melintasi WAN
      Asynchronous – pilih ini untuk semua replikasi WAN
      Synchronous – ini sangat ideal untuk replikasi LAN
      Bandwidth maksimum – yang digunakan dalam replikasi WAN sebagai cara untuk memberi cap pada jumlah replikasi bandwidth diperbolehkan digunakan. Umumnya harus dibiarkan pada 0, namun untuk pembuatan cermin awal Anda mungkin ingin membatasi bandwidth sehingga replikasi tidak menggunakan semua bandwidth yang ada untuk melakukan sinkronisasi awal.
      
      Setelah Anda klik Selesai cermin akan dibuat.
      
      Begitu cermin dibuat Anda akan diminta untuk mendaftarkan volume pada Windows Server Failover Clustering (WSFC). Klik Yes dan DataKeeper Volume Resource yang baru akan terdaftar di Available Storage (lihat gambar di Langkah 2).
      

Clustering Windows Server 2012 Langkah-demi-Langkah

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 …

1. 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
      
2. 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.
3. 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
4. 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.
      

1. 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.
      
2. 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.
3. 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/