SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Microsoft Build 2019 Pengumuman Dan Sesi Sesuai Permintaan

by Leave a Comment

Microsoft Build 2019 Pengumuman Dan Sesi Sesuai Permintaan

Microsoft Build 2019 Pengumuman Dan Sesi Sesuai Permintaan

Ketinggalan Microsoft Build 2019 karena Anda tidak dapat pergi dari kantor untuk hadir? Anda akan senang mengetahui bahwa Microsoft telah menerbitkan semua sesi dan tersedia online tanpa biaya.

Microsoft Build 2019 Pengumuman Dan Sesi Sesuai Permintaan

Menjadi konferensi yang berfokus pada pengembang, sebagian besar pengumuman ditujukan untuk pengembang. Anda dapat melihat daftar lengkap pengumuman yang dapat dicari di sini. https://azure.microsoft.com/en-us/updates/?updatetype=microsoft-build&Page=1

Apa itu Infrastruktur sebagai Kode?

Saya lebih dari seorang pria infrastruktur. Beberapa pengumuman yang lebih menarik bagi saya adalah sebagai berikut.

Solusi Azure VMware sekarang tersedia secara umum

Jika saya banyak berinvestasi di VMware dan ingin memperluas ke Azure, ketersediaan Solusi Azure VMware tentu akan membuka beberapa kemungkinan menarik. Sepertinya jika saya menggunakan contoh bare-metal atau contoh khusus, saya pada dasarnya dapat memiliki host ESX yang berjalan di Azure. Ini masuk akal bagi mereka yang merencanakan penyebaran cloud-hybrid dan ingin dengan mudah memindahkan beban kerja bolak-balik antara on-prem dan Azure. Tinggalkan saya komentar untuk memberi tahu saya mengapa ini menggairahkan Anda.

Azure Quickstart Center memungkinkan pelanggan baru untuk membangun proyek cloud dengan percaya diri

Saya belum melihat ini. Namun, ini terlihat SANGAT menarik bagi saya jika memang itu yang saya pikirkan. Seiring adopsi cloud terus tumbuh, demikian pula keahlian yang diperlukan dari profesional TI. Seorang profesional TI yang bijak ingin menjadi nyaman dengan Infrastruktur sebagai Kode (IaC). Hanya dua tahun yang lalu, rangkaian keterampilan ini tidak ada. Konsultan IT atau penyedia cloud yang lebih besar mungkin memiliki sedikit atau bahkan tidak memiliki pengalaman sama sekali. Selama setahun terakhir saya telah melihat keahlian ini menjadi lebih umum dengan pelanggan yang bekerja dengan saya. Ini sering merupakan metode penyebaran yang disukai. Pada saat yang sama, teknologi IaS juga telah matang. Saya memperkirakan bahwa jika Anda belum mengelola penyebaran cloud Anda dengan IaC, Anda akan berada dalam waktu dekat. Saya berharap bahwa penawaran baru dari Microsoft ini dapat menjadi pengantar yang bagus bagi para profesional TI yang ingin mendapatkan pengalaman dan pengetahuan IaC. Saya akan memposting artikel tindak lanjut setelah saya melihatnya.

Webinar: Ketersediaan Tinggi untuk SQL di VMware tanpa Pemetaan Perangkat Mentah

by Leave a Comment

Ketersediaan Tinggi untuk SQL di VMware tanpa Pemetaan Perangkat Mentah Webinar: Ketersediaan Tinggi untuk SQL di VMware tanpa Pemetaan Perangkat Mentah

Webinar: Ketersediaan Tinggi untuk SQL di VMware tanpa Pemetaan Perangkat Mentah

Tahukah Anda bahwa Anda dapat memiliki perlindungan ketersediaan tinggi (HA) untuk SQL di lingkungan VMware tanpa kerepotan Raw Device Mapping (RDM)? Membuat cluster penyimpanan bersama di lingkungan VMware berarti implementasi yang rumit menggunakan RDM – dan melepaskan fitur-fitur VMware penting, seperti Vmotion. Di webinar ini, pakar pengelompokan SIOS Tony Tomarchio menunjukkan cara mudah untuk membuat kluster failover di lingkungan VMware tanpa kompleksitas atau keterbatasan fitur Pemetaan Perangkat Mentah. Pelajari lebih lanjut tentang Ketersediaan Tinggi VMWare dengan SIOS. Daftar untuk Webinar: Ketersediaan Tinggi untuk SQL di VMware tanpa Pemetaan Perangkat Mentah

Pertimbangan Penyimpanan Untuk Menjalankan SQL Server Di Azure

by Leave a Comment

Pertimbangan Penyimpanan Untuk Menjalankan SQL Server Di Azure

