S2D Untuk SQL Server Failover Cluster Instances 

Ruang Penyimpanan Langsung Untuk SQL Server Failover Cluster Instances

Dengan diperkenalkannya Windows Server 2016 Datacenter Edition, fitur baru yang disebut Storage Spaces Direct (S2D) diperkenalkan. Pada tingkat yang sangat tinggi, S2D For SQL Server Failover Cluster Instances memungkinkan Anda untuk mengumpulkan bersama penyimpanan lokal dan menyajikannya ke cluster sebagai CSV untuk digunakan dalam Scale Out File Server. Kemudian dapat diakses melalui SMB 3 dan digunakan untuk menyimpan data klaster seperti file Hyper-V VMDK. Ini juga dapat dikonfigurasi dalam mode hyper-converged (HCI) sedemikian rupa sehingga aplikasi dan data semua dapat berjalan pada set server yang sama.  Ini adalah deskripsi yang terlalu disederhanakan, tetapi untuk detailnya, Anda akan ingin melihat di sini.

Gambar diambil dari https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview Kasus penggunaan utama yang ditargetkan adalah infrastruktur hyper-converged untuk penyebaran Hyper-V. Namun, ada kasus penggunaan lainnya, termasuk memanfaatkan penyimpanan SMB ini untuk menyimpan Data SQL Server yang akan digunakan dalam SQL Server Failover Cluster Instance

Kenapa ada yang mau melakukan itu?

Nah, sebagai permulaan Anda sekarang dapat membangun SQL Server Failover Cluster Instance 2-node yang sangat tersedia (FCI) dengan SQL Server Standard Edition, tanpa perlu penyimpanan bersama. Sebelumnya, jika Anda ingin HA tanpa SAN Anda cukup terdorong untuk membeli SQL Server Enterprise Edition dan memanfaatkan Always On Availability Groups atau membeli SIOS DataKeeper dan memanfaatkan solusi pihak ke-3 yang memungkinkan Anda membangun cluster SANless dengan versi Windows apa pun atau SQL Server. SQL Server Enterprise Edition benar-benar dapat menaikkan biaya proyek Anda, terutama jika Anda hanya membeli untuk fitur Ketersediaan Grup. Selain biaya yang terkait dengan Grup Ketersediaan, ada sejumlah alasan teknis lainnya mengapa Anda mungkin lebih memilih Failover Cluster daripada AG. Kompatibilitas aplikasi, misalnya terhadap perlindungan tingkat basis data, sejumlah besar basis data, dukungan DTC, staf terlatih, dll., Hanyalah sebagian dari alasan teknis mengapa Anda mungkin ingin tetap menggunakan Mesin Virtual Failover.

SIOS DataKeeper Solusi Vs S2D Untuk SQL Server Failover Cluster Instances 

Microsoft mencantumkan solusi SIOS DataKeeper dan solusi S2D sebagai dua solusi yang didukung untuk SQL Server FCI dalam dokumentasinya di sini. https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr Ketika membandingkan dua solusi, Anda harus mempertimbangkan bahwa SIOS telah memungkinkan Anda membangun Cluster SANAST sejak 1999. Tetapi S2D Untuk SQL Server Failover Cluster Instances masih dalam masa pertumbuhan.  Karena itu, pasti ada beberapa area di mana S2D memiliki beberapa hal yang harus dilakukan. Atau, sekadar fitur yang tidak akan pernah mereka dukung semata-mata karena keterbatasan teknologi.

Sebelum Memilih Solusi Cluster SANless Anda

Silahkan lihat tabel berikut untuk ikhtisar tentang beberapa hal yang harus Anda pertimbangkan sebelum Anda memilih solusi cluster SANless Anda. Jika kita melihat grafik ini, kita melihat bahwa SIOS DataKeeper jelas memiliki beberapa keuntungan yang signifikan. Untuk satu, DataKeeper mendukung berbagai platform yang lebih luas, akan kembali ke Windows Server 2008 R2 dan SQL Server 2008 R2. Solusi S2D hanya mendukung rilis terbaru Windows dan SQL Server 2016/2017. S2D juga membutuhkan Edisi Datacenter Windows, yang dapat menambah biaya penyebaran Anda secara signifikan. Selain itu, SIOS memberikan solusi HANYA HA / DR untuk SQL Server di Linux yang berfungsi baik on-prem maupun di cloud.

