Tidak memperhatikan SAN di balik tirai itu

Sekali waktu, saya membangun server SQL saya sendiri, dan memiliki kendali atas konfigurasi drive, level RAID, dll. Saran tradisional untuk pemisahan data, log, tempdb, backup, (tergantung pada anggaran!) Selalu menjadi bagian yang cukup penting proses desain SQL server.

Sekarang dengan SAN tingkat perusahaan, saya hanya meminta jumlah ruang drive tertentu untuk server SQL baru, dibagi menjadi drive logis untuk data, cadangan, dan fileshares. Tentu saja membuat pekerjaan saya lebih mudah, tetapi ada bagian dari diri saya yang tidak merasa benar-benar nyaman sehingga saya tidak bisa mengintip "balik tirai" untuk melihat apa yang sebenarnya terjadi di sana.

Pemahaman saya adalah bahwa tim SAN tidak mengkonfigurasi "tipe" drive yang berbeda secara berbeda (mengoptimalkan drive data untuk akses acak vs drive log untuk streaming menulis). Beberapa di antaranya mungkin tergantung pada produk SAN itu sendiri (kami memiliki HP XP12000 dan HP XP24000), tetapi saya telah diyakinkan bahwa perangkat lunak HP melakukan segala macam konfigurasi kinerja dinamis (mengawasi hotspot IO dan mengkonfigurasi ulang dengan cepat untuk mengoptimalkan LUN tersebut), sehingga tim aplikasi dan DBA tidak perlu khawatir tentang hal-hal itu. Sesuatu tentang "menyebarkan beban semua server melalui sejumlah besar spindle" atau sesuatu seperti itu.

Pertanyaan / diskusi saya:

1. Tanpa membuat musuh pada tim SAN, bagaimana saya bisa meyakinkan diri sendiri dan pengembang aplikasi bahwa server SQL kami tidak menderita penyimpanan yang tidak terkonfigurasi dengan baik? Cukup gunakan statistik perfmon? Tolok ukur lain seperti sqlio?

2. Jika saya memuat tes pada drive SAN ini, apakah itu benar-benar memberi saya ukuran yang dapat diandalkan dan berulang tentang apa yang akan saya lihat ketika kita ditayangkan? (dengan asumsi bahwa perangkat lunak SAN mungkin "secara dinamis mengkonfigurasi" secara berbeda pada titik waktu yang berbeda.)

3. Apakah IO berat di satu bagian SAN (katakanlah server Exchange) berdampak pada server SQL saya? (dengan asumsi mereka tidak memberikan disk khusus untuk masing-masing server, yang saya telah diberitahu mereka tidak)

4. Apakah meminta memisahkan drive logis untuk fungsi yang berbeda drive logis (data vs log vs tempdb) membantu di sini? Apakah SAN akan melihat aktivitas IO berbeda pada ini dan secara optimal mengkonfigurasi mereka berbeda?

5. Kita sedang dalam krisis ruang saat ini. Tim aplikasi diberitahu untuk memangkas arsip data, dll. Apakah masalah ruang akan menyebabkan tim SAN membuat keputusan berbeda tentang cara mereka mengonfigurasi penyimpanan internal (tingkat RAID, dll.) Yang dapat memengaruhi kinerja server saya?

Terima kasih atas pemikiran Anda (topik serupa yang dibahas secara singkat dalam pertanyaan SF ini )

Tanpa membuat musuh pada tim SAN, bagaimana saya bisa meyakinkan diri sendiri dan pengembang aplikasi bahwa server SQL kami tidak menderita penyimpanan yang tidak terkonfigurasi dengan baik? Cukup gunakan statistik perfmon? Tolok ukur lain seperti sqlio?

Singkatnya, mungkin tidak ada cara untuk benar-benar yakin. Apa yang akan saya katakan (saya adalah admin SAN), adalah bahwa jika aplikasi Anda berjalan sesuai harapan Anda, jangan khawatir tentang hal itu. Jika Anda mulai melihat masalah kinerja yang Anda yakini terkait dengan kinerja SAN / Disk IO, maka mungkin bijaksana untuk menanyakannya. Saya tidak menggunakan banyak penyimpanan HP seperti yang Anda lakukan, tetapi di dunia IBM / NetApp saya dapat mengatakan dari pengalaman bahwa tidak ada banyak opsi yang akan memungkinkan Anda untuk mengkonfigurasinya dengan "buruk". Sebagian besar penyimpanan perusahaan akhir-akhir ini membutuhkan banyak dugaan untuk membangun array serangan, dan tidak benar-benar membiarkan Anda melakukan kesalahan. Kecuali jika mereka mencampur kecepatan dan kapasitas drive dalam grup raid yang sama, Anda dapat yakin dalam banyak kasus bahwa disk Anda berkinerja baik.

