Tuning penyimpanan iSCSI

29

Ini adalah Pertanyaan Canonical tentang iSCSI yang dapat kita gunakan sebagai referensi.

iSCSI adalah protokol yang menempatkan perintah SCSI sebagai muatan ke paket jaringan TCP. Karena itu, ia mengalami serangkaian masalah yang berbeda dari, katakanlah, Fibre Channel. Sebagai contoh, jika sebuah link menjadi macet dan buffer switch penuh, Ethernet akan, secara default, menjatuhkan frame daripada memerintahkan host untuk memperlambat. Hal ini menyebabkan pengiriman ulang yang mengarah ke latensi tinggi untuk sebagian kecil lalu lintas penyimpanan.

Ada solusi untuk masalah ini, tergantung pada sistem operasi klien, termasuk mengubah pengaturan jaringan. Untuk daftar OS berikut, seperti apa konfigurasi klien iSCSI yang optimal? Apakah ini melibatkan perubahan pengaturan pada sakelar? Bagaimana dengan penyimpanannya?

  • VMWare 4 dan 5
  • Windows Hyper-V 2008 & 2008r2
  • Windows 2003 dan 2008 pada bare metal
  • Linux pada logam telanjang
  • AIX VIO
  • OS lain apa pun yang kebetulan Anda pikir akan relevan
Basil
sumber
iSCSI jauh lebih kompleks dari itu - tetapi sehubungan dengan IP-stack, semua berlaku untuk throughput tinggi, koneksi latensi rendah IP - tidak terlalu istimewa di sini.
Nils

Jawaban:

6

Saya tidak terbiasa dengan VMWare, tetapi saya menggunakan Xenserver dan saya telah menggunakan Hyper-V (R2).

Dengan konfigurasi Xenserver saya saat ini, saya memiliki:

  • 8 server Dell Poweredge 29xx
  • 2 sakelar Dell Powerconnect 6248
  • 2 Dell MD3000i SAN (iSCSI)

Saya telah mengatur switch saya dalam konfigurasi multipath dan dioptimalkan untuk iSCSI dengan:

  • Memisahkan switch saya menjadi 3 VLANS (2 untuk lalu lintas iSCSI dan 1 untuk manajemen)
  • Menggunakan JumboFrames
  • Menerapkan optimisasi "iSCSI" yang dimiliki powerconnect

Setiap server memiliki beberapa kartu jaringan untuk menyediakan koneksi ke setiap switch, yang pada gilirannya menyediakan redundansi melalui multipathing antara server dan iSCSI SAN. VLAN iSCSI tidak mengandung lalu lintas selain iSCSI.

Saya senang melaporkan bahwa dengan konfigurasi ini "cluster" Xenserver berfungsi dengan baik.

Di samping catatan saya punya server Windows 2008 yang terhubung langsung oleh iSCSI ke HP SAN (server file lama). Dulu menjalankan Windows 2003, dan secara teratur akan menjatuhkan koneksi (bahkan setelah menginstal ulang tahun 2003); Namun, segera setelah saya memutakhirkan ke windows 2008 tetap terhubung.

Saya akan dengan senang hati menjawab pertanyaan apa pun tentang pengaturan saya.

Steve
sumber
1
Apakah Anda menggunakan kabel susun di antara kedua sakelar Dell?
SpacemanSpiff
Mengapa iSCSI? Mengapa tidak DRBD pada MD3000 yang terhubung langsung?
Nils
@SpacemanSpiff Switch saya tidak ditumpuk.
Steve
@Nils Saya belum meneliti DRBD, meskipun saya pernah mendengarnya. Apa yang akan ditawarkan DRBD melalui iSCSI untuk penyimpanan saya yang terhubung langsung?
Steve
DRBD tidak memiliki overhead SCSI. Hal lain adalah Anda tidak dapat menyingkirkan proses klien-iSCSI ketika server iSCSI Anda mati atau tidak dapat dijangkau (yang terakhir seharusnya tidak menjadi masalah dalam pengaturan Anda).
Nils
3

Ini bukan jawaban ... belum. Ini adalah kerangka kerja untuk Jawaban Umum. Jika Anda punya waktu, silakan isi apa pun yang Anda ketahui. Berkenaan dengan mengkonfigurasi perangkat keras tertentu, silakan kirim jawaban terpisah untuk masing-masing vendor sehingga kami dapat menjaga informasi tersebut terorganisir dan terpisah.

Profil QoS ke port, serta mematikan kontrol badai, mengatur MTU ke 9000, menyalakan kontrol aliran, dan menempatkan port ke portfast