Analisis Perbedaan

Tapi di luar batasan biaya dan platform, saya pikir kesenjangan yang paling mencolok datang ketika kita mulai mempertimbangkan opsi pemulihan bencana untuk cluster SANless Anda. Allan Hirt, SQL Server Cluster guru dan sesama Microsoft Cloud dan Manajemen Datacenter MVP, baru-baru ini diposting tentang keterbatasan S2D ini. Dalam artikelnya, Revisiting Storage Spaces Direct dan SQL Server FCIs Allan menunjukkan bahwa karena kurangnya dukungan untuk memperluas cluster S2D di seluruh situs atau termasuk cluster berbasis S2D sebagai kaki dalam Always On Availability Group, pilihan terbaik untuk DR di Skenario S2D adalah pengiriman log! Jangan salah paham. Pengiriman kayu telah ada selamanya dan mungkin akan lama setelah saya pergi. Tapi itu mengambil langkah BESAR mundur ketika kita berpikir tentang semua solusi pemulihan bencana yang telah kita kuasai, seperti kluster multi-situs, Grup Ketersediaan, dll. Sebaliknya, solusi SIOS DataKeeper sepenuhnya mendukung Always On Availability Groups. Lebih baik lagi – ini dapat memungkinkan Anda untuk memperluas FCI Anda di seluruh situs untuk memberikan solusi HA / DR terbaik yang dapat Anda harapkan untuk dicapai dalam hal RTO / RPO. Di lingkungan Azure, DataKeeper juga mendukung Azure Site Recovery (ASR), memberi Anda lebih banyak pilihan untuk pemulihan bencana. Sisa dari grafik ini cukup jelas. Ini pada dasarnya terdiri dari daftar perangkat keras, penyimpanan dan persyaratan jaringan yang harus dipenuhi sebelum Anda dapat menyebarkan gugus S2D. Daftar lengkap persyaratan S2D dipertahankan di sini.  https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIOS Datakeeper. Apa yang baik

Solusi SIOS DataKeeper jauh lebih lunak. Mendukung penyimpanan lokal apa pun dan selama perangkat keras melewati validasi klaster, itu adalah konfigurasi klaster yang didukung. Solusi replikasi block level telah bekerja hebat sejak 1 Gbps dianggap sebagai LAN cepat dan koneksi T1 WAN dianggap mewah. Pemetaan SANless sangat menarik untuk penyebaran cloud. Cloud tidak menawarkan opsi penyimpanan bersama tradisional untuk kluster. Jadi bagi pengguna di tengah "angkat dan bergeser" ke awan yang ingin membawa kelompok mereka dengan mereka, mereka harus melihat solusi penyimpanan alternatif. Untuk penyebaran cloud, SIOS disertifikasi untuk Azure, AWS, dan Google dan tersedia di pasar cloud yang relevan. Meskipun tampaknya tidak ada yang memblokir penyebaran gugus berbasis S2D di Azure atau Google, ada kurangnya dokumentasi atau pernyataan dukungan yang jelas dari Microsoft untuk platform tersebut.

Buat Pilihan yang Aman

SIOS DataKeeper telah melakukan ini sejak tahun 1999. SIOS telah mendengar semua permintaan fitur, menemukan semua bug, dan memiliki solusi padat batuan untuk cluster SANless yang telah teruji dan terbukti. Sementara Microsoft S2D adalah teknologi yang menjanjikan, sebagai produk generasi pertama saya akan menunggu sampai debu mengendap dan beberapa celah fitur menutup sebelum saya mempertimbangkannya untuk aplikasi bisnis penting saya.

