SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Produk
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • Berita dan acara
  • Cluster server penyederhanaan
  • Kisah sukses
  • Hubungi kami
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

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

Filed Under: Cluster server penyederhanaan Tagged With: Cloud Witness, Keseimbangan muatan, Manajer Konfigurasi Pusat Sistem, Manajer Sumber Daya Azure, multi instance sql server failover cluster dalam biru, Penyebaran, PowerShell, replikasi, Windows Server 2012

Cara Mengganti Ketersediaan Set Tersedia dari Azure VM yang Ada

Agustus 20, 2018 by Jason Aw Leave a Comment

Bagaimana cara mengubah set ketersediaan vm biru yang ada?

Mengubah Set Ketersediaan Dari Sebuah Azure VM yang Sudah Ada

6/21/2016 – Pembaruan. Karena saya memposting artikel ini saya telah diberitahu oleh sumber yang dapat dipercaya bahwa ada skrip PowerShell yang lebih baru yang dapat Mengubah Kumpulan Ketersediaan Dari Azure VM yang Ada, bahkan lebih andal. Saya belum mencobanya. Tapi saya percaya sumber dan Dukungan Microsoft Premiere mengarahkannya ke artikel ini. https://gallery.technet.microsoft.com/Azure-RM-Availability-Set-39e19d01 Saya sedikit terkejut mengetahui hari ini bahwa tidak mudah untuk mengubah apa yang Tersedia Set VM berada dalam sekali sudah dibuat. Portal Azure tidak memiliki mekanisme penambahan VM yang ada ke Kumpulan Ketersediaan. Untungnya bagi saya, saya menemukan sumber daya yang hebat ini. Atur Azure Resource Manager VM AvailabilitySet Dengan memanfaatkan skrip PowerShell yang tersedia untuk diunduh di artikel itu, saya dapat menambahkan dua VM yang sudah ada ke yang telah saya buat. Akhirnya saya bisa Mengganti Ketersediaan Set Dari Existing Azure VM – apa yang hidup hemat! Ubah Ketersediaan Set Dari Azure VM yang Sudah Ada

Direproduksi dengan izin dari ClusteringforMereMortals.com

Filed Under: Cluster server penyederhanaan Tagged With: Manajer Sumber Daya Azure, Set Ketersediaan

Menyebarkan kluster Failover SQL Server di Azure Resource Manager

Agustus 19, 2018 by Jason Aw Leave a Comment

Menyebarkan Microsoft SQL Server 2014 Failover Cluster di Azure Resource Manager

Dalam posting ini, kita akan detail langkah-langkah spesifik yang diperlukan untuk Menyebarkan SQL Server Failover Cluster di Azure Resource Manager. Saya akan menganggap Anda akrab dengan konsep Azure dasar serta konsep SQL Server Failover Cluster dasar. Menerapkan 2-node SQL Server Failover Cluster di satu wilayah Azure menggunakan Azure Resource Manager bukanlah ilmu roket. Apa yang saya akan fokus dalam artikel ini adalah keunikan tentang penggelaran Cluster Failover SQL Server di Azure Resource Manager. Jika Anda masih menggunakan Azure Classic dan perlu menggunakan SQL Server Failover Cluster di Classic, baca artikel saya “LANGKAH-LANGKAH-LANGKAH: BAGAIMANA MENGONFIGURASI SQL SERVER FAILOVER CLUSTER INSTANCE (FCI) DI MICROSOFT AZURE IAAS #SQLSERVER #AZURE # SANLESS ”Sebelum kita mulai, mari kita membiasakan dengan Artikel Windows Azure, ketersediaan tinggi dan pemulihan bencana untuk SQL Server di Azure Virtual Machines. Dalam artikel itu semua opsi HA diuraikan. Ini termasuk AlwaysOn AG, Pencerminan Database, Pengiriman Log, Pencadangan dan Pemulihan, dan akhirnya Failover Cluster Instances. Dengan asumsi Anda telah menolak opsi-opsi lain karena biaya yang terkait dengan Edisi Enterprise SQL Server atau kurangnya fitur, kami berfokus pada opsi terakhir – SQL Server AlwaysOn Failover Cluster Instance (FCI). Ketika Anda membaca artikel itu menjadi jelas bahwa kurangnya penyimpanan bersama yang sadar cluster di Azure adalah kendala dalam menyebarkan gugus Failover SQL Server. Namun, ada beberapa alternatif yang dijelaskan dalam artikel itu. Kami akan fokus menggunakan SIOS DataKeeper, untuk menyediakan penyimpanan yang akan digunakan dalam klaster. Gambar 1 Kebijakan dukungan Microsoft untuk SQL Server Failover Cluster https://azure.microsoft.com/en-us/documentation/articles/virtual-machines- windows-classic-sql-dr / [/ caption] 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 banyak 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 SQL Server dan 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 SQL Server Failover Cluster Di Azure Resource Manager

  • Anda telah menggunakan Portal Azure sebelumnya dan nyaman menggunakan mesin virtual di Azure IaaS.
  • Telah memperoleh lisensi atau lisensi eval dari SIOS DataKeeper
  • Apakah akrab dengan SQL Server AlwaysOn Failover Cluster Instance. Jika tidak, silakan tinjau dokumentasi di sini https://msdn.microsoft.com/en-us/library/ms189134.aspx