Throughput dan Latency

Firmware yang diperbarui, driver, dan sistem lainnya

MPIO

Bingkai Jumbo / MTU

Karena kecepatan tautan jaringan meningkat, jumlah paket yang berpotensi dihasilkan juga meningkat. Ini menghasilkan semakin banyak CPU / waktu interupsi yang dihabiskan untuk menghasilkan paket-paket yang memiliki efek membebani sistem transmisi secara berlebihan dan mengambil bandwidth link dengan jumlah yang berlebihan.

Frame yang disebut "jumbo" adalah frame Ethernet yang melebihi batas 1518 byte kanonik. Sementara jumlahnya dapat bervariasi berdasarkan vendor switch, sistem operasi dan NIC, ukuran paket jumbo yang paling umum adalah 9000 dan 9216 byte (yang terakhir adalah yang paling umum). Mengingat bahwa sekitar 6X data dapat dimasukkan ke dalam bingkai 9K, jumlah paket aktual (dan interupsi) dikurangi dengan jumlah yang sama pada host. Keuntungan ini terutama diucapkan pada tautan berkecepatan lebih tinggi (yaitu 10GE) yang mengirim data dalam volume besar (yaitu iSCSI).

Mengaktifkan frame jumbo membutuhkan konfigurasi host dan switch Ethernet dan harus diperhatikan sebelum implementasi. Beberapa pedoman harus diikuti-

1.) Dalam segmen Ethernet yang diberikan (VLAN) semua host dan router harus memiliki MTU yang sama dikonfigurasi. Perangkat tanpa konfigurasi yang tepat akan melihat bingkai yang lebih besar sebagai kesalahan tautan (khususnya "raksasa") dan menjatuhkannya.

2.) Dalam protokol IP, dua host dengan ukuran bingkai yang berbeda memerlukan mekanisme untuk menegosiasikan ukuran bingkai umum yang sesuai. Untuk TCP ini adalah jalur penemuan MTU (PMTU) dan bergantung pada transmisi paket ICMP yang tidak terjangkau. Pastikan bahwa PMTU diaktifkan pada semua sistem dan bahwa setiap ACL atau aturan firewall mengizinkan paket-paket ini.

Kontrol Aliran Ethernet (802.3x)

Meskipun direkomendasikan oleh beberapa vendor iSCSI, kontrol aliran ethernet 802.3x yang sederhana tidak boleh diaktifkan di sebagian besar lingkungan kecuali semua port switch, NIC, dan tautan sepenuhnya didedikasikan untuk lalu lintas iSCSI dan tidak ada yang lain. Jika ada lalu lintas lain pada tautan (seperti berbagi file SMB atau NFS, detak jantung untuk penyimpanan berkerumun atau VMware, lalu lintas kontrol / pemantauan tim NIC, dll.) Kontrol aliran 802.3x sederhana tidak boleh digunakan karena memblokir seluruh port dan lalu lintas non-iSCSI lainnya juga akan diblokir. Keuntungan kinerja Ethernet Flow Control seringkali minimal atau tidak ada, pembandingan yang realistinc harus dilakukan pada seluruh kombinasi OS / NIC / sakelar / penyimpanan yang dipertimbangkan untuk menentukan apakah ada manfaat aktual.

Pertanyaan aktual dari perspektif server adalah: Apakah saya menghentikan lalu lintas jaringan jika NIC atau Jaringan saya dikuasai, atau apakah saya mulai menjatuhkan dan mengirimkan kembali paket? Mengaktifkan kontrol aliran akan memungkinkan buffer NIC dikosongkan di sisi penerima tetapi akan menekankan buffer di sisi pengirim (biasanya perangkat jaringan akan buffer di sini).

Kontrol Kemacetan TCP (RFC 5681)

TOE (TCP / IP Offload Engine)

iSOE (Mesin Offload iSCSI)

LSO (Segmentasi TCP / Besar Kirim Pembongkaran)

Isolasi Jaringan

Praktik terbaik umum untuk iSCSI adalah mengisolasi kedua pemrakarsa dan target dari lalu lintas jaringan non-penyimpanan lainnya. Ini menawarkan manfaat dalam hal keamanan, pengelolaan dan, dalam banyak kasus, dedikasi sumber daya untuk lalu lintas penyimpanan. Isolasi ini dapat mengambil beberapa bentuk:

1.) Isolasi fisik - semua inisiator memiliki satu atau lebih NIC yang didedikasikan hanya untuk lalu lintas iSCSI. Ini mungkin - atau mungkin tidak - mengimplikasikan perangkat keras jaringan yang tergantung pada kemampuan perangkat keras yang dimaksud dan keamanan spesifik dan persyaratan operasional dalam suatu organisasi.

2.) Isolasi logis - Sebagian besar ditemukan di jaringan yang lebih cepat (yaitu 10GE), pemrakarsa memiliki penandaan VLAN (lihat 802.1q) yang dikonfigurasi untuk memisahkan lalu lintas penyimpanan dan non-penyimpanan.

Di banyak organisasi, mekanisme tambahan digunakan untuk memastikan bahwa pemrakarsa iSCSI tidak dapat menjangkau satu sama lain melalui jaringan khusus ini dan, lebih jauh, jaringan khusus ini tidak dapat dijangkau dari jaringan data standar. Langkah-langkah yang digunakan untuk mencapai hal ini termasuk daftar kontrol akses standar, VLAN pribadi, dan firewall.

Sesuatu tentang backplane dan switching fabric di sini juga.

QoS (802.1p)

vLAN (802.1q)

STP (RSTP, MSTP, dll)

Supresi Lalu Lintas (Kontrol Badai, Kontrol Multi / Broad-cast)

Keamanan

Otentikasi dan Keamanan

BAB

IPSec

Pemetaan LUN (Praktik Terbaik)

Chris S
sumber
Apakah ada merdu untuk RFC 5681 di perangkat apa pun? Jika tidak kita harus menghapus bagian itu.
Nils
Apakah perlu menambahkan bahwa frame jumbo jarang didukung untuk replikasi iSCSI (karena semua perangkat WAN perantara harus mendukungnya)?
Jeremy
@ Jeremy yakin - tulis di atas. Bahkan di LAN - jika Anda lupa satu perangkat di jalan (atau jika tim jaringan outsourcing Anda melakukan kesalahan konfigurasi sesuatu) jalur MTU tidak akan mendukung frame jumbo.
Nils
Setuju dengan Jeremy. Nils, jika TCP-CC tersedia memungkinkan itu memiliki kemungkinan manfaat dan konsekuensi, itu harus diuraikan setidaknya.
Chris S
1

Beberapa pertimbangan dan penelitian yang harus Anda ambil secara subyektif terkait:

1) Multi-pathing - Solusi SAN Anda dan OS Anda, baik hypervisor atau bare metal OS mungkin memerlukan perangkat lunak khusus vendor agar ini berfungsi dengan baik.

2) Pemrakarsa - Anda perlu memeriksa apakah pemrakarsa perangkat lunak memiliki kinerja yang cukup berdasarkan permintaan. Banyak NIC memiliki kemampuan offloading iSCSI yang secara signifikan dapat meningkatkan throughput, tetapi beberapa hypervisor yang lebih tua telah diketahui menjadi sangat jengkel dengan dukungan mereka secara bijaksana. Persembahan yang lebih matang (ESXi 4.1+) tampaknya cocok.

3) Keamanan / Izin - Pastikan untuk sepenuhnya memeriksa inisiator mana yang memerlukan akses ke LUN ... Anda akan berada di hari yang buruk jika admin di salah satu mesin Windows Anda melakukan "inisialisasi disk" pada disk yang benar-benar digunakan oleh server lain sebagai datastore VMware.

SpacemanSpiff
sumber
Sehubungan dengan multi-pathing - sebenarnya Anda dapat mencapai ini melalui jaringan yang berbeda juga - yang sedikit lebih rumit dengan IP daripada dengan FC-SAN (di mana konsep SAN A / B dengan kain perangkat keras yang berbeda cukup umum).
Nils
Pengalaman saya dengan multi-pathing terutama bersifat equallogic, dalam hal ini klien biasanya diberi alamat IP penemuan (grup IP) dan kemudian bernegosiasi dengan alamat itu untuk alamat target yang sebenarnya. Saya kira ini bisa dilakukan dengan jaringan yang berbeda dan klien akan memiliki jalur untuk itu, atau tidak, tetapi penemuan akan turun jika subnet yang digunakan grup IP adalah yang mati.
SpacemanSpiff
Saya mencoba (asli) multipathing pada SLES11 pada VLAN yang berbeda. Bagian yang sulit adalah untuk memodifikasi konfigurasi multipath, sehingga target iSCSI yang pergi ke penyimpanan fisik yang sama dilihat sebagai perangkat yang sama.
Nils