Untuk mengetahui lebih lanjut tentang S2D Untuk SQL Server Failover Cluster Contoh, cari di sini SIOS DataKeeper Direproduksi dengan izin dari Clusteringformeremortals.com

SQL Server Failover Instance Cluster Instan di Google Cloud Platform

Cara Membangun Sebuah Instance Cluster Server Instan Sanless Sanless di Google Cloud Platform

Jika Anda akan menjadi tuan rumah SQL Server di Google Cloud Platform (GCP), Anda akan ingin memastikannya sangat tersedia. Salah satu cara terbaik dan paling ekonomis untuk melakukannya adalah dengan membuat Program Cloud Failover Cluster Instan Sanless di Google Cloud Platform.

Hemat Biaya

Karena SQL Server Standard Edition mendukung Failover Clustering, kita dapat menghindari biaya yang terkait dengan SQL Server Enterprise Edition yang diperlukan untuk Always On Availability Groups. Selain itu, SQL Server Failover Clustering adalah solusi yang jauh lebih kuat karena melindungi seluruh contoh SQL Server. Ia tidak memiliki batasan dalam hal dukungan DTC (Distributed Transaction Coordinator) dan lebih mudah untuk dikelola. Plus, mendukung versi SQL Server sebelumnya yang mungkin masih Anda miliki, seperti SQL 2012 melalui SQL 2017 terbaru. Sayangnya, SQL 2008 R2 tidak didukung karena kurangnya dukungan untuk failover lintas-subnet.

Apa yang Berbeda dengan SIOS Datakeeper?

Secara tradisional, SQL Server FCI mengharuskan Anda memiliki SAN atau beberapa jenis perangkat penyimpanan bersama. Di cloud, tidak ada penyimpanan bersama yang sadar-cluster. Sebagai pengganti SAN, kami akan membangun cluster SANless menggunakan SIOS DataKeeper Cluster Edition (DKCE). DKCE menggunakan replikasi blok-level untuk memastikan bahwa penyimpanan yang terpasang secara lokal pada setiap instance tetap sinkron satu sama lain. Ini juga terintegrasi dengan Windows Server Failover Clustering melalui sumber daya penyimpanan kelasnya sendiri yang disebut DataKeeper Volume yang menggantikan sumber disk fisik. Sejauh menyangkut cluster, SIOS DataKeeper volume terlihat seperti disk fisik, tetapi bukannya mengontrol pemesanan SCSI. Ini mengontrol arah cermin, memastikan bahwa hanya server yang aktif menulis ke disk dan bahwa server pasif (s) menerima semua perubahan baik secara sinkron atau asinkron.

Memulai dengan SQL Server Failover Cluster Instance Di Google Cloud Platform

Dalam panduan ini, kita akan berjalan melalui langkah-langkah untuk membangun cluster failover dua-node antara dua instance di wilayah yang sama, tetapi di Zona yang berbeda, dalam GCP seperti yang ditunjukkan pada Gambar 1. Untuk mengetahui lebih lanjut tentang Program Cloud Failover Cluster Instan Sanless di Google Cloud Platform, unduh seluruh kertas putih di https://us.sios.com/sios-resources/white-paper-build-sql-server-failover-cluster-gcp/ Cari tahu lebih lanjut tentang SIOS DataKeeper Direproduksi dengan izin dari Clusteringformeremortals.com

Clailers Failover Ketersediaan Tinggi Untuk MS SQL Server v.Next di Linux

MS SQL Server V.Next Di Linux Dengan Replikasi Dan Ketersediaan Tinggi