Menyebarkan SQL Server di Azure, atau platform Cloud apa pun? Alih-alih hanya menyediakan penyimpanan seperti yang Anda lakukan untuk penyebaran di tempat Anda selama bertahun-tahun, mempertimbangkan penyimpanan di Azure tidak persis seperti penyimpanan yang mungkin Anda miliki akses ke di tempat. Beberapa "praktik terbaik" tradisional mungkin berakhir dengan biaya tambahan uang dan memberi Anda kinerja yang kurang optimal. Namun, sambil tidak memberikan Anda manfaat yang diinginkan. Banyak hal yang akan saya bahas juga dijelaskan dalam Pedoman Kinerja untuk Azure di SQL Server Virtual Machines.

Jenis Disk

Saya di sini bukan untuk memberi tahu Anda bahwa Anda harus menggunakan UltraSSD, Penyimpanan Premium, atau jenis disk apa pun lainnya. Anda hanya perlu menyadari bahwa Anda memiliki opsi, dan apa yang dibawa oleh masing-masing tipe disk ke tabel. Tentu saja, seperti hal lain di cloud, semakin banyak uang yang Anda habiskan, semakin banyak kekuatan, kecepatan, throughput, dll., Yang akan Anda raih. Caranya adalah menemukan konfigurasi optimal yang sesuai dengan pertimbangan penyimpanan Anda sehingga Anda menghabiskan cukup banyak untuk mencapai hasil yang diinginkan.

Ukuran Tidak Peduli

Seperti banyak hal di awan, spesifikasi tertentu diikat bersama. Untuk server jika Anda menginginkan lebih banyak RAM, Anda sering mendapatkan lebih banyak CPU, bahkan jika Anda TIDAK MEMBUTUHKAN lebih banyak CPU. Untuk penyimpanan, IOPS, throughput, dan ukuran semuanya terikat bersama. Jika Anda ingin lebih banyak IOPS, Anda memerlukan disk yang lebih besar. Jika Anda membutuhkan lebih banyak ruang, Anda juga mendapatkan lebih banyak IOPS. Tentu saja Anda dapat melompat di antara kelas penyimpanan untuk menghindari hal itu sampai batas tertentu, tetapi tetap berlaku bahwa jika Anda membutuhkan lebih banyak IOPS, Anda juga mendapatkan lebih banyak ruang pada salah satu dari jenis penyimpanan yang berbeda. Ukuran instance mesin virtual Anda juga penting. Terlepas dari konfigurasi penyimpanan apa yang akhirnya Anda gunakan, throughput keseluruhan akan dibatasi pada ukuran instance apa pun yang memungkinkan. Jadi sekali lagi, Anda mungkin perlu membayar lebih banyak RAM dan CPU daripada yang Anda butuhkan, hanya untuk mencapai kinerja penyimpanan yang Anda inginkan. Pastikan Anda memahami apa ukuran instance Anda dapat mendukung dalam hal throughput IOPS dan MBps maks. Banyak kali ukuran instance akan berubah menjadi hambatan dalam masalah kinerja penyimpanan yang dirasakan di Azure.

Gunakan Raid 0

RAID 0 secara tradisional rel ketiga dari opsi konfigurasi penyimpanan. Meskipun memberikan kombinasi terbaik dari kinerja dan pemanfaatan penyimpanan dari setiap opsi RAID, ia melakukannya dengan risiko kegagalan besar. Seluruh set strip gagal jika hanya satu disk dalam set strip RAID 0 gagal. Dengan demikian, secara tradisional RAID 0 hanya digunakan dalam skenario di mana kehilangan data dapat diterima dan kinerja tinggi diinginkan. Namun, dalam perangkat lunak Azure, RAID 0 diinginkan dan bahkan direkomendasikan dalam banyak situasi. Bagaimana kita bisa lolos dengan RAID 0 di Azure? Jawabannya mudah. Setiap disk yang Anda tampilkan di mesin virtual Azure sudah memiliki tiga redundansi di backend. Berarti Anda harus mengalami beberapa kegagalan sebelum Anda kehilangan set strip Anda. Dengan menggunakan RAID 0, Anda dapat menggabungkan beberapa disk. Kinerja keseluruhan set strip gabungan akan meningkat sebesar 100% untuk setiap disk tambahan yang Anda tambahkan ke set strip. Jadi misalnya, Anda memiliki persyaratan 10.000 IOPS, Anda mungkin berpikir bahwa Anda memerlukan UltraSSD karena Premium Storage mencapai 7,500 IOPS dengan P50. Namun, dengan meletakkan dua P50 dalam RAID 0, Anda sekarang memiliki potensi untuk mencapai hingga 15.000 IOPS. Itu dengan asumsi Anda menjalankan Standard_F16s_v2 atau ukuran instance yang sama besar yang mendukung banyak IOPS. Di Windows 2012 dan yang lebih baru, RAID 0 dicapai dengan menciptakan Ruang Penyimpanan Sederhana. Di Windows Server 2008 R2, Anda dapat menggunakan Disk Dinamis untuk membuat Volume Bergaris RAID 0. Hanya kata-kata peringatan. Jika Anda akan menggunakan Ruang Penyimpanan lokal dan juga mengkonfigurasi Grup Ketersediaan atau Mesin Virtual Cluster SANless dengan DataKeeper, yang terbaik adalah mengkonfigurasi penyimpanan Anda SEBELUM Anda membuat sebuah cluster. Hanya pengingat. Anda hanya memiliki sekitar dua bulan lagi untuk memindahkan instance SQL Server 2008 R2 Anda ke Azure. Lihat posting saya tentang cara menggunakan SQL Server 2008 R2 FCI di Azure untuk memastikan ketersediaan tinggi.

