Archives for Mei 2019

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