Microsoft baru-baru ini merilis preview publik pertama dari MS SQL Server yang berjalan di Linux. Saya bertanya-tanya apa yang akan mereka lakukan untuk ketersediaan tinggi. Mengetahui seberapa eratnya Kelompok-kelompok Ketersediaan AlwaysOn dan Failover Clustering adalah sistem operasi Windows, saya cukup yakin mereka tidak akan menjadi pilihan. Saya benar – Clailers Failover Ketersediaan Tinggi Untuk MS SQL Server v.Next di Linux. Nah, orang-orang di LinuxClustering.Net menjawab pertanyaan saya tentang bagaimana menyediakan gugus failover ketersediaan tinggi untuk MS SQL Server v.Berikutnya di Linux dengan artikel Langkah demi Langkah yang hebat ini. http://www.linuxclustering.net/2016/11/18/step-by-step-sql-server-v-next-for-linux-public-preview-high-availability-azure/ Tidak hanya itu, mereka melakukannya itu semua di Azure yang kami tahu bisa jadi rumit mengingat beberapa keterbatasan jaringan. Saya ingin tahu apakah Anda senang memiliki Clailers Failover Ketersediaan Tinggi Untuk MS SQL Server v.Next di Linux. Atau jika menurut Anda itu hanya sedikit percobaan sains. Untuk yang bersemangat, apa yang dilakukan SQL Server di Linux ke tabel yang tidak memiliki basis data sumber terbuka? Karena Anda suka SQL Server yang banyak, mengapa tidak jalankan saja di Windows? Saya tidak bercanda di sini. Sejujurnya saya ingin tahu apa yang menggairahkan Anda tentang SQL Server di Linux. Saya menantikan komentar Anda. Direproduksi dengan izin dari Clusteringformeremortals.com

Azure Auto Shutdown Untuk Mesin Virtual

Azure Auto Shutdown Untuk Mesin Virtual

Saya mencoba untuk membuat kredit berlangganan Azure MSDN saya meregang sepanjang bulan. Tetapi dengan Azure Auto Shutdown Untuk Mesin Virtual, saraf saya dapat sedikit istirahat. Saya biasanya hanya membangun laboratorium untuk mencoba fitur baru atau untuk menunjukkan SQL Server Failover Clusters di Azure. Banyak waktu saya menguji beberapa ukuran instance yang cukup besar dengan banyak penyimpanan premium. Seperti yang Anda bayangkan, Anda dapat membakar hingga $ 150 cukup cepat dengan beberapa contoh GS5 berjalan. Saya mencoba untuk berhati-hati dan mematikan atau menghancurkan kejadian setelah saya selesai dengan mereka. Terkadang saya akan ditarik untuk urusan lain, hanya untuk masuk keesokan harinya dan melihat kredit saya telah kedaluwarsa karena saya lupa mematikan VM. Saya senang melihat bahwa sekarang sangat mudah untuk mengatur Azure Auto Shutdown Untuk Mesin Virtual. Namun perlu diingat bahwa ini hanya mematikan instance. Jika Anda memiliki penyimpanan premium yang melekat padanya, Anda akan terus membayar Penyimpanan bahkan jika instance dimatikan.

Menerapkan 2-Node File Server Failover Cluster di Azure

Menyebarkan File Server Yang Sangat Tersedia Di Azure IAAS (ARM) dengan SIOS DataKeeper

Dalam posting ini kita akan detail langkah-langkah spesifik yang diperlukan untuk Menyebarkan 2-Node File Server Failover Cluster di Azure dalam satu wilayah Azure menggunakan Azure Resource Manager. Saya akan menganggap Anda akrab dengan konsep Azure dasar serta konsep Failover Cluster dasar. Dalam artikel ini kita akan membahas apa yang unik tentang penggelaran File Server Failover Cluster di Azure. Dengan DataKeeper Cluster Edition Anda dapat mengambil penyimpanan yang terhubung secara lokal, apakah itu Disk Premium atau Standar, dan mereplikasi disk tersebut secara serentak, asinkron atau campuran atau keduanya, antara dua atau lebih node klaster. Selain itu, sumber daya DataKeeper Volume terdaftar di Windows Server Failover Clustering yang mengambil tempat dari sumber Disk fisik. Alih-alih mengontrol pemesanan SCSI-3 seperti Physical Disk Resource, Volume DataKeeper mengontrol arah cermin, memastikan node aktif selalu menjadi sumber cermin. Sejauh Failover Clustering yang bersangkutan, terlihat, terasa dan bau seperti Disk Fisik dan digunakan dengan cara yang sama Sumber Daya Disk Fisik akan digunakan.

