SQL Server - Memisahkan file data, log, dan TempDB pada SAN

8

Saya memiliki SQL Server yang terhubung ke SAN. Vendor penyimpanan baru kami merekomendasikan agar semua LUN menjangkau seluruh array disk, yaitu RAID5. Saya biasanya akan meminta 3 LUN terpisah (data, log, dan TempDB) dari administrator SAN, tetapi dengan rekomendasi vendor baru, apakah ada gunanya membuat LUN terpisah? Atau apakah saya akan melihat kinerja yang sama jika semuanya berada dalam satu LUN karena itu akan merentang semua disk?

Artikel bagus di sini, tetapi tidak cukup membahas situasi persis saya: http://www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-share-drives/

sql-server performance storage san Beberapa pria
sumber

Jawaban:

6

Satu hal yang perlu dipertimbangkan adalah bahwa file log adalah menulis sekuensial sedangkan file data tidak berurutan. Itulah salah satu alasan untuk LUN yang terpisah. File log menulis lebih cepat jika mereka berada di LUN mereka sendiri karena spindle tidak harus melompat-lompat, cukup tulis berurutan. Jika Anda menambahkan file data maka spindle harus melewati dan Anda kehilangan beberapa kinerja. Saya berharap saya mendapatkan terminologi yang tepat di sana karena saya tidak terlalu akrab dengan SAN sendiri. Namun ide di balik itu harus.

Rekomendasi vendor yang sering salah ketika datang ke SQL Server. Hanya karena SQL Server memiliki kebutuhan yang berbeda dari kebanyakan aplikasi yang menggunakan SAN.

Kenneth Fisher
sumber
1
Saya pikir apa yang OP katakan adalah bahwa terlepas dari LUN, mereka semua memukul spindle yang sama. Dengan kata lain, tidak ada pemisahan fisik untuk kumpulan disk yang terisolasi.
Thomas Stringer
1
Ahh, saya kira apa yang saya katakan adalah jangan mengaturnya seperti itu :) minta masing-masing LUN pada spindle yang berbeda meskipun vendor menyarankan sebaliknya. Jika itu tidak memungkinkan maka tidak ada alasan kinerja untuk memisahkan mereka pada LUN yang berbeda. Meskipun Anda tidak pernah tahu apa yang akan terjadi di latar belakang dan di beberapa titik di masa depan jika mereka berada di LUN terpisah, mereka mungkin dipindahkan ke spindle yang berbeda.
Kenneth Fisher
4

Banyak tergantung pada SAN, biasanya Anda ingin mengkonfigurasi LUN berbeda dengan caching yang berbeda, kompresi, enkripsi, baca-depan, menulis melalui / kembali kebijakan, prioritas, dll. File data SQL sering menunjukkan perilaku yang berbeda daripada tempdb atau log file. Metode / jaringan akses juga berperan sebagai trunking, multi-pathing, dan teknologi lainnya mungkin berfungsi atau tidak mungkin tergantung pada metode akses Anda (FC, iSCSI, ..) dan infrastruktur. Anda akan ingin dapat memanfaatkan jaringan Anda secara maksimal dengan SQL Server karena latensi dan throughput sangat penting. Saya telah melihat kasus dengan pengaturan jaringan tim, tetapi hanya 1Gbps dapat digunakan karena kendala lain yang tidak disadari klien. Saya setuju dengan Kenneth, mengambil rekomendasi vendor dengan dosis besar garam, mereka sering salah. SQL Server adalah binatang yang berubah-ubah, ada sangat sedikit yang absolut, biasanya hanya lebih banyak pertanyaan. Mengajukan pertanyaan yang tepat (melalui pengujian) adalah kuncinya.

AceCTO
sumber
2

Jangan "mengambil rekomendasi penjual dengan garam dalam jumlah besar", kecuali mereka dari departemen penjualan atau pemasaran. Justru sebaliknya, jika Anda bisa mendapatkan akses ke orang-orang implementasi teknis mereka, berteman.

Kemungkinan ini adalah salah satu peralatan berkembang biak baru yang memvirtualisasi kumpulan penyimpanan dan termasuk kemampuan auto-tier. Salah satu contohnya adalah Compellent . Mereka melakukan segala macam SAN voodoo seperti:

  • Tulis blok data aktif ke penyimpanan Tier 1 dengan tingkat RAID yang dioptimalkan kinerja seperti RAID 10.
  • Secara otomatis memigrasikan blok data yang tidak aktif ke penyimpanan tingkat yang lebih rendah dengan RAID 5 atau 6 dengan perlindungan overhead yang tinggi.

Untuk Compellent, penyimpanan dibagi menjadi 3 tingkatan dengan Tier1 menjadi yang tercepat (SSD atau RAID 10) hingga Lemahnya Tier3 yang terdiri dari 7k SAS disk. Saya belum pernah menggunakan salah satu ini dalam lingkungan produksi tetapi memiliki akses ke salah satunya, yang saya harap dapat menjalankan beberapa pengujian.

Saya mengaku tertarik dan takut dengan fitur auto-tier, yang di atas kertas terdengar indah tetapi dalam produksi mungkin bermasalah. Contoh pertama yang muncul sebagai berpotensi mematikan mekanisme auto-tier adalah backup database. Di sana Anda memiliki target penulisan berulang tinggi yang mungkin menipu mekanisme tiering untuk memindahkan blok ke kumpulan kinerja tinggi, berpotensi mendorong keluar data yang seharusnya ada.

Untuk pertanyaan awal:

... apakah ada gunanya membuat LUN terpisah?

Mungkin tidak, tidak. Pastikan use case jelas untuk vendor tetapi jika itu adalah tipe perangkat Compellent, saya tidak percaya Anda mendapatkan apa pun dari pemisahan LUN Anda.

Mark Storey-Smith
sumber
2

Apakah ada gunanya memisahkan LUN? Hampir selalu. Kalau tidak, Anda berakhir kelebihan antrian LUN di server Windows. Dan mengalami kondisi qfull menyakitkan, terlepas dari OS, virtualisasi, atau platform penyimpanan

sql_handle
sumber