Jangan repot-repot memisahkan Log dan file data

Secara tradisional log dan file data akan berada di disk fisik yang berbeda. File log cenderung memiliki banyak aktivitas tulis dan file data cenderung memiliki lebih banyak aktivitas membaca. Oleh karena itu terkadang penyimpanan akan dioptimalkan berdasarkan karakteristik tersebut. Itu juga diinginkan untuk menyimpan log dan file data pada disk yang berbeda untuk tujuan pemulihan. Jika Anda harus kehilangan satu atau yang lain, dengan strategi cadangan yang tepat, Anda dapat memulihkan database Anda tanpa kehilangan data. Dengan penyimpanan berbasis cloud, kemungkinan kehilangan hanya satu volume sangat rendah. Sekarang Anda berpikir tentang pertimbangan penyimpanan. Jika kebetulan Anda kehilangan penyimpanan, kemungkinan seluruh cluster penyimpanan Anda, bersama dengan tiga cadangan, pergi untuk makan siang. Jadi, meskipun mungkin merasa benar untuk meletakkan log di E: log dan data dalam F: data, Anda benar-benar merugikan diri sendiri. Misalnya, Anda menyediakan P20 untuk log dan P20 untuk data. Setiap volume akan berukuran 512 GiB dan ditutup pada 2.300 IOPS. Bayangkan saja, Anda mungkin tidak perlu semua ukuran itu untuk file log. Tapi itu mungkin tidak memberi Anda banyak ruang untuk tumbuh untuk file data Anda. Pada akhirnya akan membutuhkan pindah ke P30 lebih mahal hanya untuk ruang ekstra. Tidakkah akan jauh lebih baik untuk memisahkan kedua volume itu menjadi volume 1 TB yang bagus yang mendukung 4.600 IOPS? Dengan melakukan itu, baik file log dan data dapat memanfaatkan peningkatan IOPS. Dan, Anda juga baru saja mengoptimalkan pemanfaatan penyimpanan Anda dan mengurangi biaya penyimpanan cloud Anda dengan menunda perpindahan ke disk P30 untuk file data Anda. Hal yang sama juga berlaku pada file dan filegroup. Benar-benar berpikir keras tentang apa yang Anda lakukan. Apakah itu masih masuk akal setelah Anda pindah ke cloud.  Apa yang masuk akal mungkin berlawanan dengan apa yang telah Anda lakukan di masa lalu. Jika ragu, ikuti aturan KISS, Keep It Simple Stupid! Keindahan cloud adalah Anda selalu dapat menambahkan lebih banyak penyimpanan, menambah ukuran instance, atau melakukan apa pun untuk mengoptimalkan kinerja vs. biaya.

Apa yang Harus Dilakukan Tentang TempDB

Gunakan SSD lokal, alias, drive D:. Drive D akan menjadi lokasi terbaik untuk tempdb Anda. Karena ini adalah drive lokal, data dianggap "sementara". Berarti bisa hilang jika server dipindahkan, reboot, dll. Tidak apa-apa. Tempdb diciptakan kembali setiap kali SQL dimulai. SSD lokal akan menjadi cepat dan memiliki latensi rendah. Tetapi karena ini bersifat lokal, baca dan tulis tidak berkontribusi pada batas IOPS penyimpanan keseluruhan dari ukuran instance. Jadi secara efektif, IOPS GRATIS! Kenapa tidak mengambil keuntungan? Jika Anda sedang membangun SANless SQL Server FCI dengan SIOS DataKeeper, pastikan untuk membuat sumber daya volume yang tidak dicerminkan dari drive D. Dengan cara ini Anda tidak perlu meniru TempDB.

Poin Gunung Menjadi Usang