Pra-syarat Untuk Menyebarkan 2-Node File Server Failover Cluster di Azure

• Anda telah menggunakan Portal Azure sebelumnya dan nyaman menggunakan mesin virtual di Azure IaaS.
• Telah memperoleh lisensi atau lisensi eval dari SIOS DataKeeper

Menyebarkan A Failover Server Instance Server File Menggunakan Portal Azure

Untuk Menyebarkan 2-Node File Server Failover Cluster di Azure, kita akan berasumsi Anda memiliki Virtual Network dasar berdasarkan Azure Resource Manager dan Anda memiliki setidaknya satu mesin virtual dan berjalan dan dikonfigurasi sebagai Domain Controller. Setelah Anda memiliki Jaringan Virtual dan Domain yang dikonfigurasi, Anda akan menyediakan dua mesin virtual baru yang akan bertindak sebagai dua node dalam kelompok kami. Lingkungan kita akan terlihat seperti ini: DC1 – Pengontrol Domain dan File Share Witness SQL1 dan SQL2 – Dua node dari File Server Cluster kami

Penyediaan Dua Cluster Nodes (SQL1 Dan SQL2)

Dengan menggunakan Azure Portal, kami akan menyediakan SQL1 dan SQL2 dengan cara yang sama. Ada banyak pilihan untuk dipilih termasuk ukuran instan, opsi penyimpanan, dll. Panduan ini tidak dimaksudkan sebagai panduan lengkap untuk menyebarkan Server di Azure karena ada beberapa sumber daya yang sangat bagus di luar sana dan lebih banyak diterbitkan setiap hari. Namun, ada beberapa hal penting yang perlu diingat saat membuat instance Anda, terutama di lingkungan yang padat. Ketersediaan Set – Penting bahwa baik SQL1, SQL2 DAN DC1 berada dalam set ketersediaan yang sama. Dengan menempatkan mereka dalam Set Ketersediaan yang sama kami memastikan bahwa setiap node cluster dan file berbagi saksi berada di Domain Fault dan Update Domain yang berbeda. Ini membantu menjamin bahwa selama pemeliharaan yang direncanakan dan pemeliharaan yang tidak terencana, klaster akan terus dapat mempertahankan kuorum dan menghindari downtime. Gambar 3 – Pastikan untuk menambahkan kedua node cluster dan file berbagi saksi ke Set Ketersediaan yang sama

Alamat IP Statis

Setelah setiap VM disediakan, Anda akan ingin masuk ke pengaturan dan mengubah pengaturan sehingga alamat IP adalah Statis. Kami tidak ingin alamat IP dari node cluster kami berubah. Gambar 4 – Pastikan setiap node cluster menggunakan IP statis

Penyimpanan

Sejauh menyangkut Storage, Anda akan ingin berkonsultasi Praktik terbaik kinerja untuk SQL Server di Azure Virtual Machines. Bagaimanapun, Anda akan minimal perlu menambahkan setidaknya satu disk tambahan ke masing-masing node cluster Anda. DataKeeper dapat menggunakan Disk Dasar, Penyimpanan Premium, atau bahkan Storage Pools yang terdiri dari beberapa disk di kolam penyimpanan. Pastikan untuk menambahkan jumlah penyimpanan yang sama ke setiap node cluster dan konfigurasikan secara identik. Selain itu, pastikan untuk menggunakan akun penyimpanan yang berbeda untuk setiap mesin virtual untuk memastikan bahwa masalah dengan satu Akun Penyimpanan tidak memengaruhi kedua mesin virtual pada saat yang bersamaan. Gambar 5 – pastikan untuk menambahkan penyimpanan tambahan ke setiap node cluster

Buat Cluster

