Cluster server penyederhanaan | Page 3 of 34

Multi-Instance SQL Server Failover Cluster Dengan Fitur Azure ILB Baru

April 14, 2019 by Jason Aw Leave a Comment

Fitur Azure ILB Baru Memungkinkan Anda Membuat Cluster Failover SQL Server Multi-Instance

Di Microsoft Ignite pada September lalu, Microsoft membuat beberapa pengumuman seputar Azure. Salah satu pengumuman ini adalah ketersediaan umum beberapa VIP pada penyeimbang beban internal. Mengapa ini sangat penting untuk DBA SQL Server? Ya, sampai sekarang jika Anda ingin menggunakan SQL Server yang sangat tersedia di Azure, Anda dibatasi untuk SQL Server FCI per cluster atau pendengar Grup Ketersediaan tunggal. Batasan ini memaksa Anda untuk menyebarkan cluster baru untuk setiap instance SQL Server yang ingin Anda lindungi dalam Failover Cluster. Itu juga memaksa Anda untuk mengelompokkan semua basis data Anda ke dalam Kelompok Ketersediaan tunggal jika Anda menginginkan failover otomatis dan pengalihan klien dalam konfigurasi AlwaysOn AG Anda.

Bagaimana Keluar Dari Batasan Ini?

Batasan tersebut sekarang telah dicabut dengan fitur-fitur ILB baru ini. Dalam posting ini saya akan memandu Anda melalui proses penyebaran SQL Server FCI di Azure yang berisi dua contoh SQL Server. Dalam posting mendatang saya akan memandu Anda melalui proses yang sama untuk SQL Server AlwaysOn AG.

Mari Kita Mulai Dengan Cluster Failover SQL Server Multi-Instance

Membangun dasar, contoh tunggal SQL Server FCI di Azure seperti yang saya jelaskan di posting saya Menyebarkan Microsoft SQL Server 2014 Failover Clusters di Azure Resource Manager. Posting itu menjelaskan proses membuat Multi-Instance SQL Server Failover Cluster. Menggunakan DataKeeper untuk membuat sumber daya volume yang direplikasi yang digunakan dalam cluster, coba buat Internal Load Balancer (ILB) dan kemudian perbaiki SQL Server Cluster IP Resource untuk bekerja dengan ILB. Jika Anda ingin melewati proses itu dan memulai konfigurasi Anda, Anda selalu dapat menggunakan Azure Deployment Templat yang membuat 2-Node SQL Server FCI menggunakan SIOS DataKeeper Dengan anggapan Anda sekarang memiliki dua simpul dasar SQL Server FCI, langkah-langkah untuk menambahkan 2^bernama contoh adalah sebagai berikut:

Buat Sumber Daya Volume DataKeeper lain pada volume lain yang saat ini tidak digunakan. Anda mungkin perlu menambahkan disk tambahan ke instance Azure Anda jika Anda tidak memiliki volume yang tersedia. Sebagai bagian dari proses pembuatan volume ini, sumber daya Volume DataKeeper baru akan didaftarkan di Penyimpanan Tersedia di kluster. Lihat artikel yang dirujuk sebelumnya untuk detailnya.
Instal contoh bernama SQL Server pada node pertama, tentukan Volume DataKeeper yang baru saja kita buat sebagai lokasi penyimpanan.
“Tambahkan simpul” ke kluster pada simpul kedua.
Kunci nomor port instance bernama baru ini ke port yang tidak digunakan. Dalam contoh saya, saya menggunakan port 1440.

Sesuaikan ILB Ke Instance Kedua

Selanjutnya kita harus menyesuaikan ILB untuk mengarahkan lalu lintas ke instance kedua ini. Berikut adalah langkah-langkah yang perlu Anda ikuti: Tambahkan alamat IP frontend yang identik dengan alamat IP SQL cluster yang Anda gunakan untuk contoh kedua SQL Server seperti yang ditunjukkan di bawah ini. Multi-Instance SQL Server Failover Cluster Dengan Fitur Azure ILB Baru Selanjutnya, kita perlu menambahkan probe lain karena instance dapat berjalan di server yang berbeda. Seperti yang ditunjukkan di bawah ini, saya menambahkan probe yang memeriksa port 59998 (bukan 59999 yang biasa). Kita perlu memastikan aturan baru merujuk pada penyelidikan ini. Kita juga perlu mengingat nomor port itu karena kita perlu memperbarui alamat IP yang terkait dengan instance ini selama langkah terakhir dari proses ini. Multi-Instance SQL Server Failover Cluster Dengan Fitur Azure ILB Baru Sekarang kita perlu menambahkan dua aturan baru ke ILB untuk mengarahkan lalu lintas yang ditujuk^an untuk ke-2 SQL ini. Tentu saja kita perlu menambahkan aturan untuk mengarahkan kembali port TCP 1440 (port yang saya gunakan untuk instance bernama SQL), tetapi karena kita sekarang menggunakan instance bernama kita juga perlu memiliki port untuk mendukung Layanan Browser SQL Server, Port UDP 1434. Pada gambar di bawah ini yang menggambarkan aturan untuk Layanan Browser SQL Server, perhatikan bahwa Alamat IP Front End merujuk pada alamat FrontendIP baru (10.0.0.201), port UDP 1434 untuk Port dan Backend Port. Di pool, Anda perlu menentukan dua server di cluster, dan akhirnya pastikan Anda memilih Health Probe yang baru saja kita buat. Multi-Instance SQL Server Failover Cluster Dengan Fitur Azure ILB Baru Kami sekarang akan menambahkan aturan untuk TCP / 1440. Seperti yang ditunjukkan pada gambar di bawah ini, tambahkan aturan baru untuk port TCP 1440, atau port apa pun yang dikunci untuk instance bernama SQL Server. Sekali lagi, pastikan untuk memilih Alamat IP FrontEnd baru dan Probe Kesehatan baru (59998). Juga, pastikan IP Terapung (pengembalian server langsung) diaktifkan. Multi-Instance SQL Server Failover Cluster Dengan Fitur Azure ILB Baru

Langkah Terakhir

Sekarang setelah load balancer dikonfigurasi, langkah terakhir adalah menjalankan skrip PowerShell untuk memperbarui alamat IP Cluster baru yang terkait dengan ⁱⁿstance SQL Server ke-2 ini. Skrip PowerShell ini hanya perlu dijalankan di salah satu node cluster.

# Definisikan variabel

$ ClusterNetworkName = ""

# nama jaringan cluster 
(Gunakan Get-ClusterNetwork di Windows Server 2012 yang lebih tinggi untuk menemukan nama)

$ IPResourceName = ""

# nama sumber daya Alamat IP dari instance kedua SQL Server

$ ILBIP = ""

# Alamat IP dari instance SQL kedua, 
yang harus sama dengan alamat IP Frontend baru juga

Impor-Modul FailoverClusters

# Jika Anda menggunakan Windows Server 2012 atau lebih tinggi:

Dapatkan-ClusterResource $ IPResourceName | 
Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59998;
SubnetMask = "255.255.255.255"; Jaringan = $ ClusterNetworkName; EnableDhcp = 0}

# Jika Anda menggunakan Windows Server 2008 R2 gunakan ini:

#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59998  
subnetmask = 255.255.255.255

Anda sekarang memiliki multi-instance SQL Server FCI yang berfungsi penuh di Azure. Beri tahu saya jika Anda memiliki pertanyaan untuk membangun Cluster Failover SQL Server Multi-Instance Dengan Fitur ILB Azure Baru yang Direproduksi dari Clusteringformeremortals.com

Mengkonfigurasi contoh SQL Server Failover Cluster pada mesin virtual Azure

April 4, 2019 by Jason Aw Leave a Comment

Mengkonfigurasi contoh SQL Server Failover Cluster pada mesin virtual Azure dengan Msdtc #Sql #Azure #Msdtc

Anda mungkin tahu bahwa kami telah menyertakan banyak panduan langkah demi langkah untuk membangun SQL Server Failover Cluster Instances (FCI) di Azure, dari SQL Server 2008 hingga yang terbaru. Berikut ini beberapa tautan untuk membantu Anda memulai. Tetapi sebenarnya ada sedikit perbedaan dalam konfigurasi antara versi Windows dan SQL Server yang berbeda. Jadi saya pikir Anda akan dapat mengetahuinya terlepas dari versi apa yang Anda gunakan. LANGKAH-LANGKAH-LANGKAH: CARA MENGONFIGURASI SQL SERVER FAILOVER CLUSTER INSTANCE (FCI) DI MICROSOFT AZURE IAAS #SQLSERVER #AZURE #SANLESS LANGKAH DENGAN-LANGKAH: BAGAIMANA CARA KONFIGURASI SQL SERVER 2008 R2 FAILOVER INSTANCE IN AZURE tidak ditujukan apa yang harus dilakukan tentang MSDTC. Microsoft mengalamatkan hal itu dalam artikel ini yang diposting di sini. https://blogs.msdn.microsoft.com/sql_pfe_blog/2018/07/05/configure-sql-server-failover-cluster-instance-onstaz-viure-virtual-machines-with-msdtc Namun, artikel / video itu saja alamat SQL Server 2016 dan yang lebih baru. Berita baiknya adalah bahwa sebagian besar panduan itu dapat diterapkan ke SQL Server 2008/2012/2014. Sampai saya punya waktu untuk melakukan panduan langkah demi langkah yang tepat, saya ingin menuliskan beberapa catatan dasar, lebih sebagai pengingat bagi diri saya sendiri. Namun, Anda mungkin menemukan informasi ini berguna untuk sementara waktu. Langkah-langkah di bawah ini menganggap Anda telah membuat SQL Server FCI di Azure dan mengelompokkan sumber daya DTC. Referensi panduan di atas untuk perincian tentang langkah-langkah tersebut. Langkah-langkah di bawah ini benar-benar hanya merinci konfigurasi penyeimbang beban yang diperlukan di Azure untuk membuat pekerjaan ini.

Buat Load Balancer Untuk MSDTC

Sumber daya MSDTC akan membutuhkan load balancer-nya sendiri. Alih-alih membuat penyeimbang beban baru, kami akan menambahkan antarmuka baru ke penyeimbang beban yang seharusnya sudah dikonfigurasi untuk SQL Server FCI. Tentu saja alamat IP frontend ini harus cocok dengan alamat IP cluster yang terkait dengan sumber daya MSDTC yang dikelompokkan. Untuk backend pool cukup gunakan kembali pool yang sudah Anda buat yang berisi node cluster SQL. Anda perlu membuat pemeriksaan kesehatan baru yang didedikasikan untuk sumber daya MSDTC. Port yang Anda gunakan harus berbeda dari yang Anda gunakan untuk sumber daya SQL. Jangan gunakan 59999. Mungkin menggunakan sesuatu seperti 49999. Langkah terakhir adalah membuat aturan keseimbangan muatan untuk MSDTC. Buat aturan baru dan referensi frontend MSDTC yang baru saja kita buat dan backend yang ada. Selanjutnya kita perlu membuat aturan keseimbangan beban baru. MSDTC menggunakan porta fana, yang merupakan sejumlah besar porta. Saat Anda membuat aturan, Anda harus memilih kotak yang mengatakan "HA Ports". Akhirnya, pastikan Direct Server Return diaktifkan.

Perbarui MSDTC Cluster IP Resource

Bekerja seperti alamat IP SQL Server Cluster. Kita perlu menjalankan perintah Powershell yang akan untuk sumber daya MSDTC cluster IP untuk menanggapi penyelidikan kesehatan yang baru saja kita buat yang memeriksa port 49999. Itu juga menetapkan subnet mask dari alamat IP MSDTC cluster ke 255.255.255.255 untuk menghindari konflik alamat IP dengan frontend penyeimbang beban yang kami atur yang berbagi alamat yang sama.

# Tentukan variabel $ ClusterNetworkName = ""  
# nama jaringan cluster (Gunakan Get-ClusterNetwork on 
Windows Server 2012 yang lebih tinggi untuk menemukan nama sumber daya MSDTC) 
$ IPResourceName = ""  
# nama sumber daya Alamat IP sumber daya MSDTC $ ILBIP = ""  
# Alamat IP Internal Load Balancer (ILB) dan sumber daya MSDTC 
Impor-Modul FailoverClusters 
# Jika Anda menggunakan Windows Server 2012 atau lebih tinggi: 
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Multiple @ {Alamat = $ ILBIP; ProbePort = 49999; SubnetMask = "255.255.255.255";
Network = $ ClusterNetworkName; EnableDhcp = 0} 
# Jika Anda menggunakan Windows Server 2008 R2 gunakan ini:  
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999  
subnetmask = 255.255.255.255

Konfirmasikan Berhasil!

Anda dapat menggunakan DTCPing atau masuk ke Layanan Komponen dan lihat di bawah Komputer> Komputer Saya> Koordinator Transaksi Terdistribusi di mana Anda akan melihat DTC lokal dan DTC berkerumun. Setiap transaksi terdistribusi harus muncul di DTC berkerumun, bukan DTC lokal. Lihat video ini untuk contoh cara membuat transaksi terdistribusi untuk pengujian.

Langkah selanjutnya

Ini adalah panduan cepat dan kotor. Untuk pengguna yang berpengalaman itu harus membuat sumber daya MSDTC Anda dan berjalan di Azure. Saya akan menerbitkan panduan langkah demi langkah terperinci dalam waktu dekat. Sementara itu, jika Anda buntu jangan ragu untuk menghubungi saya di Twitter @daveberm

Panduan untuk mengkonfigurasi contoh SQL Server Failover Cluster di Azure

Maret 31, 2019 by Jason Aw Leave a Comment

Langkah-demi-Langkah: Cara Mengkonfigurasi Instance Failover Cluster SQL Server 2008 R2 di Azure