Mount Points biasanya digunakan dalam konfigurasi SQL Server FCI ketika beberapa contoh SQL Server diinstal pada Windows Cluster yang sama. Ini mengurangi biaya keseluruhan lisensi SQL Server. Ini dapat membantu menghemat biaya dengan mendorong pemanfaatan server yang lebih tinggi. Seperti yang kita bahas di masa lalu, biasanya mungkin ada lima atau lebih drive yang terkait dengan setiap instance SQL Server. Jika masing-masing drive tersebut harus menggunakan huruf drive, Anda akan kehabisan huruf hanya dalam tiga hingga empat contoh. Jadi, alih-alih memberikan setiap drive huruf, mount point digunakan sehingga setiap instance hanya bisa dilayani oleh huruf drive tunggal, root drive. Drive root memiliki titik pemasangan yang memetakan untuk memisahkan disk fisik yang tidak memiliki huruf drive. Namun, seperti yang kita diskusikan di atas, konsep menggunakan sekelompok disk individu benar-benar tidak masuk akal di cloud. Karenanya poin mount menjadi usang di awan. Sebagai gantinya, buatlah RAID 0 stripe seperti yang dijelaskan. Setiap contoh berkerumun SQL Server hanya akan memiliki volume sendiri yang dioptimalkan untuk ruang, kinerja, dan biaya. Ini menyelesaikan masalah kehabisan huruf drive. Selain itu, memberi Anda pemanfaatan dan kinerja penyimpanan yang jauh lebih baik, sekaligus juga mengurangi biaya penyimpanan cloud Anda.

Kesimpulan

Posting ini dimaksudkan sebagai titik awal, bukan panduan yang pasti. Poin utama dari posting ini adalah membuat Anda berpikir secara berbeda tentang pertimbangan cloud dan penyimpanan terkait dengan menjalankan SQL Server di Azure. Jangan hanya mengambil apa yang Anda lakukan di tempat dan membuatnya kembali di cloud. Itu hampir selalu menghasilkan kinerja yang kurang optimal dan tagihan penyimpanan yang jauh lebih besar dari yang diperlukan. Diproduksi ulang dengan izin dari Clusteringformeremortals.com

Mengkonfigurasi contoh SQL Server 2008 R2 Failover Cluster pada Windows Server 2008 R2 di Azure

by Leave a Comment

Langkah-demi-Langkah: Cara Mengkonfigurasi Instance Failover Cluster SQL Server 2008 R2 Pada Windows Server 2008 R2 Di Azure

Intro

Pada 9 Juli 2019, dukungan untuk SQL Server 2008 dan 2008 R2 akan berakhir. Itu berarti akhir dari pembaruan keamanan reguler. Namun, jika Anda memindahkan instance SQL Server ke Azure, Microsoft akan memberi Anda Pembaruan Keamanan Diperpanjang tiga tahun tanpa biaya tambahan. Jika saat ini Anda menjalankan SQL Server 2008/2008 R2 dan Anda tidak dapat memperbarui ke versi SQL Server yang lebih lama sebelum batas waktu 9 Juli, Anda akan ingin mengambil keuntungan dari penawaran ini daripada menjalankan risiko menghadapi kerentanan keamanan di masa depan. . Contoh SQL Server yang tidak ditambal dapat menyebabkan kehilangan data, downtime atau pelanggaran data yang menghancurkan.

Salah satu tantangan yang akan Anda hadapi ketika menjalankan SQL Server 2008/2008 R2 di Azure adalah memastikan ketersediaan tinggi. Di tempat Anda mungkin menjalankan contoh SQL Server Failover Cluster (FCI) untuk ketersediaan tinggi, atau mungkin Anda menjalankan SQL Server di mesin virtual dan mengandalkan VMware HA atau cluster Hyper-V untuk ketersediaan. Saat pindah ke Azure, tidak ada opsi itu yang tersedia. Downtime di Azure adalah kemungkinan yang sangat nyata sehingga Anda harus mengambil langkah-langkah untuk mengurangi.

Untuk mengurangi kemungkinan downtime dan memenuhi syarat untuk Azure 99,95% atau SLA 99,99%, Anda harus memanfaatkan SIOS DataKeeper. DataKeeper mengatasi kurangnya penyimpanan bersama Azure dan memungkinkan Anda untuk membangun SQL Server FCI di Azure yang memanfaatkan penyimpanan terlampir secara lokal pada setiap instance. SIOS DataKeeper tidak hanya mendukung SQL Server 2008 R2 dan Windows Server 2008 R2 seperti yang didokumentasikan dalam panduan ini, ia mendukung semua versi Windows Server, dari 2008 R2 hingga Windows Server 2019 dan versi SQL Server apa pun dari dari SQL Server 2008 hingga SQL Server 2019 .

