SAN dengan beberapa drive SSD, atau banyak HDD kuno?

9

Perusahaan saya mencoba mencari tahu jenis SAN apa yang harus dibeli. Ini khusus untuk server basis data yang menjadi dibatasi oleh IO (penyimpanan adalah DAS sekarang, tetapi kami mencapai batas satu server dan kami juga ingin menambahkan pengelompokan).

Kami membutuhkan solusi yang akan menghasilkan sekitar 3000 IOPS jangka panjang (saat ini kami memuncak sekitar 1000 IOPS). Sebagian besar operasi basis data kami adalah kecil baca / tulis. Berdasarkan diskusi dengan para insinyur HP dan yang lainnya secara online, sebuah HP P2000 dengan 24 SAS HD dalam konfigurasi RAID 10 akan menghasilkan kecepatan yang kurang dari hanya untuk ~ $ 20K. Tambahkan pengontrol dan item lainnya untuk membangun SAN menempatkan kami tepat di sekitar anggaran maksimal kami sebesar $ 30 ribu.

Tapi secara online, saya melihat bahwa banyak SAS SSD memberikan kecepatan 80.000 IOPS +. Apakah ini realistis untuk diharapkan? Jika demikian, apakah realistis untuk mendapatkan SAN entry level P2000 atau serupa dan melemparkan beberapa SSD di sana? Basis data kami kecil, hanya beberapa total TB. Jika kita melakukan ini, kita akan memiliki sisa uang untuk membeli SAN kedua untuk mirroring / failover, yang tampaknya bijaksana.

Bip bip
sumber
3
Saya akan menjawab ini segera.
ewwhite
Bisakah Anda menautkan ke model / tipe SAN tertentu yang Anda tertarik gunakan? Ada banyak peringatan yang datang dengan array penyimpanan gaya HP P2000. Bagaimana Anda berencana untuk terhubung? iSCSI? Serat? SAS?
ewwhite
Juga, platform basis data apa ini?
ewwhite
Berikut adalah model yang saya lihat, hanya dengan konfigurasi drive yang berbeda: aventissystems.com/product-p/200385.htm . DBMS adalah SQL Server Standard 2008 R2. Kami benar-benar terbuka untuk hampir semua konfigurasi / vendor selama kami dapat skala "murah" di masa depan, dan selama kami tetap dalam anggaran sederhana kami.
Bip bip
Berapa kapasitas yang Anda butuhkan?
ewwhite

Jawaban:

4

Saya dapat berbicara secara spesifik tentang apa yang ingin Anda capai. Jujur, saya tidak akan mempertimbangkan HP P2000 / MSA2000 entry-level untuk tujuan Anda.

Perangkat ini memiliki banyak keterbatasan dan dari perspektif pengaturan fitur SAN, tidak lebih dari sekotak disk. Tanpa tiering, tidak ada caching cerdas, maksimal 16 disk dalam grup Disk Virtual , kemampuan IOPS rendah, dukungan SSD yang buruk, (terutama pada unit yang Anda pilih).

Anda perlu meningkatkan HP MSA2040 untuk melihat manfaat kinerja atau dukungan resmi dengan SSD. Plus, apakah Anda benar-benar ingin menggunakan iSCSI?

DAS mungkin menjadi pilihan terbaik Anda jika Anda dapat mentolerir penyimpanan lokal. Penyimpanan flash PCIe akan masuk dalam anggaran Anda, tetapi kapasitas harus direncanakan dengan hati-hati.

Bisakah Anda menguraikan spesifikasi server Anda yang sebenarnya? Buat / model, dll.

Jika pengelompokan adalah harus dimiliki, opsi lain adalah melakukan unit HP MSA2040, tetapi gunakan unit SAS sebagai ganti iSCSI. Ini lebih murah daripada model lainnya, memungkinkan Anda untuk menghubungkan 4-8 server, menawarkan latensi rendah dan throughput yang hebat, dan masih dapat mendukung SSD. Bahkan dengan model Fiber atau iSCSI, unit ini akan memberi Anda lebih banyak fleksibilitas daripada yang Anda tautkan.