Jika Anda memerlukan panduan Mengkonfigurasi Instance Cluster Failover SQL Server di Azure, Anda mungkin masih menggunakan SQL Server 2008/2008 R2. Dan, ingin mengambil keuntungan dari pembaruan keamanan yang diperluas yang ditawarkan Microsoft jika Anda memindahkan SQL Server 2008/2008 R2 ke Azure. Saya sebelumnya menulis tentang topik ini di posting blog ini. Anda mungkin bertanya-tanya bagaimana memastikan contoh SQL Server Failover Cluster Anda tetap tersedia begitu Anda pindah ke Azure. Saat ini, kebanyakan orang memiliki bisnis kritis SQL Server 2008/2008 R2 dikonfigurasi sebagai contoh berkerumun (SQL Server FCI) di pusat data mereka. Saat melihat Azure, Anda mungkin menyadari bahwa karena kurangnya penyimpanan bersama, tampaknya Anda tidak dapat membawa SQL Server FCI ke cloud Azure. Namun, bukan itu masalahnya berkat SIOS DataKeeper. SIOS DataKeeper memungkinkan Anda untuk membangun contoh SQL Server Failover Cluster di Azure, AWS, Google Cloud, atau di mana pun di mana penyimpanan bersama tidak tersedia atau di mana Anda ingin mengonfigurasi cluster multi-situs di mana penyimpanan bersama tidak masuk akal. DataKeeper telah mengaktifkan kluster SANless untuk Windows dan Linux sejak 1999. Microsoft mendokumentasikan penggunaan SIOS DataKeeper untuk contoh SQL Server Failover Cluster dalam dokumentasi mereka: Ketersediaan tinggi dan pemulihan bencana untuk SQL Server di Mesin Virtual Azure. Saya sudah menulis tentang SQL Server FCI yang berjalan di Azure sebelumnya, Tapi saya tidak pernah menerbitkan Panduan Langkah-demi-Langkah khusus untuk SQL Server 2008/2008 R2. Berita baiknya adalah ini berfungsi sama baiknya dengan SQL 2008/2008 R2 seperti halnya dengan SQL 2012/2014/2016/2017 dan segera dirilis 2019. Selain itu, terlepas dari versi Windows Server (2008/2012/2016/2019) atau SQL Server (2008/2012/2014/2016/2017) proses konfigurasinya cukup mirip sehingga panduan ini harus cukup memadai untuk membantu Anda melalui konfigurasi. Jika rasa Anda SQL atau Windows tidak tercakup dalam salah satu panduan saya, jangan takut untuk melompat dan membangun FCI SQL Server dan referensi panduan ini, saya pikir Anda akan mengetahui perbedaan dan jika Anda pernah terjebak hanya menjangkau saya di Twitter @daveberm dan saya akan dengan senang hati membantu Anda. Panduan ini menggunakan SQL Server 2008 R2 dengan Windows Server 2012 R2. Pada saat penulisan ini saya tidak melihat gambar Azure Marketplace dari SQL 2008 R2 pada Windows Server 2012 R2, jadi saya harus mengunduh dan menginstal SQL 2008 R2 secara manual. Secara pribadi saya lebih suka kombinasi ini, tetapi jika Anda perlu menggunakan Windows Server 2008 R2 atau Windows 212 itu bagus. Jika Anda menggunakan Windows Server 2008 R2 jangan lupa untuk menginstal Pembaruan Rollup kb3125574Convenience untuk Windows Server 2008 R2 SP1. Atau jika Anda terjebak dengan Server 2012 (bukan R2), Anda memerlukan perbaikan terbaru di kb2854082. Jangan tertipu oleh artikel ini yang mengatakan Anda harus menginstal kb2854082 pada contoh SQL Server 2008 R2 Anda. Jika Anda mulai mencari pembaruan untuk Windows Server 2008 R2 Anda akan menemukan bahwa hanya versi untuk Server 2012 yang tersedia. Perbaikan terbaru khusus itu untuk Server 2008 R2 yang termasuk dalam rollup pembaruan kenyamanan Rollup untuk Windows Server 2008 R2 SP1.

INSTAN AZURE KETENTUAN

Saya tidak akan membahas detail di sini dengan banyak tangkapan layar, terutama karena Azure Portal UI cenderung berubah cukup sering, sehingga tangkapan layar yang saya ambil akan menjadi sangat cepat. Sebagai gantinya, saya hanya akan membahas topik-topik penting yang harus Anda ketahui.

DOMAIN KESALAHAN ATAU KETERSEDIAAN ZONA?

Untuk memastikan instance SQL Server Anda sangat tersedia, Anda harus memastikan node cluster Anda berada di berbagai Domain Kesalahan (FD) atau di Zona Ketersediaan yang berbeda (AZ). Instance Anda tidak hanya perlu berada di FD atau AZ yang berbeda, tetapi File Share Witness Anda (lihat di bawah) juga perlu berada di FD atau AZ yang berbeda dari yang ada di mana node cluster Anda berada. Ini pendapat saya. AZ adalah fitur Azure terbaru, tetapi mereka hanya didukung di beberapa wilayah sejauh ini. AZ memberi Anda SLA yang lebih tinggi (99,99%) kemudian FD (99,95%), dan melindungi Anda terhadap jenis pemadaman awan yang saya jelaskan dalam posting saya Azure Outage Post-Mortem. Jika Anda dapat menggunakan di wilayah yang mendukung AZ maka saya sarankan Anda menggunakan AZ. Dalam panduan ini saya menggunakan AZ yang akan Anda lihat ketika Anda sampai pada bagian tentang mengkonfigurasi penyeimbang beban. Namun, jika Anda menggunakan FD, semuanya akan persis sama, kecuali konfigurasi penyeimbang beban akan merujuk pada Kumpulan Ketersediaan daripada Zona Ketersediaan.

APA ITU FILE SHARE SAKSI YANG ANDA TANYAKAN?

Tanpa merinci lebih jauh, Windows Server Failover Clustering (WSFC) mengharuskan Anda mengonfigurasi "Witness" untuk memastikan bahwa failover berperilaku baik. Windows Server Failover Clustering mendukung tiga jenis saksi: Disk, File Share, Cloud. Karena kita berada di Azure, Saksi Disk tidak mungkin. Cloud Witness hanya tersedia dengan Windows Server 2016 dan yang lebih baru, sehingga meninggalkan kami dengan File Share Witness. Jika Anda ingin mempelajari lebih lanjut tentang kuorum klaster, lihat pos saya di Microsoft Press Blog, Dari MVP: Memahami Kuorum Cluster Failover Server Windows di Windows Server 2012 R2

TAMBAHKAN PENYIMPANAN KEPADA INSTAN SQL SERVER ANDA

