File SQL Server Lokal atau NAS atau SAN?

Saya harus menginstal Server baru dengan SQL Server 2008, Apa yang Anda rekomendasikan, Satu server dengan Raid 10 atau File di NAS?

Bagaimana dengan iSCSI yang harus saya gunakan?

Bagaimana dengan SAN?

Server memiliki 4Gb RAM dan file database sekitar 2GB.

Untuk membuat diri saya jelas hari ini server tidak memiliki RAID, saya harus menerapkan beberapa jenis strategi jadi jika ada sesuatu yang terjadi, saya dapat memiliki file saya aman, jadi Apa yang harus saya pilih File Lokal, NAS, SAN? Opsi apa yang paling banyak memiliki kinerja, apa yang lebih aman?

NAS

Jelas bukan NAS untuk SQL Server. SMB / CIFS tidak memiliki dukungan yang memadai untuk penguncian file untuk mendukung DBMS (setidaknya tidak beberapa tahun yang lalu, sekitar 2002-2003). Perhatikan bahwa NFS melakukannya dan Anda benar-benar dapat melakukan ini dengan Oracle pada server NFS. Namun, SQL Server pada saham CIFS tidak dapat diandalkan karena keterbatasan protokol. Bahkan mungkin tidak membiarkan Anda meletakkan file pada CIFS yang dipasang berbagi.

SAN

Ini bagus untuk aplikasi transaksional karena cache pada pengontrol RAID dapat menyerap perangkat kerja yang cukup besar. Pengontrol SAN RAID biasanya akan mendukung lebih banyak cache daripada pengontrol RAID berbasis host, terutama pada kit kelas atas di mana pengontrol RAID mungkin merupakan kotak multiprosesor yang sama kuatnya dengan server.

SAN dengan pengontrol ganda juga memiliki arsitektur tanpa titik kegagalan tunggal dan menawarkan banyak opsi untuk pencadangan panas. Ini membuat mereka menang dari perspektif pengelolaan dan keandalan. Namun mereka mahal dan terkendala untuk volume data streaming, meskipun yang terakhir tidak mungkin menjadi masalah pada sistem transaksional.

Untuk sistem operasional, SAN hampir selalu merupakan pilihan terbaik jika tersedia. Mereka juga dapat dibagi antara beberapa server yang menjalankan sistem volume menengah ke bawah. Namun mereka datang dengan label harga yang menempatkan batas bawah yang cukup substansial pada sistem terkecil yang dapat digunakan teknologi.

Lampirkan langsung

Dalam beberapa kasus, penyimpanan lampiran langsung adalah yang terbaik. Salah satu kemungkinan adalah aplikasi streaming yang dibatasi bandwidth, di mana jumlah terbatas koneksi saluran serat akan membatasi bandwidth yang tersedia menjadi kurang dari yang mungkin dengan pengontrol SAS kelas atas. Namun, ini kemungkinan merupakan aplikasi yang cukup khusus seperti gudang data yang sangat besar di mana arsitektur shared-nothing dapat memberikan throughput terbaik.

Bahkan, penyimpanan lampiran langsung seringkali lebih baik daripada SAN untuk sistem data warehouse karena beberapa alasan:

• Gudang data menempatkan lonjakan beban transien yang besar pada subsistem disk. Ini membuat mereka sangat anti-sosial di SAN karena mereka dapat mempengaruhi kinerja sistem lain di SAN.

• Hambatan streaming yang disebutkan di atas.

• Penyimpanan attachment langsung jauh lebih murah daripada penyimpanan SAN.

Pasar lain untuk penyimpanan pemasangan langsung adalah ketika Anda menjual ke pasar yang tidak akan membayar cukup uang untuk SAN. Ini sering terjadi pada aplikasi yang dijual kepada pelanggan SMB. Untuk sistem point-of-sale atau sistem manajemen praktik yang akan memiliki enam pengguna, SAN mungkin berlebihan. Dalam situasi seperti ini server menara kecil yang berdiri sendiri dengan beberapa disk internal adalah solusi yang jauh lebih tepat.

Lokal atau SAN adalah satu-satunya cara untuk mempertahankan kinerja. Dalam beberapa kasus, SAN bisa lebih cepat daripada disk lokal karena cache tulis yang lebih besar dan konfigurasi throughput disk paralel.

Hindari melakukan file I / O berkinerja tinggi di atas berbagi windows. Ada sejumlah besar overhead protokol yang akan memperlambat throughput secara dramatis. Sebagai contoh, tahun lalu saya telah mengukur transfer file besar melalui WAN ~ 50% lebih cepat menggunakan FTP melalui share Windows.

Jangan gunakan NAS.

Baik menggunakan lokal (OK untuk jangka menengah dengan kontroler RAID yang baik) tetapi jika anggaran memungkinkan, gunakan SAN yang layak. Dengan keberuntungan Anda dapat mulai "membagikan" SAN dengan sistem lain dan mendapatkan kembali sebagian besar pengeluaran awal.

RAM 4GB baik untuk sebagian besar sistem selama itu adalah SQL Server khusus (dan harus selalu demikian). Jika Anda belum mempertimbangkannya, gunakan OS 64bit dan SQL server sehingga Anda dapat dengan mudah melempar lebih banyak RAM tanpa harus berurusan dengan hal-hal PAE / AWE.

Juga pikirkan tentang virtualisasi. Anda akan memerlukan server uji? Server pengembang? Uji instalasi SP1? (Shameless plus untuk posting sebelumnya: sql-server-in-vmware )