Jika saya memuat tes pada drive SAN ini, apakah itu benar-benar memberi saya ukuran yang dapat diandalkan dan berulang tentang apa yang akan saya lihat ketika kita ditayangkan? (dengan asumsi bahwa perangkat lunak SAN mungkin "secara dinamis mengkonfigurasi" secara berbeda pada titik waktu yang berbeda.)

Pengujian beban harus banyak andal. Hanya perlu diingat bahwa ketika Anda memuat pengujian satu kotak, yang berada di SAN / Disk Array bersama bahwa kinerjanya dapat (dan akan) dipengaruhi oleh sistem lain menggunakan penyimpanan yang sama.

Apakah IO berat di satu bagian SAN (katakanlah server Exchange) berdampak pada server SQL saya? (dengan asumsi mereka tidak memberikan disk khusus untuk masing-masing server, yang saya telah diberitahu mereka tidak)

Bisa. Ini tidak semua tentang disk, atau disk mana, server aktif. Semua data disajikan melalui pengontrol disk, dan kemudian SAN switch. Kinerja yang akan Anda lihat sangat tergantung pada bagaimana pengontrol disk terhubung ke rak disk yang sesuai, dan SAN yang sesuai. Jika seluruh array terhubung ke backbone SAN pada satu untai tunggal serat 4gbps, maka jelas kinerjanya akan terpengaruh. Jika array terhubung di dua SAN yang redundan yang memuat seimbang, menggunakan tautan trunk, maka mustahil untuk bertukar sendiri untuk menyedot terlalu banyak bandwidth. Hal lain yang perlu dipertimbangkan adalah berapa banyak IO / detik array mampu. Selama array dan SAN terhubung ke diskalakan dengan benar,

Apakah meminta memisahkan drive logis untuk fungsi yang berbeda drive logis (data vs log vs tempdb) membantu di sini? Apakah SAN akan melihat aktivitas IO berbeda pada ini dan secara optimal mengkonfigurasi mereka berbeda?

Itu mungkin masalah preferensi, dan juga sangat tergantung pada bagaimana admin penyimpanan Anda mengonfigurasinya. Mereka bisa memberi Anda tiga LUN dalam array atau volume yang sama, dalam hal ini semuanya tetap sama. Jika mereka memberi Anda masing-masing LUN pada array yang berbeda, dalam volume yang berbeda (disk yang berbeda secara fisik), maka mungkin Anda layak untuk memisahkannya.

Kita sedang dalam krisis ruang saat ini. Tim aplikasi diberitahu untuk memangkas arsip data, dll. Apakah masalah ruang akan menyebabkan tim SAN membuat keputusan berbeda tentang cara mereka mengonfigurasi penyimpanan internal (tingkat RAID, dll.) Yang dapat memengaruhi kinerja server saya?

Saya tidak membayangkan admin penyimpanan Anda akan mengubah tingkat serangan untuk membebaskan ruang. Jika dia mau, maka dia mungkin harus dipecat. Kekhawatiran ruang dapat menyebabkan berbagai hal dikonfigurasikan secara berbeda, tetapi biasanya tidak dengan cara yang berdampak pada kinerja. Mereka mungkin menjadi sedikit lebih ketat tentang berapa banyak ruang yang mereka berikan kepada Anda. Mereka mungkin mengaktifkan fitur seperti de-duplikasi data (jika array mendukungnya) yang dapat menghambat kinerja array saat proses berjalan, tetapi tidak sepanjang waktu.

Tim SAN harus memiliki alat yang dapat membantu Anda mengungkapkan jika aplikasi Anda hotspot. Jelas, Anda juga harus memantau dan mengukur pada akhirnya.

Sebagian besar pengalaman saya adalah dengan EMC jadi YMMV. Tetapi yang berikut ini harus berlaku untuk sebagian besar peralatan SAN.