Panduan ini akan berjalan melalui proses membuat dua simpul SQL Server 2008 R2 Failover Cluster Instance (FCI) di Azure, berjalan pada Windows Server 2008 R2. Meskipun SIOS DataKeeper juga mendukung cluster yang menjangkau Zona Ketersediaan atau Wilayah, panduan ini mengasumsikan setiap node berada di Wilayah Azure yang sama, tetapi Domain Fault yang berbeda. SIOS DataKeeper akan digunakan sebagai pengganti penyimpanan bersama yang biasanya diperlukan untuk membuat SQL Server 2008 R2 FCI.

Buat contoh SQL Server pertama di Azure

Panduan ini akan memanfaatkan SQL Server 2008R2SP3 pada gambar Windows Server 2008R2 yang diterbitkan di Azure Marketplace.

Ketika Anda memberikan instance pertama Anda harus membuat Set Ketersediaan baru. Selama proses ini pastikan untuk meningkatkan jumlah Domain Kesalahan ke 3. Ini memungkinkan dua node cluster dan saksi file berbagi masing-masing untuk berada di Domain Kesalahan mereka sendiri.

Tambahkan disk tambahan untuk setiap instance. Direkomendasikan Premium atau Ultra SSD. Nonaktifkan caching pada disk yang digunakan untuk file log SQL. Aktifkan caching hanya-baca pada disk yang digunakan untuk file data SQL. Lihat pedoman Kinerja untuk SQL Server di Mesin Virtual Azure untuk informasi tambahan tentang praktik terbaik penyimpanan.

Jika Anda belum memiliki jaringan virtual yang dikonfigurasi, izinkan panduan pembuatan untuk membuat yang baru untuk Anda.

Setelah instance dibuat, masuk ke konfigurasi IP dan buat alamat IP Privat statis. Ini diperlukan untuk SIOS DataKeeper dan merupakan praktik terbaik untuk instance berkerumun.

Pastikan jaringan virtual Anda dikonfigurasi untuk mengatur server DNS menjadi pengontrol Windows AD lokal. Ini untuk memastikan Anda dapat bergabung dengan domain pada langkah selanjutnya.

Buat Instance SQL Server Akhir Di Azure

Ikuti langkah-langkah yang sama seperti di atas. Kecuali pastikan untuk menempatkan instance ini di jaringan virtual yang sama dan Set Ketersediaan yang Anda buat dengan instance 1.

Buat File Berbagi Saksi (FSW) Instance

Agar Windows Server Failover Cluster (WSFC) untuk bekerja secara optimal Anda diminta untuk membuat contoh Windows Server lain dan menempatkannya di Ketersediaan yang sama seperti contoh SQL Server. Dengan menempatkannya di Set Ketersediaan yang sama, Anda memastikan bahwa setiap node cluster dan FSW berada di Domain Kesalahan yang berbeda. Dengan demikian memastikan cluster Anda tetap on line seandainya seluruh Fault Domain keluar jalur. Contoh ini tidak memerlukan SQL Server. Ini bisa menjadi Windows Server sederhana karena yang perlu dilakukan hanyalah menjadi tuan rumah berbagi file sederhana.

Contoh ini akan menjadi tuan rumah saksi berbagi file yang diperlukan oleh WSFC. Instance ini tidak perlu memiliki ukuran yang sama, juga tidak memerlukan disk tambahan untuk dilampirkan. Satu-satunya tujuan adalah meng-host berbagi file sederhana. Itu sebenarnya bisa digunakan untuk tujuan lain. Di lingkungan lab saya, FSW saya juga pengontrol domain saya.

Hapus instalasi SQL Server 2008 R2

Masing-masing dari dua contoh SQL Server yang disediakan sudah memiliki SQL Server 2008 R2 yang diinstal pada mereka. Namun, mereka diinstal sebagai contoh SQL Server mandiri, bukan contoh berkerumun. SQL Server harus dihapus dari masing-masing instance ini sebelum kita dapat menginstal instance cluster. Cara termudah untuk melakukannya adalah dengan menjalankan SQL Setup seperti yang ditunjukkan di bawah ini.

Ketika Anda menjalankan setup.exe / Action-RunDiscovery Anda akan melihat semua yang sudah diinstal 

setup.exe / Action-RunDiscovery

Menjalankan setup.exe / Action = Uninstall / FITUR = SQL, AS, RS, IS, Tools / INSTANCENAME = MSSQLSERVER memulai proses penghapusan instalasi

setup.exe / Action = Copot pemasangan / FITUR = SQL, AS, RS, IS, Alat / INSTANCENAME = MSSQLSERVER

Menjalankan setup.exe / Action-RunDiscovery mengkonfirmasi penghapusan instalan selesai