Dengan ukuran basis data 2Gb, tidak ada alasan untuk mempertimbangkan SAN. NAS tidak akan berfungsi, Anda seharusnya hanya berpikir untuk menggunakan NAS untuk cadangan sehingga Anda tidak menyimpan cadangan pada mesin yang sama dengan data Anda, dan mudah untuk membuat salinan dari NAS untuk penyimpanan di luar lokasi.

Dengan database kecil, cukup gunakan disk lokal di RAID 1 atau RAID 10. Jika database Anda sesuai dengan RAM, Anda tidak perlu terlalu khawatir tentang kinerja IO. Gunakan windows 64-bit dan taruh 8 Gigs di sana. Itu akan menyisakan banyak untuk OS dan memberi Anda ruang untuk tumbuh.

Saya bekerja dengan sistem yang menggunakan disk RAID lokal dan juga fiber connect SAN. SAN tampak berkinerja lebih baik bahkan dengan yang sebelumnya menjadi mesin yang lebih baru dan lebih cepat. Saya pikir faktor yang signifikan adalah bahwa pengaturan disk lokal adalah drive tunggal sehingga SQL berbagi disk I / O dengan OS dan file swap. Ini kemungkinan berkontribusi besar pada hambatan.

Seperti @spoulson sebutkan, SAN dapat memberikan kinerja disk yang jauh lebih baik. Tidak hanya itu drive yang terpisah tetapi kemungkinan pada perangkat keras disk jauh lebih cepat.

Dalam kasus kami, kami menggunakan SAN karena menyediakan area penyimpanan terpusat untuk failover otomatis VERITAS kelompok layanan SQL Server. Ketika mesin utama gagal, drive windows yang dipasang pada SAN bisa dipasang kembali ke mesin cadangan panas dan server kembali cukup cepat. Tentu saja, ini membutuhkan sistem yang mirip dengan VERITAS untuk manajemen grup layanan yang mungkin berada di luar jangkauan Anda.

Satu peringatan yang kami perjuangkan adalah penugasan ruang disk SAN ditangani secara konservatif. Karena mahal, mereka tidak melakukannya dengan hati-hati. Dengan EMC SAN yang kami gunakan, Anda tidak bisa mendapatkan kembali ruang yang ditentukan tanpa membuang seluruh LUN. Jadi jika kita menemukan ruang yang dialokasikan lebih dari yang kita butuhkan dan kita ingin menggunakan sebagian dari ruang itu untuk LUN lain, kita tidak bisa hanya mengecilkan ruang yang terlalu besar. Kita harus menjatuhkannya dan menetapkan kembali. Ini tidak berfungsi dengan baik di lingkungan produksi.

Seperti yang disarankan orang lain, hindari NAS. Anda mungkin juga meletakkan file data Anda pada hard drive eksternal USB.

Untuk database 2GB kecil, SAN akan membutuhkan banyak tenaga.

Secara umum, Anda tidak ingin drive SQL Anda dibagikan dengan aplikasi lain. Demikian juga, semakin banyak spindle (disk) yang dapat Anda gunakan untuk menyebar file, semakin baik. Sekali lagi, dengan basis data kecil seperti yang Anda gambarkan, Anda akan dapat memenuhi semua yang Anda butuhkan dalam RAM, sehingga kinerja disk menjadi lebih sedikit.

Yang mengatakan, jangan pergi dan buat volume RAID-10 tunggal & meletakkan SEMUA file database Anda di atasnya. Anda bisa mulai dengan sesuatu yang sederhana seperti: Data - 2x 73GB 15K RPM, RAID1 Logs - 2x 73GB 15K RPM, RAID1 Backups - tunggal besar 7200 RPM atau sepasang di RAID1

Jika Anda memiliki anggaran untuk ditingkatkan, tambahkan volume terpisah lain untuk TempDB (jika Anda melakukan pelaporan / pertanyaan analitik yang kompleks) atau berikan disk Log volume lebih banyak & konfigurasikan sebagai RAID10 jika sistem Anda lebih banyak transaksi dengan volume tinggi pembaruan.

SAN mungkin akan memakan biaya 3-4x lipat dari penyimpanan yang terpasang langsung untuk jumlah drive yang setara. SAN memang menyediakan banyak kemampuan canggih untuk pencadangan / snapshotting, dukungan pengelompokan & migrasi LUN dan ekspansi. Jika ini penting bagi Anda, mungkin sepadan dengan biaya tambahan.

Penafian: Ada banyak masalah serius dengan menyimpan file database SQL Server pada NAS. Semua opsi lain dianggap sama, sudah benar untuk memilih opsi SAN. Diskusi terperinci tentang masalah yang relevan ada di MS KB304261 . Namun utas ini telah menjadi tangkapan bagi semua pertanyaan lain mengenai SQL Server pada jaringan berbagi, saya lebih suka memposting referensi ke keadaan dukungan NAS dalam versi SQL Server.

Cukup banyak orang sekarang bereksperimen dengan menggunakan NAS dengan MS SQL.

Ini dulunya dilarang secara default, namun seseorang dapat mengangkat batasan dalam MS SQL 2008 dan MS SQL 2005. Karena MS SQL 2008 R2 tidak ada batasan seperti itu.

Dalam MS SQL 2005 dan 2008 kuncinya adalah jejak jejak yang melarang penggunaan saham jaringan. Seseorang bisa mengeluarkan

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

Lebih detail di posting September 2010 di blog MSDN Varun Dhawan.

Setidaknya secara teknis menjalankan SQL Server pada NAS dimungkinkan. Pilihannya tergantung pada banyak faktor dan tidak sulit untuk membayangkan situasi di mana penyimpanan untuk database tersedia di NAS.