Hanya ada begitu banyak port yang masuk ke array. Terkadang ada sakelar SAN di antara Anda bisa menentukan zona. Hanya karena array pada dasarnya adalah kumpulan penyimpanan yang besar, tidak berarti Anda tidak perlu khawatir tentang kinerja IO.

Jadi, jika Anda merasa memiliki masalah IO, Anda harus mempersempit di mana hambatannya. Jika berada di suatu tempat antara HBA dan array, Anda kemudian dapat mengetahui apakah HBA maksimal atau jika port SAN pada sisi switch / array kelebihan permintaan. Selain itu, Anda harus memiliki tim SAN memantau pola akses untuk aplikasi Anda, baik dari awal yang dingin dan panas.

Jelas, penyimpanan yang mendasarinya membuat perbedaan mengatakan menjalankan RAID5 besar lambat vs RAID10 cepat karena Anda pada suatu saat harus menekan disk terlepas dari berbagai tingkat cache.

HTH. Anda dapat mem-ping saya secara offline jika Anda memiliki masalah khusus karena ini bisa memakan waktu cukup lama untuk digali.

Tanpa membuat musuh pada tim SAN, bagaimana saya bisa meyakinkan diri sendiri dan pengembang aplikasi bahwa server SQL kami tidak menderita penyimpanan yang tidak terkonfigurasi dengan baik? Cukup gunakan statistik perfmon? Tolok ukur lain seperti sqlio?

Hal pertama yang perlu Anda ketahui sebelum melakukan pembandingan apa pun adalah seberapa besar toleransi yang dibutuhkan oleh beban kerja Anda sendiri. Jadi, perbandingkan barang-barang Anda sendiri sebelum memeriksa sistem yang baru. Dengan begitu jika Anda menemukan Anda mendorong maksimum, katakanlah, 56MB / s selama beban puncak (cadangan?), Mengetahui bahwa array disk yang terhubung dengan SAN 'hanya' mendorong 110MB / s di bawah beban puncak yang disimulasikan, Anda dapat meyakinkan bahwa batasnya tidak akan menjadi saluran I / O.

Saat memeriksa larik disk baru, saya telah melakukan pengujian kinerja semacam ini. Array baru menggunakan drive SATA daripada drive fiber-channel (SCSI), dan saya perlu meyakinkan diri saya bahwa itu akan bekerja di lingkungan kita. Saya sangat ragu. Tetapi setelah karakterisasi, saya menemukan bahwa sistem baru memiliki cukup I / O overhead di bawah puncak untuk mengimbangi puncak yang diukur pada disk yang lebih dapat diandalkan. Itu mengejutkan saya.

Jika saya memuat tes pada drive SAN ini, apakah itu benar-benar memberi saya ukuran yang dapat diandalkan dan berulang tentang apa yang akan saya lihat ketika kita ditayangkan? (dengan asumsi bahwa perangkat lunak SAN mungkin "secara dinamis mengkonfigurasi" secara berbeda pada titik waktu yang berbeda.)

Karena sifat bersama array disk yang dilampirkan SAN, kinerja menjadi variabel sepanjang minggu. Jika Anda sudah tahu kapan beban I / O puncak Anda, lakukan serangkaian tes beban pada saat hari ketika beban I / O puncak Anda. Dengan begitu Anda bisa lebih mengkarakterisasi overhead jenis I / O apa yang tersedia selama periode yang paling Anda minati. Memuat tes selama waktu non-puncak akan memberi Anda perasaan tentang bagaimana hal-hal 'tajam' akan terjadi, tetapi pengujian puncak akan memberi Anda batas sejati memeriksa.

Apakah IO berat di satu bagian SAN (katakanlah server Exchange) berdampak pada server SQL saya? (dengan asumsi mereka tidak memberikan disk khusus untuk masing-masing server, yang saya telah diberitahu mereka tidak)