setup.exe / Action-RunDiscovery

Jalankan lagi proses penghapusan instalasi ini pada instance ke-2.

Tambahkan Mesin Virtual ke Domain

Ketiga contoh ini perlu ditambahkan ke Domain Windows.

Tambahkan Fitur Clustering Windows Failover

Fitur Failover Clustering perlu ditambahkan ke dua contoh SQL Server

Tambahkan-WindowsFeature Failover-Clustering

Matikan Windows Firewall

Demi kesederhanaan, matikan Windows Firewall selama instalasi dan konfigurasi SQL Server FCI. Konsultasikan Praktik Terbaik Keamanan Jaringan Azure untuk saran tentang pengamanan sumber daya Azure Anda. Rincian tentang port Windows yang diperlukan dapat ditemukan di sini, port SQL Server di sini dan port SIOS DataKeeper di sini, The Internal Load Balancer yang akan kami konfigurasikan nanti juga memerlukan akses port 59999. Jadi pastikan untuk memperhitungkannya dalam konfigurasi keamanan Anda.

NetSh Advfirewall menonaktifkan semua profil

Instal Pembaruan Kenyamanan Rollup Untuk Windows Server 2008 R2 SP1

Ada pembaruan kritis (kb2854082) yang diperlukan untuk mengkonfigurasi contoh Windows Server 2008 R2 di Azure. Pembaruan itu dan banyak lagi yang termasuk dalam Pembaruan Kenyamanan Rollup untuk Windows Server 2008 R2 SP1. Instal pembaruan ini di masing-masing dari dua contoh SQL Server.

Format Penyimpanan

Disk tambahan yang dilampirkan ketika dua contoh SQL Server disediakan harus diformat. Lakukan hal berikut untuk setiap volume pada setiap instance.

Praktik terbaik Microsoft mengatakan berikut ini …

"Ukuran unit alokasi NTFS: Saat memformat disk data, disarankan agar Anda menggunakan ukuran unit alokasi 64-KB untuk data dan file log serta TempDB."

Jalankan Validasi Cluster

Jalankan validasi kluster untuk memastikan semuanya siap untuk dikelompokkan.

Laporan Anda akan berisi PERINGATAN tentang Penyimpanan dan Jaringan. Anda dapat mengabaikan peringatan tersebut karena kami tahu tidak ada disk bersama dan hanya ada satu koneksi jaringan antara server. Anda juga dapat menerima peringatan tentang pesanan pengikatan jaringan yang juga dapat diabaikan. Jika Anda menemukan KESALAHAN, Anda harus mengatasinya sebelum melanjutkan.

Buat Cluster

Praktik terbaik untuk membuat cluster di Azure adalah dengan menggunakan Powershell seperti yang ditunjukkan di bawah ini. Powershell memungkinkan kita untuk menentukan Alamat IP Statis, sedangkan metode GUI tidak. Sayangnya, implementasi DHCP Azure tidak berfungsi dengan baik dengan Windows Server Failover Clustering. Jika Anda menggunakan metode GUI Anda akan berakhir dengan alamat IP duplikat sebagai Alamat IP Cluster. Ini bukan akhir dunia, tetapi Anda harus memperbaikinya seperti yang saya tunjukkan.

Seperti yang saya katakan, metode Powershell umumnya bekerja paling baik. Namun, untuk beberapa alasan, tampaknya gagal pada Windows Server 2008 R2 seperti yang ditunjukkan di bawah ini.

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

Anda dapat mencoba metode itu dan jika itu berhasil untuk Anda – hebat! Saya perlu kembali dan menyelidiki ini sedikit lebih untuk melihat apakah itu kebetulan. Opsi lain yang perlu saya jelajahi jika Powershell tidak berfungsi adalah Cluster.exe. Menjalankan cluster / create /? memberikan sintaks yang tepat untuk digunakan untuk membuat cluster dengan perintah cluster.exe yang sudah tidak digunakan lagi.

Namun, jika Powershell atau Cluster.exe gagal Anda, langkah-langkah di bawah ini mengilustrasikan cara membuat cluster melalui UI Server Windows Failover Clustering, termasuk memperbaiki alamat IP duplikat yang akan ditugaskan ke cluster.

Ingat, nama yang Anda tentukan di sini hanyalah Cluster Name Object (CNO). Ini bukan nama yang akan digunakan klien SQL Anda untuk terhubung ke cluster; kita akan mendefinisikan itu selama pengaturan kluster SQL Server di langkah selanjutnya. 

Pada titik ini, cluster dibuat, tetapi Anda mungkin tidak dapat terhubung dengan itu dengan Windows Server Failover Clustering UI karena masalah alamat IP duplikat.