putih
sumber
Terima kasih! Kami memiliki semua server HP, terutama HP DL380. Satu-satunya alasan kami mempertimbangkan iSCSI adalah sepertinya lebih mudah untuk memperluas melewati 4 server (jika kami ingin mendorong data server lain ke SAN), dan itu sedikit lebih cepat (10Gb vs 6Gb).
Bip bip
Yang mengatakan, saya akan melihat pada MSA2040 ... tidak yakin mengapa itu tidak muncul di radar kami sebelumnya.
Bip bip
Saya dapat melihat kebingungan ... Jika Anda tidak berencana untuk memperluas di luar 4 atau 8 server, SAS bekerja dengan sangat baik. Dan itu bukan 10Gb dibandingkan 6Gb ... itu 10Gb versus 4-jalur 12Gbps SAS (48Gbps ke enklosur) antarmuka.
ewwhite
Saya baru saja melihat bahwa perangkat lunak Remote Snap hanya berfungsi pada iSCSI atau FC ... kami berharap dapat menggunakan remote snap untuk mencerminkan SAN untuk pemulihan bencana pada akhirnya. Atau apakah ada proses lain melalui SAS yang memungkinkan untuk kemampuan yang sama?
Bip bip
@Beepbeep Saya mungkin akan menggunakan proses DR yang berbeda. Saya cenderung tidak bergantung pada penyimpanan-alat atau replikasi tingkat SAN. Tetapi versi 10GbE dan FC dari MSA2040 mungkin lebih cocok untuk Anda.
ewwhite
6

Aturan praktis yang saya gunakan untuk disk IO adalah:

  • 75 IOP per spindle untuk SATA.

  • 150 IOP per spindle untuk FC / SAS

  • 1500 IOP per spindle untuk SSD.

Serta IOP per array juga mempertimbangkan IOP per terabyte. Ini tidak biasa berakhir dengan rasio TIO per TB yang sangat buruk jika melakukan SATA + RAID6. Ini mungkin tidak terdengar terlalu banyak, tetapi Anda akan sering berakhir dengan seseorang melihat 'ruang kosong' pada sebuah array, dan ingin menggunakannya. Sudah umum bagi orang untuk membeli gigs dan mengabaikan iops, padahal yang terjadi justru sebaliknya di sebagian besar sistem perusahaan.

Kemudian tambahkan biaya penalti tulis untuk RAID:

  • 2 untuk RAID1, RAID1 + 0
  • 4 untuk RAID5 (atau 4)
  • 6 untuk RAID6.

Denda tulis dapat dikurangi sebagian dari cache tulis besar yang bagus dan dalam kondisi yang tepat. Jika Anda memiliki banyak IO menulis berurutan (seperti log DB), Anda dapat mengurangi hukuman penulisan pada RAID 5 dan 6 secara signifikan. Jika Anda dapat menulis garis penuh (mis. Satu blok per spindel), Anda tidak harus membaca untuk menghitung paritas.

Asumsikan 8 + 2 RAID 6 set. Dalam operasi normal untuk satu tulisan IO Anda perlu:

  • Baca blok 'diperbarui'.
  • Baca blok paritas pertama
  • Baca blok paritas kedua
  • Hitung ulang paritas.
  • tulis semua 3. (6 IO).

Dengan penulisan garis penuh yang di-cache - misalnya 8 'potongan' berturut-turut ukuran garis RAID Anda dapat menghitung paritas pada keseluruhan lot, tanpa perlu membaca. Jadi, Anda hanya perlu 10 penulisan - satu untuk setiap data, dan dua paritas.

Ini membuat penalti tulis Anda 1.2.

Anda juga harus ingat bahwa menulis IO mudah untuk di-cache - Anda tidak perlu langsung masuk ke disk. Ini beroperasi di bawah batasan waktu lunak - selama rata-rata tulisan Anda tidak melebihi kecepatan spindle, semuanya akan dapat berjalan pada 'kecepatan cache'.

Baca IO di sisi lain, menderita kendala waktu - Anda tidak dapat menyelesaikan pembacaan sampai data diambil. Algoritma caching dan loading cache menjadi penting pada saat itu - pola baca yang dapat diprediksi (misalnya berurutan, seperti yang akan Anda dapatkan dari cadangan) dapat diprediksi dan diambil sebelumnya, tetapi pola baca acak tidak dapat.

Untuk database, saya biasanya menyarankan Anda berasumsi bahwa:

  • sebagian besar IO 'basis data' Anda adalah pembacaan acak. (mis. buruk untuk akses acak) Jika Anda mampu membayar overhead, RAID1 + 0 baik - karena disk yang dicerminkan memberikan dua sumber bacaan.

  • sebagian besar IO 'log' Anda adalah penulisan berurutan. (mis. bagus untuk caching, dan bertentangan dengan apa yang akan disarankan banyak DBA, Anda mungkin ingin RAID50 daripada RAID10).

Rasio keduanya sulit sulit dikatakan. Tergantung apa yang DB lakukan.

