İSCSI depolama alanını ayarlama


29

Bu, referans olarak kullanabileceğimiz iSCSI hakkında Kanonik bir Soru .

iSCSI, SCSI komutlarını veri yükü olarak TCP ağ paketlerine yerleştiren bir protokoldür. Dolayısıyla, Fiber Kanal'dan farklı bir dizi soruna maruz kalmaktadır. Örneğin, bir bağlantı tıkanır ve anahtarın arabellekleri doluysa, Ethernet varsayılan olarak, ana makineye yavaşlatmalarını bildirmek yerine kareleri düşürür. Bu, depolama trafiğinin çok küçük bir kısmı için yüksek gecikmeye neden olan yeniden iletimlere neden olur.

İstemci işletim sistemine bağlı olarak, ağ ayarlarını değiştirmek de dahil olmak üzere bu sorunun çözümleri vardır. Aşağıdaki işletim sistemleri listesi için, optimum bir iSCSI istemci yapılandırması nasıl görünür? Anahtarlardaki ayarların değiştirilmesini içerir mi? Peki ya depolama alanı?

  • VMWare 4 ve 5
  • Windows Hyper-V 2008 ve 2008r2
  • Çıplak metal üzerine Windows 2003 ve 2008
  • Çıplak metal üzerinde Linux
  • AIX VIO
  • Düşündüğünüz diğer işletim sistemleri alakalı olabilir

iSCSI bundan çok daha karmaşıktır - ancak IP yığınına gelince, hepsi yüksek verimli, düşük gecikmeli IP bağlantılarına uygulanan - burada çok özel değildir.
Nils

Yanıtlar:


6

VMWare'e aşina değilim, ancak Xenserver kullanıyorum ve Hyper-V (R2) kullandım.

Mevcut Xenserver konfigürasyonum ile:

  • 8 Dell Poweredge 29xx sunucu
  • 2 Dell Powerconnect 6248 anahtarları
  • 2 Dell MD3000i SAN (iSCSI)

Anahtarlarımı çok yollu bir yapılandırmada ayarladım ve iSCSI için optimize ettim:

  • Anahtarlarımı 3 VLANS'a ayırma (iSCSI trafiği için 2 ve yönetim için 1)
  • JumboFrames'i Kullanma
  • Powerconnect’in sahip olduğu "iSCSI" optimizasyonlarını uygulama

Her sunucu, her bir anahtara bağlantı sağlamak için birden fazla ağ kartına sahiptir ve sırayla sunucular ve iSCSI SAN arasında çoklu yolla fazlalık sağlar. İSCSI VLAN'ları, iSCSI'dan başka bir trafik içermemektedir.

Bu konfigürasyonla, Xenserver "kümesinin" mükemmel çalıştığını bildirmekten memnuniyet duyuyorum.