Jika Exchange LUN berbagi disk dengan SQL LUN ​​Anda, mereka akan melakukannya. Kami menggunakan HP EVA, bukan XPs, tapi saya pikir mereka menggunakan terminologi "grup disk" yang sama. LUN di disk grup-disk yang sama, dan karenanya bersaing untuk I / O pada perangkat fisik tersebut. Semakin banyak disk yang Anda masukkan ke dalam grup disk, semakin banyak ruang gerak array harus menyulap I / O. Array (setidaknya EVA melakukan ini, dan saya menganggap XP lebih mahal melakukan hal yang sama) mendistribusikan blok LUN logis di disk fisik dengan cara yang tidak berurutan. Ini memungkinkannya melakukan apa yang Anda sarankan, yang secara dinamis mendistribusikan grup blok yang sering diakses ke perangkat fisik yang berbeda untuk meningkatkan paralelisme dan mengurangi pertikaian I / O pada tingkat disk.

Pertanyaan yang harus ditanyakan adalah berapa banyak anggaran I / O yang dimiliki oleh grup disk itu, dan apakah aplikasi yang menggunakan LUN tersebut kelebihan permintaan berlangganan untuk I / O. Itu adalah pertanyaan yang harus dilacak oleh admin penyimpanan. Bisa jadi puncak I / O untuk Exchange (mungkin selama cadangan) mungkin tidak bertepatan dengan beban SQL, dan kedua sistem dapat hidup berdampingan dengan bahagia.

Apakah meminta memisahkan drive logis untuk fungsi yang berbeda drive logis (data vs log vs tempdb) membantu di sini? Apakah SAN akan melihat aktivitas IO berbeda pada ini dan secara optimal mengkonfigurasi mereka berbeda?

Untuk array HP, Anda harus memasukkan pola I / O yang berbeda ke dalam grup disk yang berbeda, bukan LUN. Pola I / O basis data tidak boleh hidup berdampingan dengan pola akses yang melayani web, misalnya. LUN yang berbeda tidak secara nyata meningkatkan kinerja Anda kecuali mereka berada di grup disk yang berbeda. Jika mereka berada di grup disk yang sama, satu-satunya keuntungan nyata adalah sistem operasi, di mana ia dapat melakukan penjadwalan I / O di kernel untuk meningkatkan paralelisme ke subsistem disk. Yang mengatakan ...

Array HP, menurut pemahaman saya, sadar akan pola akses yang berbeda pada LUN, tetapi memperhatikan blok logis yang sebenarnya. Menempatkan log pada LUN yang berbeda menempatkan batasan pada blok logis yang akan mendapatkan jenis I / O traffic, dan itu akan memudahkan tugas menyortir blok logis dengan benar pada disk fisik.

Kita sedang dalam krisis ruang saat ini. Tim aplikasi diberitahu untuk memangkas arsip data, dll. Apakah masalah ruang akan menyebabkan tim SAN membuat keputusan berbeda tentang cara mereka mengonfigurasi penyimpanan internal (tingkat RAID, dll.) Yang dapat memengaruhi kinerja server saya?

Pastinya. Jika ruangnya sempit, Anda tidak akan mendapatkan grup disk khusus untuk I / O Anda (kecuali lingkungan penyimpanan Anda cukup besar untuk membenarkan pengabdian 7TB disk fisik untuk penggunaan eksklusif Anda, pada titik yang mungkin terjadi. ). Perdebatan Raid5 / Raid10 sebagian besar tergantung pada kebijakan organisasi, dan bertanya adalah taruhan terbaik Anda.

Saya sarankan membuka dialog dengan Tim SAN Anda dan vendor untuk mengatasi masalah Anda. Salah satu masalah yang akan Anda miliki dengan menjalankan tolok ukur Anda sendiri adalah bahwa tes Anda mungkin tidak berpengaruh pada apa yang terjadi dalam produksi, terutama pada beban puncak. Kebanyakan SAN memiliki banyak sekali cache yang didukung oleh baterai, yang dalam banyak kasus (terutama ketika Anda menjalankan benchmark sintetis) berarti Anda menulis ke RAM dan mendapatkan kinerja yang baik.

Bergantung pada lingkungan Anda dan solusi yang Anda gunakan, beberapa vendor CE mungkin baru saja terbang dan mengatur SAN ke standar apa pun yang ia inginkan. Itu terjadi lebih dari yang Anda pikirkan. Anda harus mengupas shell "tim SAN yang tahu semua" sampai Anda yakin bahwa solusinya memenuhi persyaratan Anda.

Semoga berhasil.

Saya pernah di sebuah konferensi oracle sekali dengan pembicaraan tentang topik ini - waras SAN untuk database.

Inti dari pembicaraan tersedia dalam file PDF ini atau di situs penulis di sini