Saat Anda menyediakan instance SQL Server Anda, Anda akan ingin menambahkan disk tambahan untuk setiap instance. Minimal Anda akan memerlukan satu disk untuk Data SQL dan file Log, satu disk untuk Tempdb. Apakah Anda harus memiliki disk terpisah untuk file log dan data agak diperdebatkan saat berjalan di cloud. Di bagian belakang, penyimpanan semua berasal dari tempat yang sama dan ukuran instance Anda membatasi total IOPS Anda. Menurut pendapat saya benar-benar tidak ada nilai dalam memisahkan log dan file data Anda karena Anda tidak dapat memastikan bahwa mereka berjalan pada dua set fisik disk. Saya akan membiarkan itu untuk Anda putuskan, tetapi saya menaruh log dan data semua pada volume yang sama. Biasanya SQL Server 2008 R2 FCI akan meminta Anda untuk meletakkan tempdb pada disk berkerumun. Namun, SIOS DataKeeper memiliki fitur yang sangat bagus ini disebut DataKeeper Non-Mirrored Volume Resource. Panduan ini tidak mencakup memindahkan tempdb ke sumber daya volume yang tidak dicerminkan ini, tetapi untuk kinerja yang optimal Anda harus melakukan ini. Sebenarnya tidak ada alasan yang baik untuk mereplikasi tempdb karena itu diciptakan pada saat failover. Sejauh penyimpanan terkait Anda dapat menggunakan jenis penyimpanan apa pun, tetapi tentu saja menggunakan Managed Disk kapan pun memungkinkan. Pastikan setiap node dalam gugus memiliki konfigurasi penyimpanan yang identik. Setelah Anda meluncurkan instance, Anda ingin melampirkan disk ini dan memformatnya NTFS. Pastikan setiap instance menggunakan huruf drive yang sama.

JARINGAN

Ini bukan persyaratan yang sulit, tetapi jika mungkin gunakan ukuran instance yang mendukung jaringan yang dipercepat. Juga, pastikan Anda mengedit antarmuka jaringan di portal Azure sehingga instance Anda menggunakan alamat IP statis. Agar pengelompokan berfungsi dengan baik, Anda ingin memastikan Anda memperbarui pengaturan untuk server DNS sehingga menunjuk ke Windows AD / DNS server Anda dan bukan hanya beberapa server DNS publik.

KEAMANAN

Secara default, komunikasi antara node dalam jaringan virtual yang sama terbuka lebar, tetapi jika Anda telah mengunci Grup Keamanan Azure Anda, Anda perlu tahu port apa yang harus terbuka antara node cluster dan menyesuaikan grup keamanan Anda. Dalam pengalaman saya, hampir semua masalah yang akan Anda temui ketika membangun sebuah cluster di Azure disebabkan oleh port yang diblokir. DataKeeper memiliki beberapa port yang harus dibuka antara instance clustered. Port-port itu adalah sebagai berikut: UDP: 137, 138 TCP: 139, 445, 9999, plus port dalam rentang 10000 hingga 10025 Failover cluster memiliki serangkaian persyaratan port sendiri yang bahkan tidak akan saya coba dokumentasikan di sini. Artikel ini sepertinya sudah dibahas. http://dsfnet.blogspot.com/2013/04/windows-server-clustering-sql-server.html Selain itu, Load Balancer yang dijelaskan nanti akan menggunakan port probe yang harus mengizinkan lalu lintas masuk pada setiap node. Port yang umum digunakan dan dijelaskan dalam panduan ini adalah 59999. Dan akhirnya jika Anda ingin klien Anda dapat mencapai contoh SQL Server Anda, Anda ingin memastikan port SQL Server Anda terbuka, yang secara default adalah 1433. Ingat, port ini dapat diblokir oleh Windows Firewall atau Azure Security Groups, jadi pastikan untuk memeriksa keduanya untuk memastikan mereka dapat diakses.

GABUNGKAN DOMAIN

Persyaratan untuk SQL Server 2008 R2 FCI adalah bahwa instance harus berada di Windows Server Domain yang sama. Jadi, jika Anda belum melakukannya, pastikan Anda telah bergabung dengan instance ke domain Windows Anda

AKUN LAYANAN LOKAL

Ketika Anda menginstal DataKeeper, ia akan meminta Anda untuk memberikan akun layanan. Anda harus membuat akun pengguna domain dan kemudian menambahkan akun pengguna itu ke Grup Administrator Lokal pada setiap node. Ketika ditanya selama instalasi DataKeeper, tentukan akun itu sebagai akun layanan DataKeeper. Catatan – Jangan menginstal DataKeeper dulu!

KELOMPOK KEAMANAN DOMAIN GLOBAL

Anda akan diminta untuk menentukan dua Grup Keamanan Domain Global saat Anda menginstal SQL 2008 R2. Anda mungkin ingin melihat ke depan pada petunjuk instalasi SQL dan membuat grup tersebut sekarang. Juga, buat akun pengguna domain dan letakkan di masing-masing akun keamanan ini. Anda akan menentukan akun ini sebagai bagian dari instalasi SQL Server Cluster.

PERSYARATAN LAINNYA

Anda harus mengaktifkan Failover Clustering dan .Net 3.5 pada setiap instance dari dua instance cluster. Ketika Anda mengaktifkan Failover Clustering, pastikan juga untuk mengaktifkan "Server Failover Cluster Automation" opsional. Ini diperlukan untuk SQL Server 2008 R2 cluster di Windows Server 2012 R2.

BUAT SUMBER DAYA CLUSTER DAN DATAKEEPER

Kami sekarang siap untuk mulai membangun cluster. Langkah pertama adalah membuat basis cluster. Karena cara Azure menangani DHCP, kami HARUS membuat cluster menggunakan Powershell dan bukan Cluster UI. Kami menggunakan Powershell karena itu akan memungkinkan kami menentukan alamat IP statis sebagai bagian dari proses pembuatan. Jika kami menggunakan UI, itu akan melihat bahwa VM menggunakan DHCP dan itu akan secara otomatis menetapkan alamat IP duplikat. Karena itu untuk menghindari situasi itu, mari kita gunakan Powershell seperti yang ditunjukkan di bawah ini.

New-Cluster -Name cluster1 -Node sql1, sql2 -StaticAddress 10.0.0.100 -NoStorage

Setelah cluster membuat, jalankan Test-Cluster. Ini diperlukan sebelum SQL Server akan menginstal.

Test-Cluster

Anda akan mendapatkan peringatan tentang Penyimpanan dan Jaringan. Untungnya, Anda dapat mengabaikannya seperti yang diharapkan pada kluster SANless di Azure. Namun, atasi peringatan atau kesalahan lainnya sebelum melanjutkan. Setelah cluster dibuat, Anda perlu menambahkan File Share Witness. Pada server ketiga kami tentukan sebagai saksi berbagi file, buat berbagi file dan berikan izin Baca / Tulis ke objek komputer cluster yang baru saja kita buat di atas. Dalam hal ini $ Cluster1 akan menjadi nama objek komputer yang membutuhkan izin Baca / Tulis di tingkat keamanan berbagi dan NTFS. Setelah berbagi dibuat, Anda dapat menggunakan panduan kuorum konfigurasi Cluster seperti yang ditunjukkan di bawah ini untuk mengkonfigurasi File Share Witness.

INSTAL DATAKEEPER

Penting untuk menunggu hingga klaster dasar dibuat sebelum kita menginstal DataKeeper, karena instalasi DataKeeper mendaftarkan tipe Sumber Daya Volume DataKeeper dalam kluster failover. Jika Anda melompat pistol dan sudah menginstal DataKeeper tidak apa-apa. Cukup jalankan pengaturan lagi dan pilih Perbaiki Instalasi. Screenshot di bawah ini memandu Anda melalui instalasi dasar. Mulai dengan menjalankan Pengaturan DataKeeper.

Akun yang Anda tentukan di bawah ini harus akun domain. Itu harus menjadi bagian dari grup Administrator Lokal pada setiap node cluster.