Cara Mudah Untuk Melakukan Proof-Of-Concept

Jika Anda terbiasa dengan Azure Resource Manager, Anda tahu salah satu fitur baru yang hebat adalah kemampuan untuk menggunakan Template Penerapan untuk menyebarkan aplikasi dengan cepat yang terdiri dari sumber daya Azure yang saling terkait. Banyak dari template ini dikembangkan oleh Microsoft dan sudah tersedia di komunitas mereka di Github sebagai "Template Quickstart". Anggota komunitas juga bebas memperpanjang templat atau mempublikasikan templat mereka sendiri di GitHub. Salah satu template yang berjudul "SQL Server 2014 AlwaysOn Failover Cluster Instance dengan SIOS DataKeeper Azure Deployment Template" yang diterbitkan oleh SIOS Technology sepenuhnya mengotomatiskan proses penyebaran 2-node SQL Server FCI ke dalam Domain Direktori Aktif baru. Untuk menerapkan templat ini semudah mengklik tombol “Deploy to Azure” di template. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Gambar 2- Kunjungi https://github.com/SIOSDataKeeper/SIOSDataKeeper-SQL-Cluster untuk menyediakan klaster SQL 2-node dengan cepat [/ caption]

Menyebarkan A SQL Server Failover Cluster Instance Menggunakan Portal Azure

Sementara template penyebaran Azure otomatis adalah cara cepat dan mudah untuk mendapatkan 2-node SQL Server FCI dan berjalan dengan cepat, ada beberapa batasan. Untuk satu, ini menggunakan 180 Hari evaluasi versi SQL Server, sehingga Anda tidak dapat menggunakannya dalam produksi kecuali Anda meng-upgrade lisensi eval SQL. Juga, ia membangun domain AD yang sama sekali baru jadi jika Anda ingin berintegrasi dengan domain yang ada, Anda harus membuatnya secara manual. Untuk membangun 2-node SQL Server Failover Cluster Instance di Azure, kita akan berasumsi Anda memiliki Virtual Network dasar berdasarkan Azure Resource Manager (bukan Azure Classic) dan Anda memiliki setidaknya satu mesin virtual dan berjalan dan dikonfigurasi sebagai Kontroler Domain. 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 SQL Server Cluster kami

Penyediaan 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 menerapkan SQL 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 [/ caption]

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. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Gambar 4 – Pastikan setiap node cluster menggunakan IP statis [/ caption]

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. GaMenyebarkan kluster Failover SQL Server di Azure Resource Managermbar 5 – pastikan untuk menambahkan penyimpanan tambahan ke setiap node cluster [/ caption]

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. Gambar 6 – mengaktifkan fitur .Net Framework 3.5 dan Failover Clustering pada kedua node cluster [/ caption] Setelah fitur-fitur tersebut diaktifkan, Anda siap untuk membangun kluster 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. 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, ini menentukan IP Statis di portal Azure hanya berarti bahwa jika alamat IP tersebut masih tersedia ketika VM memintanya, Azure akan mengeluarkan IP itu padanya. 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. 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 klaster [/ caption]

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 / In

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 [/ caption] 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 [/ caption] Setelah DataKeeper dipasang dan dilisensikan setiap node Anda perlu reboot server.