Bir yandan notta, doğrudan iSCSI ile bir HP SAN'a (eski dosya sunucusu) bağlanmış bir Windows 2008 sunucum var. Windows 2003'ü çalıştırmak için kullanılırdı ve düzenli olarak bağlantıyı bırakırdı (2003'ün yeniden yüklenmesinden sonra bile); Ancak, Windows 2008’e yükseldiğimde bağlı kalıyor.

Kurulumumla ilgili herhangi bir soruyu cevaplamaktan mutlu olurum.


1
İki Dell anahtarı arasındaki istifleme kablolarını mı kullanıyorsunuz?
SpacemanSpiff

Neden iSCSI? Neden doğrudan bağlı MD3000'de DRBD kullanılmıyor?
Nils

@SpacemanSpiff Anahtarlarım yığılmadı.
Steve

@Haberler duyduğum halde DRBD'yi araştırmadım. Doğrudan bağlı depolamam için DRBD iSCSI üzerinden ne teklif edecek?
Steve

DRBD'nin SCSI ek yükü yok. Diğer bir şey, iSCSI sunucunuz öldüğünde veya erişilemediğinde bir iSCSI-istemci işleminden kurtulamamanızdır (ikincisi kurulumunuzda bir sorun olmamalıdır).
Nils,

3

Bu bir cevap değil ... henüz. Genel Cevap için çerçeve budur. Vaktiniz varsa lütfen bildiğiniz her şeyi doldurunuz. Belirli bir donanımın yapılandırılmasıyla ilgili olarak, lütfen her satıcı için ayrı bir cevap gönderin, böylece bilgileri düzenli ve ayrı tutabiliriz.

QoS profili portlara, ayrıca fırtına kontrolünü kapatmak, MTU’yu 9000’e ayarlamak, akış kontrolünü açmak ve portları portfast içine koymak

Verimlilik ve Gecikme

Güncellenen bellenim, sürücüler ve diğer sistemler

MPIO

Jumbo Çerçeveler / MTU

Ağ bağlantılarının hızı arttıkça, potansiyel olarak üretilen paketlerin sayısı da artar. Bu, hem aktarma sistemini gereksiz yere yükleyen hem de çerçeveleme ile aşırı miktarda bağlantı bant genişliği kaplayan etkiye sahip olan paketler üretmek için harcanan daha fazla CPU / kesme süresi sağlar.

"Jumbo" kareleri, kanonik 1518 bayt sınırını aşan Ethernet kareleridir. Rakamlar anahtar satıcılarına göre değişebilirken, işletim sistemleri ve NIC'lerin en tipik jumbo paket boyutları 9000 ve 9216 bayttır (ikincisi en yaygın olanıdır). Kabaca 6X veri 9K çerçeveye konabilir göz önüne alındığında, gerçek paketlerin (ve kesmeler) sayısı, ana bilgisayar üzerinde benzer bir miktarda azalır. Bu kazançlar özellikle büyük miktarlarda veri gönderen (yani iSCSI) daha yüksek hızlı (yani 10GE) bağlantılarda okunur.

Jumbo çerçevelerin etkinleştirilmesi hem ana bilgisayarın hem de Ethernet anahtarının yapılandırılmasını gerektirir ve uygulamadan önce dikkat edilmesi gerekir. Birkaç kural izlenmelidir

1.) Belirli bir Ethernet segmentinde (VLAN) tüm ana bilgisayarlar ve yönlendiriciler aynı MTU'ya sahip olmalıdır. Düzgün yapılandırılmamış bir cihaz, daha büyük kareleri bağlantı hataları (özellikle "devler") olarak görür ve düşürür.

2.) IP protokolünde, farklı çerçeve boyutlarına sahip iki ana bilgisayarın, uygun bir ortak çerçeve boyutunu pazarlık etmek için bazı mekanizmalara ihtiyacı vardır. TCP için bu yol MTU (PMTU) keşfidir ve ICMP'ye erişilemeyen paketlerin iletilmesine dayanır. PMTU'nun tüm sistemlerde etkin olduğundan ve herhangi bir ACL'nin veya güvenlik duvarı kuralının bu paketlere izin verdiğinden emin olun.

Ethernet Akışı Kontrolü (802.3x)

Bazı iSCSI satıcılar tarafından önerilen olmasına rağmen, basit 802.3x ethernet akış kontrolü gerekir değil tüm anahtar portları, NIC ve bağlantılar sürece çoğu ortamda etkin olması tamamen iSCSI trafiği adanmış ve başka bir şey. Basit 802.3x akış kontrolü (örneğin SMB veya NFS dosya paylaşımı, kümelenmiş depolama veya VMware, NIC gruplandırma kontrolü / izleme trafiği, vs. kalp atışları gibi) linklere başka bir trafik varsa gereken değil engeller tüm limanları olarak kullanılabilir ve iSCSI dışındaki diğer trafik de engellenir. Ethernet Akış Kontrolü'nün performans kazanımları çoğu zaman minimum veya yoktur, gerçek bir fayda olup olmadığını belirlemek için düşünülen OS / NIC / anahtar / depolama kombinasyonlarının tamamında realistinc kıyaslama yapılmalıdır.

Bir sunucu perspektifinden asıl soru şudur: NIC veya Ağım aşılırsa ağ trafiğini durdurur muyum, yoksa paketleri bırakıp tekrar göndermeye mi başlarım? Akış kontrolünün açılması, NIC'in tamponlara alıcı tarafında boşaltılmasına izin verecektir, ancak gönderici tarafındaki tamponları vurgulayacaktır (normalde bir ağ cihazı burada tamponlanacaktır).

TCP Tıkanıklık Kontrolü (RFC 5681)

TOE (TCP / IP Boşaltma Motorları)

iSOE (iSCSI Boşaltma Motorları)

LSO (TCP Bölümleme / Büyük Gönderme Boşaltma)

Ağ İzolasyonu

İSCSI için en yaygın kullanılan yöntem, başlatıcıları ve hedefleri diğer depolama dışı ağ trafiğinden izole etmektir. Bu, güvenlik, yönetilebilirlik ve çoğu durumda kaynakların depolama trafiğine tahsis edilmesi açısından faydalar sunar. Bu izolasyon birkaç şekilde olabilir:

1.) Fiziksel izolasyon - tüm başlatıcılarda yalnızca iSCSI trafiğine yönelik bir veya daha fazla NIC bulunur. Bu, söz konusu donanımın özelliklerine ve belirli bir kuruluştaki belirli güvenlik ve işletim gereksinimlerine bağlı olarak adanmış bir ağ donanımı olabilir.

2.) Mantıksal izolasyon - Çoğunlukla daha hızlı (yani 10GE) ağlarda bulunur, başlatıcılar, depolama ve depolama dışı trafiği ayırmak için yapılandırılmış VLAN etiketine sahiptir (bkz. 802.1q).

Birçok kuruluşta, iSCSI başlatıcılarının bu tahsisli ağlar üzerinden birbirlerine ulaşamadıklarını ve ayrıca bu tahsisli ağların standart veri ağlarından erişilemeyeceğinin temin edilmesi için ek mekanizmalar da kullanılmaktadır. Bunu gerçekleştirmek için kullanılan önlemler standart erişim kontrol listelerini, özel VLAN'ları ve güvenlik duvarlarını içerir.

Burada da arka panel ve kumaş değiştirme hakkında bir şey.

QoS (802.1p)

vLAN (802.1q)

STP (RSTP, MSTP, vb.)

Trafik Bastırma (Fırtına Kontrolü, Çok / Geniş Döküm Kontrolü)

Güvenlik

Kimlik Doğrulama ve Güvenlik

CHAP

IPSec

LUN Haritalama (En İyi Uygulamalar)


Herhangi bir cihazda RFC 5681 için herhangi bir ayarlayıcı var mı? Değilse bu bölümü silmeliyiz.
Nils,

Jumbo çerçevelerin iSCSI replikasyonu için nadiren desteklendiğini eklemek faydalı olabilir mi (tüm aracı WAN cihazlarının onları desteklemesi gerektiğinden)?
Jeremy

@ Jeremy eminim - üstüne yaz. LAN'da bile - yolda bir cihazı unutursanız (veya dış kaynaklı ağ ekibiniz bir şeyi yanlış yapılandırırsa), MTU yolu jumbo çerçevelerini desteklemeyecektir.
Nils,

Jeremy ile aynı fikirde. Nils, eğer TCP-CC'yi mümkün kılıyorsa, bunun yararları ve sonuçları vardır, bunlar en azından belirtilmelidir.
Chris S

1

Bazı göz ve araştırma sizi alınmalıdır subjektif açısından:

1) Çoklu markalama - SAN çözümünüz ve işletim sisteminiz hipervizör veya çıplak metal işletim sistemi olsun, bunun düzgün çalışması için satıcıya özel bir yazılım gerekebilir.

2) Başlatıcılar - Yazılım başlatıcının taleplere göre yeterli performans gösterip göstermediğini incelemelisiniz. Birçok NIC, verimi önemli ölçüde artırabilen iSCSI boşaltma yeteneklerine sahiptir, ancak bazı eski hipervizörlerin, akıllıca destek almaları konusunda oldukça sinirlendikleri bilinmektedir. Daha olgun teklifler (ESXi 4.1+) güzel görünüyor.

3) Güvenlik / İzinler - Hangi başlatıcıların hangi LUN'lara erişmesi gerektiğini tamamen gözden geçirdiğinizden emin olun ... Windows makinelerinizden birinde bir yönetici bir diskte bir "disk başlat" yapıyorsa, kötü bir gün geçirirsiniz. gerçekten başka bir sunucu tarafından VMware veri deposu olarak kullanılıyor.


Çoklu markalama ile ilgili olarak - aslında bunu farklı ağlar üzerinden de başarabilirsiniz - bu da IP için biraz daha zor olan FC-SAN'dan (farklı donanım kumaşlarıyla SAN A / B kavramının oldukça yaygın olduğu).
Nils

Çok yollu yazma ile ilgili deneyimim öncelikle eşitlik kazandı, bu durumda müşteriye genellikle bir keşif IP adresi (grup IP) verilir ve daha sonra gerçek adresler için bu adresle görüşür. Sanırım bunun farklı ağlarla yapılabileceğini ve müşterinin ya buna bir yolu olacağını ya da etmeyeceğini, ancak IP’nin üzerinde bulunduğu alt ağın ölen ağ olduğunu tespit edersek keşif azalır.
SpacemanSpiff

SLES11'de farklı VLAN'larda (yerel) çoklu yollamayı denedim. Zor kısım çok yollu konfigürasyonu değiştirmekti, bu yüzden aynı fiziksel depoya giden iSCSI hedefleri aynı cihaz olarak görüldü.
Nils,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.