Ketika disajikan dengan manajer Kunci Lisensi SIOS, Anda dapat menelusuri kunci sementara Anda. Atau jika Anda memiliki kunci permanen, Anda dapat menyalin ID Host Sistem dan menggunakannya untuk meminta lisensi permanen Anda. Jika Anda perlu menyegarkan kunci, SIOS License Key Manager adalah program yang akan diinstal yang dapat Anda jalankan secara terpisah untuk menambahkan kunci baru.

BUAT SUMBER DATAKEEPER VOLUME

Setelah DataKeeper diinstal pada setiap node, Anda siap membuat Sumber Daya Volume DataKeeper pertama Anda. Langkah pertama adalah membuka UI DataKeeper dan menghubungkan ke masing-masing node cluster.

Jika semuanya dilakukan dengan benar, Laporan Ikhtisar Server akan terlihat seperti ini.

Anda sekarang dapat membuat Pekerjaan pertama Anda seperti yang ditunjukkan di bawah ini.

Setelah Anda memilih Sumber dan Target, Anda akan diberikan opsi berikut. Untuk target lokal di wilayah yang sama, satu-satunya yang perlu Anda pilih adalah Sinkron.

Pilih Ya dan daftarkan otomatis volume ini sebagai sumber daya klaster.

Setelah Anda menyelesaikan proses ini, buka Failover Cluster Manager dan cari di Disk. Anda harus melihat sumber daya Volume DataKeeper di Penyimpanan yang Tersedia. Pada titik ini WSFC memperlakukan ini seolah-olah itu adalah sumber daya disk cluster yang normal.

SLIPSTREAM SP3 ONTO SQL 2008 R2 INSTALL MEDIA

SQL Server 2008 R2 hanya didukung pada Windows Server 2012 R2 dengan SQL Server SP2 atau yang lebih baru. Sayangnya, Microsoft tidak pernah merilis media instalasi SQL Server 2008 R2 yang menyertakan SP2 atau SP3. Sebagai gantinya, Anda harus memasukkan paket layanan ke media instalasi sebelum Anda melakukan instalasi. Jika Anda mencoba melakukan instalasi dengan media SQL Server 2008 R2 standar, Anda akan mengalami semua jenis masalah. Saya tidak ingat kesalahan pasti yang akan Anda lihat. Tapi saya ingat mereka tidak benar-benar menunjukkan masalah yang sebenarnya. Anda akan menghabiskan banyak waktu untuk mencari tahu apa yang salah. Pada tanggal penulisan ini, Microsoft tidak memiliki Windows Server 2012 R2 dengan penawaran SQL Server 2008 R2 di Azure Marketplace. Jangan membawa lisensi SQL Anda sendiri jika Anda ingin menjalankan SQL 2008 R2 pada Windows Server 2012 R2 di Azure. Jika mereka menambahkan gambar itu nanti, atau jika Anda memilih untuk menggunakan SQL 2008 R2 pada gambar Windows Server 2008 R2, Anda harus terlebih dahulu menghapus instalan contoh mandiri SQL Server yang ada sebelum melanjutkan. Saya mengikuti panduan dalam Opsi 1 artikel ini untuk memasukkan SP3 ke media instalasi SQL 2008 R2 saya. Anda tentu saja harus menyesuaikan beberapa hal karena artikel ini merujuk SP2 daripada SP3. Pastikan Anda memasukkan SP3 pada media instalasi yang akan kami gunakan untuk kedua node cluster. Setelah selesai, lanjutkan ke langkah berikutnya.

INSTAL SQL SERVER PADA NODE PERTAMA

Menggunakan media SQL Server 2008 R2 dengan SP3 slipstream, jalankan setup dan instal node pertama dari cluster seperti yang ditunjukkan di bawah ini.

Jika Anda menggunakan selain dari contoh Default SQL Server, Anda akan memiliki beberapa langkah tambahan yang tidak tercakup dalam panduan ini. Perbedaan terbesar adalah Anda harus mengunci port yang digunakan SQL Server karena secara default contoh bernama SQL Server TIDAK menggunakan 1433. Setelah Anda mengunci port, Anda juga perlu menentukan port itu alih-alih 1433 setiap kali kami merujuk port 1433 dalam panduan ini, termasuk pengaturan firewall dan pengaturan Load Balancer.

Di sini pastikan untuk menentukan alamat IP baru yang tidak digunakan. Ini adalah alamat IP yang sama yang akan kita gunakan nanti ketika kita mengkonfigurasi Internal Load Balancer nanti.

Seperti yang saya sebutkan sebelumnya, SQL Server 2008 R2 menggunakan Grup Keamanan AD. Jika Anda belum membuatnya, silakan dan buat sekarang seperti yang ditunjukkan di bawah ini sebelum Anda melanjutkan ke langkah berikutnya dalam instalasi SQL

Tentukan Grup Keamanan yang Anda buat sebelumnya.

Pastikan akun layanan yang Anda tentukan adalah anggota Grup Keamanan terkait.

Tentukan administrator SQL Server Anda di sini.

Jika semuanya berjalan dengan baik, Anda sekarang siap untuk menginstal SQL Server pada node kedua cluster.

INSTAL SQL SERVER PADA DATA KEDUA

Satu simpul kedua, jalankan SQL Server 2008 R2 dengan SP3 instal dan pilih Add Node ke SQL Server Failover Clustering Instance.

Lanjutkan dengan instalasi seperti yang ditunjukkan pada tangkapan layar berikut.

Dengan asumsi semuanya berjalan dengan baik, Anda sekarang harus memiliki dua node SQL Server 2008 R2 cluster yang dikonfigurasi yang terlihat seperti berikut ini.

Namun, Anda mungkin akan melihat bahwa Anda hanya bisa menyambungkan ke contoh SQL Server dari node cluster aktif. Masalahnya adalah bahwa Azure tidak mendukung ARP serampangan. Klien Anda mungkin tidak dapat terhubung langsung ke Alamat IP Cluster. Sebagai gantinya, klien harus terhubung ke Azure Load Balancer, yang akan mengarahkan ulang koneksi ke node aktif. Untuk membuat ini bekerja ada dua langkah: Buat Load Balancer dan Perbaiki SQL Server Cluster IP untuk menanggapi Load Balancer Probe dan gunakan subnet mask 255.255.255.255. Langkah-langkah tersebut dijelaskan di bawah ini.

BUAT BALANCER LOAD AZURE

Saya akan menganggap klien Anda dapat berkomunikasi langsung ke alamat IP internal SQL cluster. Mari kita lanjutkan untuk membuat Internal Load Balancer (ILB) dalam panduan ini. Jika Anda perlu mengekspos Instance SQL Anda di internet publik, gunakan Public Load Balancer sebagai gantinya. Di portal Azure, buat Load Balancer baru mengikuti tangkapan layar seperti yang ditunjukkan di bawah ini. UI portal Azure berubah dengan cepat. Tapi tangkapan layar ini akan memberi Anda informasi yang cukup untuk melakukan apa yang perlu Anda lakukan. Saya akan memanggil pengaturan penting saat kita melanjutkan. Di sini kita membuat ILB. Yang penting untuk dicatat pada layar ini adalah Anda harus memilih "Penugasan alamat IP statis". Tentukan alamat IP yang sama yang kami gunakan selama instalasi SQL Cluster juga. Karena saya menggunakan Zona Ketersediaan, saya melihat Zone Redundant sebagai opsi. Jika Anda menggunakan Set Ketersediaan, pengalaman Anda akan sedikit berbeda.