Buat Sumber Daya Volume DataKeeper

Untuk membuat DataKeeper Volume Resource Anda harus memulai UI DataKeeper dan terhubung ke kedua server. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Hubungkan ke SQLMenyebarkan kluster Failover SQL Server di Azure Resource Manager1 Hubungkan ke SQLMenyebarkan kluster Failover SQL Server di Azure Resource Manager2 Setelah Anda terhubung ke setiap server, Anda siap untuk membuat Volume DataKeeper Anda. Klik kanan pada Jobs dan pilih "Buat PekerjaanMenyebarkan kluster Failover SQL Server di Azure Resource Manager" Berikan pekerjaan nama dan deskripsi. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Pilih server sumber Anda, IP dan volume. Alamat IP adalah apakah lalu lintas replikasi akan bepergian. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Pilih server target Anda. Menyebarkan kluster Failover SQL Server di Azure Resource Manager 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. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Dengan mengklik ya pada pop-up terakhir, Anda akan mendaftarkan Sumber Daya Volume DataKeeper Baru dalam Penyimpanan Tersedia dalam Failover Clustering. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Anda akan melihat Sumber Daya Volume DataKeeper baru dalam Penyimpanan Tersedia. Menyebarkan kluster Failover SQL Server di Azure Resource Manager  

Instal Simpul Cluster Pertama

Anda sekarang siap untuk menginstal node pertama Anda. Instalasi klaster akan berjalan seperti kluster SQL lain yang pernah Anda bangun. Saya belum menyalin setiap screen shot, hanya beberapa untuk memandu Anda sepanjang jalan. Menyebarkan kluster Failover SQL Server di Azure Resource ManagerMenyebarkan kluster Failover SQL Server di Azure Resource ManagerMenyebarkan kluster Failover SQL Server di Azure Resource ManagerMenyebarkan kluster Failover SQL Server di Azure Resource Manager Anda melihat bahwa Sumber Daya Volume DataKeeper diakui sebagai sumber daya disk yang tersedia, sama seperti jika disk dibagi. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Catat alamat IP yang Anda pilih 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. Menyebarkan kluster Failover SQL Server di Azure Resource Manager

Tambahkan Simpul Kedua

Setelah node pertama berhasil di-install, Anda akan memulai instalasi pada node kedua menggunakan opsi “Add node to a SQL Server failover cluster”. Sekali lagi, instalasinya cukup lurus ke depan, cukup gunakan praktik terbaik standar seperti halnya instalasi klaster SQL lainnya. Menyebarkan kluster Failover SQL Server di Azure Resource ManagerMenyebarkan kluster Failover SQL Server di Azure Resource ManagerMenyebarkan kluster Failover SQL Server di Azure Resource ManagerMenyebarkan kluster Failover SQL Server di Azure Resource Manager

Buat Penyeimbang Beban Internal

Di sinilah tempat failover clustering di Azure berbeda dari infrastruktur tradisional. Tumpukan jaringan Azure tidak mendukung ARPS serampangan, sehingga 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 AMenyebarkan kluster Failover SQL Server di Azure Resource Managernda 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. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Menyebarkan kluster Failover SQL Server di Azure Resource Manager 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. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Menyebarkan kluster Failover SQL Server di Azure Resource Manager 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. Menyebarkan kluster Failover SQL Server di Azure Resource Manager Dan akhirnya, kita membutuhkan aturan load balancing untuk mengarahkan kembali trafik SQL Server. Dalam contoh kami, kami menggunakan Standar Instance dari SQL yang menggunakan port 1433. Anda mungkin juga ingin menambahkan aturan untuk 1434 atau yang lainnya tergantung pada persyaratan aplikasi Anda. Hal yang penting untuk diperhatikan dalam screen shot di bawah ini adalah Direct Server Return Enabled. Pastikan Anda melakukan perubahan itu.

Perbaiki Sumber Daya IP Server SQL

Satu langkah terakhir untuk Menyebarkan SQL Server Failover Cluster di Azure Resource Manager. Jalankan 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

Kesimpulan