Perbaiki Alamat IP Gandakan

Seperti yang saya sebutkan sebelumnya, jika Anda membuat cluster menggunakan GUI, Anda tidak diberi kesempatan untuk memilih alamat IP untuk cluster. Karena instance Anda dikonfigurasikan untuk menggunakan DHCP (diperlukan di Azure), GUI ingin secara otomatis memberikan Anda alamat IP menggunakan DHCP. Sayangnya, implementasi DHCP Azure tidak berfungsi seperti yang diharapkan dan cluster akan menetapkan alamat yang sama yang sudah digunakan oleh salah satu node. Meskipun cluster akan membuat dengan benar, Anda akan kesulitan menghubungkan ke cluster sampai Anda memperbaiki masalah ini.

Untuk memperbaiki masalah ini, dari salah satu node jalankan perintah berikut untuk memastikan layanan Cluster dimulai pada node itu.

Mulai bersih clussvc / fq

Pada simpul yang sama Anda sekarang harus dapat terhubung ke UI Clustering Windows Server Failover, di mana Anda akan melihat Alamat IP telah gagal untuk online.

Buka properti alamat IP Cluster dan ubah dari DHCP ke Statis, dan tetapkan alamat IP yang tidak digunakan.

Bawa sumber Nama online

Tambahkan File Bagikan Saksi

Selanjutnya kita perlu menambahkan File Share Witness. Di server ke-3 kami menyediakan sebagai FSW, buat folder dan bagikan seperti yang ditunjukkan di bawah ini. Anda harus memberikan izin baca / tulis Cluster Name Object (CNO) di tingkat Share dan Security seperti yang ditunjukkan di bawah ini.

Setelah share dibuat, jalankan wizard Configure Cluster Quorum di salah satu node cluster dan ikuti langkah-langkah yang diilustrasikan di bawah ini.

Buat Akun Layanan Untuk DataKeeper

Kami hampir siap untuk menginstal DataKeeper. Namun, sebelum kita melakukan itu, Anda perlu membuat akun Domain dan menambahkannya ke grup Administrator Lokal pada setiap contoh cluster SQL Server. Kami akan menentukan akun ini ketika kami menginstal DataKeeper.

Instal DataKeeper

Instal DataKeeper di masing-masing dari dua node cluster SQL Server seperti yang ditunjukkan di bawah ini.

Di sinilah kami akan menentukan akun Domain yang kami tambahkan ke masing-masing grup Administrator Domain lokal.

Konfigurasikan DataKeeper

Setelah DataKeeper diinstal pada masing-masing dari dua node cluster, Anda siap untuk mengkonfigurasi DataKeeper.

CATATAN – Kesalahan paling umum yang dihadapi dalam langkah-langkah berikut adalah terkait keamanan, paling sering oleh kelompok Azure Security yang sudah ada memblokir port yang diperlukan. Silakan lihat dokumentasi SIOS untuk memastikan server dapat berkomunikasi melalui port yang diperlukan.

Pertama, Anda harus terhubung ke masing-masing dari dua node.

Jika semuanya sudah dikonfigurasikan dengan benar, Anda harus melihat yang berikut ini di laporan Tinjauan Server.

Selanjutnya, buat Pekerjaan Baru dan ikuti langkah-langkah yang diilustrasikan di bawah ini

Pilih Ya di sini untuk mendaftarkan sumber daya Volume DataKeeper di Penyimpanan yang Tersedia

Selesaikan langkah-langkah di atas untuk masing-masing volume. Setelah selesai, Anda akan melihat yang berikut di UI Clustering Windows Server Failover.

Anda sekarang siap untuk menginstal SQL Server ke dalam cluster.

CATATAN – Pada titik ini volume yang direplikasi hanya dapat diakses pada node yang saat ini menampung Penyimpanan yang Tersedia. Itu yang diharapkan, jadi jangan khawatir!

Instal SQL Server Di Node Pertama

Pada node pertama, jalankan pengaturan SQL Server.

Pilih Instalasi SQL Server Failover Cluster baru dan ikuti langkah-langkah seperti yang diilustrasikan.

Pilih hanya opsi yang Anda butuhkan. 

Harap dicatat, dokumen ini mengasumsikan Anda menggunakan contoh default dari SQL Server. Jika Anda menggunakan Instance Bernama, Anda perlu memastikan Anda mengunci port yang didengarkannya, dan menggunakan port itu nanti ketika Anda mengkonfigurasi load balancer. Anda juga perlu membuat aturan penyeimbang beban untuk Layanan Peramban SQL Server (UDP 1434) agar dapat terhubung ke Mesin Virtual Bernama. Tidak satu pun dari kedua persyaratan tersebut tercakup dalam panduan ini. Tetapi jika Anda memerlukan Instance Bernama, itu akan berfungsi jika Anda melakukan dua langkah tambahan.