Di kolam Backend pastikan untuk memilih dua contoh SQL Server. Anda TIDAK ingin menambahkan File Share Witness Anda di pool.

Di sini kita mengkonfigurasi Probe Kesehatan. Sebagian besar dokumentasi Azure menggunakan port 59999, jadi kami akan tetap menggunakan port itu untuk konfigurasi kami.

Kemudian kita akan menambahkan aturan load balancing. Dalam kasus kami, kami ingin mengarahkan semua lalu lintas SQL Server ke port TCP 1433 dari simpul aktif. Penting juga bahwa Anda memilih Floating IP (Direct Server Return) sebagai Diaktifkan.

JALANKAN POWERSHELL SCRIPT UNTUK MEMPERBARUI POINT AKSES KLIEN SQL

Sekarang kita harus menjalankan skrip Powershell di salah satu node cluster untuk memungkinkan Load Balancer Probe mendeteksi node mana yang aktif. Script juga menetapkan Subnet Mask dari SQL Cluster IP Address ke 255.255.255.255.255 sehingga ia menghindari konflik alamat IP dengan Load Balancer yang baru saja kita buat.

# Tentukan variabel
$ ClusterNetworkName = "" 
nama jaringan kluster (Gunakan Get-ClusterNetwork di Windows Server 2012 of 
lebih tinggi untuk menemukan nama)
$ IPResourceName = "" 
# nama sumber daya Alamat IP 
$ ILBIP = "" 
# Alamat IP Internal Load Balancer (ILB) dan SQL Cluster
Impor-Modul FailoverClusters
# Jika Anda menggunakan Windows Server 2012 atau lebih tinggi:
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Multiple @ {Alamat = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255";
Network = $ ClusterNetworkName; EnableDhcp = 0}
# Jika Anda menggunakan Windows Server 2008 R2 gunakan ini: 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999  
subnetmask = 255.255.255.255

Ini akan terlihat seperti apa hasil jika dijalankan dengan benar.

Anda mungkin memperhatikan bahwa akhir skrip itu memiliki baris kode komentar untuk digunakan jika Anda menjalankan Windows Server 2008 R2. Menjalankan Windows Server 2008 R2? Pastikan Anda menjalankan kode khusus untuk Windows Server 2008 R2 pada prompt perintah, itu bukan Powershell.

LANGKAH SELANJUTNYA

Anda bukan yang pertama jika Anda sampai pada titik ini dan Anda masih tidak dapat terhubung ke cluster dari jarak jauh. Ada banyak hal yang bisa salah dalam hal keamanan, load balancer, port SQL, dll. Saya menulis panduan ini untuk membantu memecahkan masalah koneksi. Bahkan, saya mengalami beberapa masalah aneh dalam hal SQL Server TCP / IP Properties di SQL Server Configuration Manager. Ketika saya melihat properti saya tidak melihat alamat IP SQL Server Cluster sebagai salah satu alamat yang didengarkan. Karena itu saya harus menambahkannya secara manual. Saya tidak yakin apakah itu anomali. Meskipun itu tentu saja merupakan masalah yang harus saya selesaikan sebelum saya bisa terhubung ke cluster dari klien jarak jauh. Seperti yang saya sebutkan sebelumnya, satu perbaikan lain yang dapat Anda lakukan untuk instalasi ini adalah dengan menggunakan DataKeeper Non-Mirrored Volume Resource untuk TempDB. Jika Anda mengaturnya, harap perhatikan dua masalah konfigurasi berikut yang biasa dialami orang. Masalah pertama adalah jika Anda memindahkan tempdb ke folder pada simpul ke-1, Anda harus yakin untuk membuat struktur folder yang sama persis pada simpul kedua. Jika Anda tidak melakukan itu, ketika Anda mencoba untuk gagal SQL Server akan gagal untuk online karena tidak dapat membuat TempDB. Masalah kedua terjadi kapan saja Anda menambahkan Sumber Daya Volume DataKeeper lain ke SQL Cluster setelah cluster dibuat. Anda harus masuk ke properti sumber daya gugusan SQL Server dan membuatnya tergantung pada sumber daya Volume DataKeeper baru yang Anda tambahkan. Ini berlaku untuk volume TempDB dan volume lainnya yang dapat Anda putuskan untuk ditambahkan setelah cluster dibuat. Jika Anda memiliki pertanyaan tentang konfigurasi ini atau konfigurasi cluster lainnya, jangan ragu untuk menghubungi saya di Twitter @DaveBerm.

https://clusteringformeremortals.com/2016/01/06/troubleshooting-azure-ilb-connection-issues-in-a-qq-server-alwayson-fci-cluster/

Diproduksi ulang dengan izin dari Clusteringformeremortals.com

Mencapai SQL Server Pemulihan Bencana Ketersediaan Tinggi Dengan DataKeeper

Maret 26, 2019 by Jason Aw Leave a Comment

Mencapai SQL Server Ketersediaan Tinggi, Pemulihan Bencana Dengan Campuran Grup Selalu Tersedia dan SANless SQL Server Failover Cluster Instances

pengantar

Topik pencampuran SQL Server Failover Cluster Instances (FCI) dengan Always On Availability Groups (AG) didokumentasikan dengan cukup baik. Namun, sebagian besar konfigurasi dokumen dokumentasi yang tersedia yang mengasumsikan bagian SQL Server FCI dari solusi menggunakan penyimpanan bersama. Bagaimana jika saya ingin membangun SANless SQL Server FCI menggunakan Storage Spaces Direct (S2D), apakah saya masih dapat menambahkan SQL Server AG ke dalam campuran? Sayangnya, jawaban untuk pertanyaan ini adalah tidak. Sampai hari ini, kombinasi S2D berbasis SQL Server FCI dan Always On AG ini tidak didukung. Saya sebelumnya menulis blog tentang batasan S2D ini di sini. Namun, kabar baiknya adalah Anda BISA membangun SANless SQL Server FCI dengan SIOS DataKeeper dan masih memanfaatkan Always On AG untuk hal-hal seperti sekunder yang dapat dibaca. Anda masih harus mematuhi aturan yang sama yang berlaku ketika mencampur SQL Server FCI tradisional berbasis SAN dan Always On AGs, tetapi sebagian besar untuk mencapai SQL Server ketersediaan tinggi hampir sama. Replikasi Sinkronisasi DataKeeper umumnya digunakan antara node di pusat data atau wilayah cloud yang sama, tetapi Anda mungkin ingin mereplikasi secara tidak sinkron ke node tambahan di wilayah berbeda untuk pemulihan bencana. Dalam hal ini, jika Anda harus membawa DR node online setelah kegagalan tak terduga, Anda harus menghapus konfigurasi Always On AG dan mengkonfigurasi ulang mereka. Persyaratan ini sangat mirip dengan apa yang Microsoft terbitkan di sini sehubungan dengan mengembalikan snapshot asinkron dari SQL Server Always On AG yang berjalan di dalam VM.