Karena baca acak IO adalah kasus terburuk untuk caching, di sinilah SSD benar-benar masuk ke dalamnya - banyak produsen tidak repot-repot caching SSD karena itu tentang kecepatan yang sama pula. Jadi terutama untuk hal-hal seperti database temporer dan indeks, SSD memberikan pengembalian investasi yang baik.

Sobrique
sumber
Terima kasih, kami 100% RAID10 karena kami fokus pada basis data.
Bip bip
Itu biasa, tetapi juga salah. RAID10 sebenarnya cukup boros untuk beban kerja terutama menulis berorientasi. RAID5 / RAID6 yang di-cache tertulis memiliki penalti tulis yang lebih rendah ketika Anda melakukan mis. Menulis file jurnal basis data.
Sobrique
3

Analisis Anda cukup benar.

Gunakan beberapa HDD untuk banyak GB, dan banyak HDD untuk beberapa IOps.
Gunakan beberapa SSD untuk banyak TIO, dan banyak SSD untuk beberapa GB

Mana yang lebih penting bagi Anda? Space adalah penggerak biaya besar untuk solusi SSD, karena harga per GB jauh lebih tinggi. Jika Anda berbicara tentang database 200GB yang membutuhkan 4K IOP, sepasang SSD akan mengantarkan Anda ke sana. Atau 24 disk array 15K drive, memberi Anda banyak ruang untuk penyimpanan massal.

Berapa banyak IOps Anda benar-benar akan keluar dari SSD sangat bervariasi berdasarkan pada infrastruktur penyimpanan (ewwhite akan menguraikan itu), tetapi masuk akal untuk mendapatkan kecepatan semacam itu. Terutama dengan Raid10, di mana paritas tidak dihitung.

sysadmin1138
sumber
Terima kasih untuk umpan baliknya! Apakah masuk akal untuk mencampur drive? Yaitu mengatur 4 SSD untuk tugas yang berorientasi pada kinerja, kemudian banyak HDD untuk penyimpanan massal?
Bip bip
3
@Beepbeep Yep, tapi waspadai pengorbanannya. Banyak iops akan mengkonsumsi sumber daya pengontrol, yang berarti Anda tidak akan mendapatkan throughput sekuensial maksimal dari HDD. Banyak throughput sekuensial pada HDD dapat mengeluarkan IO dari SSD yang semakin laten karena pertikaian saluran. Jika itu penting bagi Anda, tetapi mereka di saluran yang berbeda.
sysadmin1138
0

Saya baru-baru ini membangun sepasang server penyimpanan untuk atasan saya, menggunakan sasis Dell C2100, menjalankan FreeBSD 10.1 dengan dua belas 2TB 7200rpm Western Digital "SE" drive SATA perusahaan. Drive berada dalam kumpulan ZFS tunggal yang terdiri dari dua perangkat virtual RAIDZ-2 6-drive (vdevs). Terlampir ke kolam adalah sepasang Intel DC S3500 SSD yang superkap dilindungi terhadap kehilangan daya, mereka digunakan sebagai SLOG dan L2ARC. Memuat pengujian server ini melalui iSCSI, saya dapat mencapai 7500-8200 IOPS. Total biaya kami termasuk hard drive adalah sekitar $ 2.700 per server.

Pada saat sistem berbasis BSD ini telah berjalan, salah satu unit SAN HP MSA2012i kami telah mengalami dua kesalahan pengontrol, dan unit MSA2012i kami yang lain merusak volume NTFS yang besar yang membutuhkan 12 jam downtime untuk diperbaiki.

Dell dan HP menjual 10% perangkat keras kepada Anda dan 90% janji dukungan yang Anda tidak akan pernah bisa menggunakannya.

katoda
sumber
Ini benar ... Sebagian dari saya ingin merekomendasikan server HP yang menjalankan ZFS (atau OS alat berbasis ZFS), karena kinerjanya jauh lebih baik daripada MSA / P2000 ... tapi saya tidak ingin mematikannya pada garis singgung.
ewwhite
Oh, saya tidak punya masalah dengan HP. HP dan Dell membuat perangkat keras server yang hebat. Biasanya memuat lebih baik daripada beberapa sasis iStarUSA atau Norco. Tetapi ketika datang ke perangkat kritis (SAN / NAS sangat penting dalam buku saya), saya merekomendasikan solusi dengan transparansi sebanyak mungkin. Peralatan SAN adalah kotak hitam besar. Mereka bekerja dengan baik sampai mereka tidak melakukannya, dan kemudian kau bangun.
katoda