Dengan asumsi kedua node cluster (SQL1 dan SQL2) telah ditetapkan seperti yang dijelaskan di atas dan ditambahkan ke domain Anda yang ada, kami siap untuk membuat cluster. Sebelum kami membuat gugus, ada beberapa Fitur yang harus diaktifkan. Fitur-fitur ini. Net Framework 3.5 dan Failover Clustering. Fitur-fitur ini harus diaktifkan pada kedua node cluster. Anda juga harus mengaktifkan Peran Server FIle. Gambar 6 – mengaktifkan fitur .Net Framework 3.5 dan Failover Clustering dan File Server di kedua node cluster Setelah peran itu dan fitur-fitur tersebut telah diaktifkan, Anda siap untuk membangun klaster Anda. Sebagian besar langkah yang akan saya tunjukkan dapat dilakukan melalui PowerShell dan GUI. Namun, saya akan merekomendasikan bahwa untuk langkah pertama ini Anda menggunakan PowerShell untuk membuat kluster Anda. Jika Anda memilih untuk menggunakan GUI Manajer Failover Cluster untuk membuat gugus, Anda akan menemukan bahwa Anda berakhir dengan gugus yang mengeluarkan alamat IP duplikat.

Detail Untuk Catatan

Tanpa masuk ke detail besar, apa yang akan Anda temukan adalah bahwa Azure VM harus menggunakan DHCP. Dengan menetapkan "Static IP" ketika kita membuat VM di portal Azure, yang kita lakukan hanyalah membuat semacam reservasi DHCP. Ini bukan reservasi DHCP karena reservasi DHCP yang benar akan menghapus alamat IP dari kumpulan DHCP. Sebaliknya, menentukan IP Statis di portal Azure hanya berarti bahwa jika alamat IP tersebut masih tersedia ketika VM memintanya, Azure akan mengeluarkan IP itu. Namun, jika VM Anda offline dan host lain datang online di subnet yang sama, maka akan dikeluarkan alamat IP yang sama. Ada efek samping yang aneh dengan cara Azure mengimplementasikan DHCP. Saat membuat kluster dengan Windows Server Failover Cluster GUI ketika host menggunakan DHCP (yang harus), tidak ada opsi untuk menentukan alamat IP kluster. Alih-alih bergantung pada DHCP untuk mendapatkan alamat. Yang aneh adalah, DHCP akan mengeluarkan alamat IP duplikat, biasanya alamat IP yang sama dengan tuan rumah yang meminta alamat IP baru. Cluster biasanya akan selesai, tetapi Anda mungkin memiliki beberapa kesalahan aneh dan Anda mungkin perlu menjalankan Windows Server Failover Cluster GUI dari node yang berbeda untuk membuatnya berjalan. Setelah Anda mendapatkannya untuk menjalankan Anda akan ingin mengubah alamat IP klaster ke alamat yang saat ini tidak digunakan di jaringan.

Hindari Mess

Anda dapat menghindari kekacauan itu hanya dengan membuat gugus melalui Powershell dan menentukan alamat IP klaster sebagai bagian dari perintah PowerShell untuk membuat kluster. Anda dapat membuat kluster menggunakan perintah New-Cluster sebagai berikut:

Cluster Baru -Name cluster1 -Node sql1, sql2 -StaticAddress 10.0.0.101 -NoStorage

Setelah pembuatan klaster selesai, Anda juga akan ingin menjalankan validasi klaster dengan menjalankan perintah berikut:

Uji-Cluster

Gambar 7 – Output dari pembuatan cluster dan perintah validasi cluster

Buat File Share Witness

Karena tidak ada penyimpanan bersama, Anda harus membuat saksi berbagi file di server lain dalam Kumpulan Ketersediaan yang sama dengan dua node cluster. Dengan menempatkannya dalam ketersediaan yang sama, Anda dapat yakin bahwa Anda hanya kehilangan satu suara dari kuorum Anda pada waktu tertentu. Jika Anda tidak yakin cara membuat File Share Witness, Anda dapat meninjau artikel ini http://www.howtonetworking.com/server/cluster12.htm. Dalam demo saya, saya meletakkan file berbagi saksi di pengontrol domain. Saya telah menerbitkan penjelasan lengkap tentang kuorum klaster di https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum- in-windows-server-2012-r2 /

