SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

by Leave a Comment

Fitur Azure ILB Baru Memungkinkan Anda Untuk Membangun Multi-Instance SQL Server Failover Cluster Di Azure

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 atau 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 Pusat Data Ketiga

Dan akhirnya, ketika menggelar cluster multisite, Cloud Witness menghilangkan kebutuhan untuk pusat data ke-3 untuk menjadi tuan rumah File Share Witness. Sebelum pengenalan Cloud Witness, praktik terbaik akan menentukan bahwa Saksi Berbagi Berkas berada di lokasi ketiga. Akses ke pusat data 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 untuk mempertahankan 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

S2D Untuk SQL Server Failover Cluster Instances 

by Leave a Comment

Ruang Penyimpanan Langsung (S2D) Untuk Instance SQL Server Failover Cluster

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.

Ruang Penyimpanan Stack Langsung 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. S2D Untuk SQL Server Failover Cluster Instances  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. S2D Untuk SQL Server Failover Cluster Instances  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

by Leave a Comment

Bagaimana membangun contoh failover cluster server yang bersih tanpa sanitasi di platform cloud google

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. SQL Server Failover Instance Cluster Instan di Google Cloud Platform 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

by Leave a Comment

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. Clailers Failover Ketersediaan Tinggi Untuk MS SQL Server v.Next di Linux 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

by Leave a Comment

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. 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.