Grup yang Tersedia

Pada dasarnya, Instance SQL Server Failover Cluster Instance dengan DataKeeper terlihat seperti turunan tunggal dari SQL Server sejauh yang selalu ada pada Wizard Grup Ketersediaan. Konfigurasi Selalu Aktif AG persis sama seperti jika Anda hanya membuat Selalu Aktif AG antara dua contoh SQL Server Standalone (non-clustered). Kebingungan nyata muncul pada kenyataan bahwa dalam konfigurasi ini semua server berada di kluster failover yang sama. Tetapi SQL Server FCI hanya dikonfigurasi untuk berjalan hanya pada node cluster di mana SQL Server diinstal sebagai SQL Server Clustered. Node lain berada di cluster yang sama. Namun, SQL diinstal pada node tersebut sebagai Mesin Virtual SQL Server Standalone, bukan Mesin Virtual Clustered. Agak membingungkan. Pada dasarnya apa yang terjadi adalah bahwa Always On AG memanfaatkan model kuorum dan pendengar WSFC. Dengan demikian semua Replika AG harus berada di WSFC yang sama, meskipun mereka biasanya tidak menjalankan contoh SQL Server yang dikelompokkan. Jika Anda benar-benar bingung tidak apa-apa, kebanyakan orang bingung ketika mereka pertama kali mencoba membungkus kepala mereka dengan konfigurasi hybrid ini. Manfaat nyata dalam konfigurasi seperti ini adalah bahwa SQL Server Failover Cluster Instance dapat menjadi lebih baik dan lebih hemat biaya (lebih lanjut tentang ini nanti *) Solusi Ketersediaan Tinggi daripada Selalu Di AG dalam banyak keadaan, tetapi tidak memiliki kemampuan untuk menawarkan replika sekunder yang dapat dibaca. Menambahkan replika sekunder Always On AG yang dapat dibaca menjadi opsi yang layak untuk mengatasi kebutuhan ini. Dan menggunakan SIOS DataKeeper menghilangkan kebutuhan untuk SAN untuk SQL Server FCI, yang membuka kemungkinan mengkonfigurasi SQL Server FCI di mana node berada di pusat data yang berbeda, yang juga berarti dukungan untuk SQL Server FCI yang menjangkau Zona Ketersediaan di Azure dan AWS. Harap perhatikan bahwa gambar di bawah ini hanya satu konfigurasi yang memungkinkan. Beberapa node cluster FCI, beberapa AG, dan beberapa Replika semuanya didukung. Anda hanya dibatasi oleh batasan yang diberlakukan oleh versi SQL Server Anda. Artikel ini sepertinya mendokumentasikan langkah-langkah pengaturan dengan cukup baik. Tentu saja, alih-alih penyimpanan bersama untuk SQL FCI, Anda akan menggunakan SIOS DataKeeper untuk membangun FCI seperti yang saya dokumentasikan di sini.

Grup Ketersediaan Dasar

Pada SQL Server 2016 yang diperkecil "Kelompok Ketersediaan Dasar" menjadi tersedia di SQL Server Edisi Standar, membuat konfigurasi ini mungkin bahkan dalam SQL Server Edisi Standar. AG Dasar terbatas pada basis data tunggal per Grup yang Tersedia, Replika Tunggal (2-simpul). Namun, mereka tidak mendukung replika sekunder yang dapat dibaca sehingga kasus penggunaannya dalam konfigurasi hibrid ini sangat terbatas.

Grup Ketersediaan yang Didistribusikan

AG terdistribusi yang diperkenalkan di SQL Server 2016 juga didukung dalam konfigurasi hibrid ini. AG terdistribusi sangat mirip dengan AG biasa, tetapi Replika tidak perlu berada di cluster yang sama, atau bahkan di Domain Windows yang sama. Microsoft mendokumentasikan kasus penggunaan utama dari Grup Ketersediaan Terdistribusi sebagai berikut:

Pemulihan bencana dan konfigurasi multi-situs yang lebih mudah
Migrasi ke perangkat keras atau konfigurasi baru, yang mungkin termasuk menggunakan perangkat keras baru atau mengubah sistem operasi yang mendasarinya
Meningkatkan jumlah replika yang dapat dibaca melebihi delapan dalam satu kelompok ketersediaan tunggal dengan menjangkau beberapa kelompok ketersediaan

Hasil gambar untuk grup ketersediaan yang didistribusikan

Ringkasan

Jika Anda menyukai gagasan SQL Server FCI untuk SQL Server ketersediaan tinggi, tetapi menginginkan fleksibilitas replika sekunder hanya baca, solusi hibrid ini mungkin hanya hal yang Anda cari. FCI SQL Server tradisional berbasis FCI, dan bahkan FCI berbasis Storage Spaces Direct (S2D), membatasi Anda untuk pusat data tunggal. SIOS DataKeeper membebaskan Anda dari batas SAN Anda dan memungkinkan konfigurasi seperti SQL Server FCI yang menjangkau Zona Ketersediaan atau Wilayah Cloud. Ini juga menghilangkan ketergantungan pada SAN, memungkinkan Anda untuk memanfaatkan perangkat penyimpanan berkecepatan tinggi yang terpasang secara lokal tanpa melepaskan SQL Server Failover Cluster Instance Anda.

* Cara Menghemat Uang

Sebelumnya saya berjanji saya akan memberitahu Anda bagaimana cara menghemat uang dengan melakukan ini semua dengan SQL Server Standard Edition. Jika Anda dapat hidup dengan replika yang dapat dibaca yang merupakan snapshot berbasis waktu, Anda dapat melewati Always On AGs sepenuhnya dan cukup gunakan fitur snapshot sisi target SIOS DataKeeper untuk secara berkala mengambil snapshot konsisten volume aplikasi di server target tanpa memengaruhi replikasi yang sedang berlangsung atau ketersediaan. Begini caranya …

http://discover.us.sios.com/rs/siostechnology/images/10-Ways-Save-AlwaysOn-vs-Failover-Clustering.pdf

Buat 2-node SQL Server FCI dengan SQL Server Standard Edition dan hemat sejumlah uang pada lisensi SQL. Namun masih mereplikasi data ke simpul ke-3 di luar cluster untuk tujuan pelaporan atau DR. Jika Anda mengambil snapshot dari volume di server ketiga ini, snapshot ini dapat diakses dengan benar. Dengan cara ini, Anda dapat me-mount database tersebut dari instance SQL Server mandiri untuk menjalankan laporan akhir bulan, menyalin ke arsip, atau Anda bahkan mungkin ingin menggunakan snapshot itu untuk secara cepat dan mudah memperbarui lingkungan QA dan Test / Dev Anda dengan SQL terbaru data. Saya harap Anda menemukan panduan untuk membuat untuk mencapai SQL Server ketersediaan tinggi, pemulihan bencana dengan campuran Grup Ketersediaan Selalu dan Instan SQL Server Failover Failover Cluster berguna.

Mengambil tindakan sebelum dukungan SQL Server 2008/2008 R2 kedaluwarsa