Anda sekarang harus memiliki SQL Server Failover Cluster Instance yang berfungsi. Menghadapi masalah untuk Menyebarkan SQL Server Failover Cluster Di Azure Resource Manager? Hubungi saya di Twitter @daveberm dan saya akan senang membantu. Jika Anda membutuhkan kunci evaluasi DataKeeper, isi formulir di http://us.sios.com/clustersyourway/cta/14-day-trial, SIOS akan mengirimkan kunci evaluasi yang dikirimkan kepada Anda.

Direproduksi dengan izin dari Clusteringformeremortals.com

Filed Under: Cluster server penyederhanaan Tagged With:  , failover cluster, Manajer Sumber Daya Azure

Layanan yang Didukung dengan Azure Resource Manager (ARM)

Juni 20, 2018 by Jason Aw Leave a Comment

Manajemen Layanan Azure (Klasik) atau Azure Resource Manager (ARM)?

Saya berurusan dengan pengguna setiap minggu yang memindahkan beban kerja bisnis yang penting ke Azure. Pertanyaan pertama yang biasanya saya tanyakan adalah apakah mereka menggunakan Azure Service Management (Classic) atau Azure Resource Manager (ARM).

Saya biasanya merekomendasikan ARM. Ini adalah cara baru dalam melakukan sesuatu dan semua fitur baru sedang dikembangkan untuk ARM. Namun, ada beberapa hal yang tidak kompatibel dengan ARM. Seiring berjalannya waktu, daftar fitur yang tidak didukung ini semakin kecil dan semakin kecil. Sementara itu, baik untuk mengetahui ada dokumen yang ada yang tampaknya diperbarui secara berkala yang berisi daftar semua fitur dan apakah mereka didukung dengan ARM. https://azure.microsoft.com/en-us/documentation/articles/resource-manager-supported-services/

Ini daftar yang bagus tapi tidak lengkap. Saya hanya menemukan Lingkungan Layanan Aplikasi tidak didukung pada halaman ini di halaman App Service Environment.

Direproduksi dengan izin dari Clustering For Mere Mortals.

Filed Under: Cluster server penyederhanaan Tagged With: Manajer Sumber Daya Azure

Keuntungan dari Azure Resource Manager yang Harus Anda Ketahui

Maret 31, 2018 by Jason Aw Leave a Comment

Keuntungan Dari Manajer Sumber Daya Azure Dan Penyebaran SQL Server Yang Sangat Tersedia Di Azure

Azure Resource Manager (ARM) adalah cara terbaru dan terbaik untuk bekerja dengan Microsoft Azure IaaS. Keuntungan dari Azure Resource Manager cukup banyak – penggunaan template, pengelompokan, penagihan yang disederhanakan dan banyak lagi. Model baru ini menjanjikan fitur baru dan lebih banyak interaksi.

Tangkap Webinar

Microsoft Cloud dan Manajemen Datacenter MVP David Bermingham akan memperkenalkan ARM dan melihat lebih dekat bagaimana menggunakan ARM untuk memungkinkan penyebaran SQL Server yang sangat tersedia dan terukur di awan.

Daftar untuk webinar ini di sini … https://www.mssqltips.com/webcastSignupPage.asp?id=480&src=sios

Direproduksi dengan izin dari https://clusteringformeremortals.com/2015/12/15/key-benefits-of-working-with-azure-resource-manager-and-highly-available-sql-server-deployments-in-azure/

Filed Under: Cluster server penyederhanaan Tagged With: David Bermingham, Manajer Sumber Daya Azure

  • 1
  • 2
  • Next Page »

Tulisan Terbaru

  • Strategi Peningkatan Bergulir Terbaik untuk Meningkatkan Kelangsungan Bisnis
  • Cara Melakukan Patch Tanpa Jeda: Downtime Hampir Nol dengan HA
  • Demo SIOS LifeKeeper: Cara Rolling Update dan Failover Melindungi PostgreSQL di AWS
  • Cara Menilai Apakah Kartu Jaringan Saya Perlu Diganti
  • Teknologi SIOS Akan Mendemonstrasikan Perangkat Lunak Pengelompokan Ketersediaan Tinggi untuk Aplikasi Misi-Kritis di Red Hat Summit, Milestone Technology Day dan XPerience Day, serta SQLBits 2025

Posting Terpopuler

Bergabunglah dengan Milis Kami

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in