Di sini Anda perlu menentukan alamat IP yang tidak digunakan

Buka tab Direktori Data dan pindahkan data dan file log. Pada akhir panduan ini, kita berbicara tentang memindahkan tempdb ke Volume DataKeeper yang tidak dicerminkan untuk kinerja yang optimal. Untuk saat ini, simpan saja di salah satu disk yang dikelompokkan.

Instal SQL Pada Node Kedua

Jalankan pengaturan SQL Server lagi pada node kedua. Kemudian, pilih Tambahkan simpul ke Cluster Failover SQL Server.

Selamat, Anda hampir selesai! Namun, karena kurangnya dukungan Azure untuk ARP serampangan, kami akan perlu mengonfigurasi Internal Load Balancer (ILB) untuk membantu pengalihan klien seperti yang ditunjukkan pada langkah-langkah berikut.

Perbarui Alamat IP SQL Cluster

Agar ILB berfungsi dengan benar, Anda harus menjalankan menjalankan perintah berikut dari salah satu node cluster. Itu SQL Cluster IP memungkinkan alamat IP SQL Cluster untuk menanggapi probe kesehatan ILB sementara juga mengatur subnet mask ke 255.255.255.255 untuk menghindari konflik alamat IP dengan probe kesehatan.

cluster res <IPResourceName> / priv enabledhcp = 0 address = <ILBIP> probeport = 59999 subnetmask = 255.255.255.255

CATATAN – Saya tidak tahu apakah itu kebetulan. Kadang-kadang saya telah menjalankan perintah ini dan sepertinya berfungsi, tetapi tidak menyelesaikan pekerjaan dan saya harus memulai lagi. Cara saya tahu apakah itu bekerja adalah dengan melihat Subnet Mask dari SQL Server IP Resource. Jika bukan 255.255.255.255 maka Anda tahu itu tidak berhasil.  Ini mungkin hanya masalah penyegaran GUI. Cobalah memulai kembali GUI kluster untuk memverifikasi subnet mask telah diperbarui.

Setelah berhasil, ambil sumber daya secara offline dan bawa kembali online agar perubahan diterapkan.

Buat Load Balancer

Langkah terakhir adalah membuat penyeimbang beban. Dalam hal ini kami mengasumsikan Anda menjalankan Instance Default dari SQL Server, mendengarkan pada port 1433.

Alamat IP Privat yang Anda tetapkan saat Anda Membuat load balancer akan menjadi alamat yang sama persis dengan yang Anda gunakan SQL Server FCI.

Tambahkan hanya dua contoh SQL Server ke kolam backend. JANGAN menambahkan FSW ke kolam backend.

Dalam aturan penyeimbangan beban ini, Anda harus mengaktifkan IP Terapung.

Uji Cluster

Tes paling sederhana adalah membuka SQL Server Management Studio pada node pasif dan terhubung ke cluster. Selamat! Anda melakukan semuanya dengan benar saat terhubung! Jika Anda tidak dapat terhubung, jangan takut. Saya menulis artikel blog untuk membantu memecahkan masalah ini. Mengelola cluster sama persis dengan mengelola cluster penyimpanan bersama tradisional. Semuanya dikendalikan melalui Failover Cluster Manager.

Opsional – Pindahkan TempDB

Untuk kinerja optimal, disarankan untuk memindahkan tempdb ke SSD lokal yang tidak direplikasi. Tapi, SQL Server 2008 R2 membutuhkan tempdb berada di disk berkerumun. SIOS memiliki solusi yang disebut Sumber Daya Volume Tidak Tercermin yang mengatasi masalah ini. Dianjurkan untuk membuat sumber daya volume yang tidak dicerminkan dari drive SSD lokal dan memindahkan tempdb ke sana. Perhatikan, drive SSD lokal tidak persisten. Anda harus berhati-hati untuk memastikan folder yang menahan tempdb dan izin pada folder itu diciptakan kembali setiap kali server reboot.

Setelah Anda membuat Sumber Daya Volume Tanpa Cermin dari SSD lokal, ikuti langkah-langkah dalam artikel ini untuk memindahkan tempdb. Skrip startup yang dijelaskan dalam artikel itu harus ditambahkan ke setiap node cluster.

Diproduksi ulang dengan izin dari Clusteringformeremortals.com

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

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

  1. 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.
  2. Instal contoh bernama SQL Server pada node pertama, tentukan Volume DataKeeper yang baru saja kita buat sebagai lokasi penyimpanan.
  3. “Tambahkan simpul” ke kluster pada simpul kedua.
  4. 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 ditujukan 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 instance 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