Instal DataKeeper

Setelah cluster dibuat, saatnya untuk menginstal DataKeeper. Penting untuk menginstal DataKeeper setelah cluster awal dibuat sehingga jenis sumber daya cluster khusus dapat didaftarkan dengan klaster. Jika Anda menginstal DataKeeper sebelum cluster dibuat, Anda hanya perlu menjalankan instalasi lagi dan melakukan instalasi perbaikan. Gambar 8 – Instal DataKeeper setelah cluster dibuat. Selama instalasi, Anda dapat mengambil semua opsi default.  Akun layanan yang Anda gunakan harus merupakan akun domain dan berada di grup administrator lokal pada setiap node dalam gugus. Gambar 9 – akun layanan harus berupa akun domain yang ada di grup admin lokal pada setiap node. Setelah DataKeeper diinstal dan dilisensikan pada setiap node, Anda harus mereboot server.

Buat Sumber Daya Volume DataKeeper

Untuk membuat DataKeeper Volume Resource Anda harus memulai UI DataKeeper dan terhubung ke kedua server. Hubungkan ke SQL1 Hubungkan ke SQL2 Setelah Anda terhubung ke setiap server, Anda siap untuk membuat Volume DataKeeper Anda. Klik kanan pada Jobs dan pilih "Buat Pekerjaan" Berikan pekerjaan nama dan deskripsi. Pilih server sumber Anda, IP dan volume. Alamat IP adalah apakah lalu lintas replikasi akan bepergian. Pilih server target Anda. Pilih opsi Anda. Untuk tujuan kami di mana kedua VM berada di wilayah geografis yang sama, kami akan memilih replikasi yang sinkron. Untuk replikasi jarak yang lebih jauh, Anda akan ingin menggunakan asynchronous dan mengaktifkan beberapa kompresi. Dengan mengklik ya pada pop-up terakhir, Anda akan mendaftarkan Sumber Daya Volume DataKeeper Baru dalam Penyimpanan Tersedia dalam Failover Clustering. Anda akan melihat Sumber Daya Volume DataKeeper baru dalam Penyimpanan Tersedia.

Buat Sumber Daya Cluster Server File

Untuk membuat File Server Cluster Resource kita akan menggunakan Powershell sekali lagi daripada antarmuka Failover Cluster. Alasannya adalah karena sekali lagi karena mesin virtual dikonfigurasi untuk menggunakan DHCP, wizard berbasis GUI tidak akan meminta kita untuk memasukkan alamat IP klaster dan sebagai gantinya akan mengeluarkan alamat IP duplikat. Untuk menghindari ini kita akan menggunakan perintah powershell sederhana untuk membuat Sumber Daya Cluster Server FIle dan menentukan Alamat IP

Add-ClusterFileServerRole -Storage "DataKeeper Volume E" 
-Nama FS2 -StaticAddress 10.0.0.201

Catat alamat IP yang Anda tentukan di sini. Itu harus alamat IP unik di jaringan Anda. Kami akan menggunakan alamat IP yang sama nanti ketika kami membuat Penyeimbang Beban Internal kami.

Buat Penyeimbang Beban Internal