Januari 13, 2019 by Jason Aw Leave a Comment

Centang Tock… 6 Bulan Sampai Dukungan SQL Server 2008/2008 R2 Berakhir Kecuali Anda Melakukan

Masih menjalankan SQL Server 2008/2008 R2? Anda mungkin telah mendengar sekarang bahwa pada 9 Juli 2019, Anda tidak akan lagi didukung. Microsoft telah menawarkan dua opsi untuk memberikan pembaruan keamanan yang diperpanjang untuk tiga tahun tambahan bagi pelanggan yang masih berjalan pada platform ini dan tidak dapat memutakhirkan ke versi SQL yang lebih baru sebelum batas waktu.

Pilihan pertama

Untuk mencegah Dukungan SQL Server 2008/2008 R2 Kedaluwarsa sebelum Anda siap, opsi pertama yang Anda miliki memerlukan pembelian tahunan "Pembaruan Keamanan yang Diperpanjang". Pembaruan Keamanan yang Diperpanjang akan menelan biaya 75% dari biaya lisensi penuh setiap tahun. Ini juga mensyaratkan bahwa pelanggan pada jaminan perangkat lunak aktif, yang biasanya 25% dari biaya lisensi setiap tahun. Jadi secara efektif, untuk menerima Pembaruan Keamanan yang Diperpanjang Anda membayar lisensi SQL Server baru setiap tahun selama tiga tahun, atau sampai Anda bermigrasi dari SQL Server 2008/2008 R2.

Opsi kedua

Namun, ada opsi kedua lain sebelum Dukungan SQL Server 2008/2008 R2 Anda Berakhir. Microsoft telah mengumumkan bahwa jika Anda memindahkan instance SQL Server 2008 R2 Anda ke Azure, Anda akan menerima Pembaruan Keamanan yang Diperpanjang tanpa biaya tambahan. Tentu saja ada biaya infrastruktur per jam yang akan Anda tanggung di Azure. Dan juga biaya pembayaran saat Anda masuk contoh SQL Server atau biaya Jaminan Perangkat Lunak jika Anda ingin membawa lisensi SQL yang ada ke Azure. Tetapi biaya itu termasuk manfaat tambahan dari berlari dalam keadaan lingkungan cloud art. Ini membuka peluang untuk peningkatan kinerja dan skenario HA / DR yang mungkin belum Anda miliki di lokasi.

Pilihan Array

Azure menawarkan banyak opsi berbeda dalam hal konfigurasi CPU, Memori dan Penyimpanan. Jika Anda mencari peningkatan server atau penyimpanan, atau infrastruktur lokal yang ada saat ini sedang mencapai siklus penyegaran, sekarang adalah waktu yang tepat untuk mencelupkan kaki Anda ke awan Azure dan meningkatkan kinerja dan ketersediaan Anda pada saat yang sama dengan memperluas masa penggunaan SQL Server 2008/2008 R2 Anda.

SLA 99,99%

Dalam hal ketersediaan tinggi dan konfigurasi pemulihan bencana, Azure menawarkan hingga 99,99% SLA. Agar memenuhi syarat untuk SLA, Anda harus memanfaatkan infrastruktur mereka dengan tepat. Bahkan kemudian, SLA hanya mencakup "nada panggil" untuk instance. Terserah Anda untuk memastikan SQL Server sangat tersedia, yang secara tradisional dilakukan dengan membangun SQL Server Failover Cluster Instance (FCI). Azure memiliki infrastruktur yang memungkinkan Anda untuk mengkonfigurasi SQL Server FCI. Tetapi karena kurangnya penyimpanan bersama cluster sadar di awan, Anda akan perlu menggunakan SIOS DataKeeper untuk membangun FCI.

Manfaat SIOS DataKeeper

SIOS DataKeeper menggantikan penyimpanan bersama yang biasanya diperlukan oleh SQL Server FCI. Alih-alih itu memungkinkan Anda untuk meningkatkan volume yang diformat NTFS yang terlampir pada setiap contoh. SIOS menyimpan volume yang direplikasi antara instance dan menyajikan penyimpanan ke cluster sebagai sumber daya yang disebut Volume DataKeeper. Sejauh menyangkut cluster, Volume DataKeeper terlihat seperti disk berbagi, tetapi alih-alih mengendalikan reservasi SCSI (penguncian disk), ini mengontrol arah mirror yang memastikan penulisan terjadi pada server aktif dan secara sinkron atau asinkron direplikasi ke node cluster lainnya . Pengalaman pengguna akhir persis sama dengan cluster penyimpanan tradisional bersama. Meskipun di bawah penutup, kluster ini memanfaatkan penyimpanan yang terpasang secara lokal alih-alih penyimpanan bersama.

Rak yang berbeda

Di Azure, node cluster Anda dapat berjalan di berbagai rak (Fault Domains), pusat data (Zona Ketersediaan), atau bahkan di wilayah geografis yang berbeda. SIOS DataKeeper mendukung ketiga opsi: Domain Kesalahan, Zona Ketersediaan atau replikasi lintas Wilayah untuk mencakup persyaratan HA dan DR. Konfigurasi serupa juga dimungkinkan di AWS dan Google Cloud.

Konfigurasi SQL Server FCI 2-simpul di Azure dengan SIOS DataKeeper [/ caption]

Dengan Azure Site Recovery (ASR) Anda dapat meniru contoh SQL Server mandiri atau berkelompok di antara Pasangan Wilayah, tanpa sakit kepala dan biaya mengelola situs pemulihan bencana Anda sendiri. Tentu saja SQL Server jarang hidup sendirian. Oleh karena itu, pada saat yang sama Anda memindahkan instance SQL Server Anda ke Azure Anda mungkin ingin memindahkan server aplikasi Anda di sana juga untuk mengambil keuntungan dari peningkatan kinerja dan ketersediaan yang tersedia di Azure. Menggabungkan SIOS DataKeeper untuk HA dan ASR untuk DR memberikan strategi HA dan DR yang efektif biaya yang tidak mungkin, atau sangat mahal untuk diterapkan di tempat dengan replikasi SAN dan situs DR Anda sendiri.

Memulai

Meskipun hanya perlu beberapa menit untuk memutar instance SQL Server di Azure, saya tidak akan menunggu sampai menit terakhir untuk melakukan migrasi Anda. Silakan luangkan beberapa bulan ke depan untuk mengenal Azure, mulai melakukan beberapa pengujian, dan kemudian rencanakan untuk memigrasi beban kerja Anda jauh sebelum tanggal kedaluwarsa 9 Juli 2019. Menjalankan SQL Server setelah tanggal tersebut membuat Anda rentan terhadap ancaman keamanan baru dan juga membuat Anda tidak patuh. Bos Anda, dan yang lebih penting, pelanggan Anda, akan senang mengetahui bahwa data mereka masih aman, tersedia, dan sesuai setelah Anda memigrasi beban kerja Anda ke Azure.

Nikmati tip-tip seperti mencari tahu apa yang harus dilakukan setelah Dukungan SQL Server 2008/2008 R2 Kedaluwarsa, berikut adalah pos-pos hebat lainnya untuk dibaca Diproduksi ulang dengan izin dari Clusteringformeremortals.com