Di sinilah tempat failover clustering di Azure berbeda dari infrastruktur tradisional. Tumpukan jaringan Azure tidak mendukung ARPS serampangan. Klien tidak dapat terhubung langsung ke alamat IP klaster. Sebaliknya, klien terhubung ke load balancing internal dan dialihkan ke node cluster aktif. Yang perlu kita lakukan adalah membuat penyeimbang muatan internal. Ini semua bisa dilakukan melalui Portal Azure seperti yang ditunjukkan di bawah ini. Pertama, buat Penyeimbang Beban baru Anda dapat menggunakan Penyeimbang Beban Publik jika klien Anda terhubung melalui internet publik, tetapi dengan asumsi klien Anda berada di vNet yang sama, kami akan membuat Penyeimbang Beban Internal. Hal penting yang perlu diperhatikan di sini adalah bahwa Jaringan Virtual sama dengan jaringan di mana node cluster Anda berada. Juga, alamat IP Pribadi yang Anda tentukan akan PERSIS sama dengan alamat yang Anda gunakan untuk membuat Sumber Daya Cluster SQL. Setelah Internal Load Balancer (ILB) dibuat, Anda harus mengeditnya. Hal pertama yang akan kita lakukan adalah menambahkan kumpulan backend. Melalui proses ini Anda akan memilih Set Ketersediaan di mana Anda SQL Cluster VMs berada. Namun, ketika Anda memilih VMs yang sebenarnya untuk ditambahkan ke Backend Pool, pastikan Anda tidak memilih file Anda berbagi saksi. Kami tidak ingin mengarahkan lalu lintas SQL ke saksi berbagi file Anda. Hal berikutnya yang akan kita lakukan adalah menambahkan Probe. Probe yang kami tambahkan akan memeriksa Port 59999. Probe ini menentukan node mana yang aktif di kluster kami. Dan akhirnya, kita membutuhkan aturan load balancing untuk mengarahkan trafik SMB, port TCP 445. Yang penting untuk diperhatikan dalam screenshot di bawah ini adalah Direct Server Return Enabled. Pastikan Anda melakukan perubahan itu.

Perbaiki Sumber Daya IP Server File

Hampir di sana untuk Menyebarkan 2-Node File Server Failover Cluster di Azure! Langkah terakhir dalam konfigurasi adalah menjalankan skrip PowerShell berikut di salah satu simpul klaster Anda. Ini akan memungkinkan Cluster IP Address untuk menanggapi probe ILB dan memastikan bahwa tidak ada konflik alamat IP antara Cluster IP Address dan ILB. Mohon dicatat; Anda perlu mengedit skrip ini agar sesuai dengan lingkungan Anda. Subnet mask diatur ke 255.255.255.255, ini bukan kesalahan, biarkan saja apa adanya. Ini membuat rute khusus host untuk menghindari konflik alamat IP dengan ILB.

# Definisikan variabel
$ ClusterNetworkName = “” 
# nama jaringan klaster 
(Gunakan Get-ClusterNetwork di Windows Server 2012 yang lebih tinggi untuk menemukan namanya)
$ IPResourceName = “” 
# Nama sumber alamat IP 
$ ILBIP = “” 
# Alamat IP Penyeimbang Beban Internal (ILB)
Import-Module FailoverClusters
# Jika Anda menggunakan Windows Server 2012 atau lebih tinggi:
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Beberapa @ {Alamat = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255";
Jaringan = $ ClusterNetworkName; EnableDhcp = 0}
# Jika Anda menggunakan Windows Server 2008 R2, gunakan ini: 
#cluster res $ IPResourceName / priv diaktifkanhcp = 0 alamat = $ ILBIP probeport = 59999  
subnetmask = 255.255.255.255

Membuat File Saham

Anda akan menemukan bahwa menggunakan File Share Wizard di Failover Cluster Manager tidak berfungsi. Sebagai gantinya, Anda cukup membuat file yang dibagikan di Windows Explorer pada simpul aktif. Failover clustering secara otomatis mengambil bagian-bagian itu dan menempatkannya di dalam cluster. Perhatikan bahwa opsi "Ketersediaan Berkelanjutan" dari pembagian file tidak didukung dalam konfigurasi ini.

Kesimpulan

Anda telah berhasil Menyebarkan 2-Node File Server Failover Cluster di Azure.  Jika Anda memiliki masalah APAPUN, silakan hubungi saya di Twitter @daveberm dan saya akan senang membantu. Jika Anda memerlukan kunci evaluasi DataKeeper, isi formulir di http://us.sios.com/clustersyourway/cta/14-day-trial dan SIOS akan mengirimkan kunci evaluasi yang dikirimkan kepada Anda. Direproduksi dengan izin dari Clusteringformeremortals.com