Soru İSCSI yüksek kullanılabilirlik çözümü üzerinden ZFS


Düz PC donanımının wimpy düğümleri üzerinde çalışan ve FreeBSD 9 çalıştıran bir HA / ölçeklendirilmiş / paylaşımlı-hiç veritabanı platformu için bir ZFS / iSCSI tabanlı mimarisi düşünüyorum.

Çalışacak mı? Olası dezavantajlar nelerdir?

Mimari

  1. Depolama düğümleri, ucuz SATA / SAS sürücülerini doğrudan bağladı. Her disk ayrı bir iSCSI LUN olarak dışa aktarılır. Bu katmana hiçbir RAID (ne HW veya SW), bölümleme, ses yönetimi veya bunun gibi herhangi bir şeyin dahil olmadığını unutmayın. Fiziksel disk başına sadece 1 LUN.

  2. Veritabanı düğümleri ZFS'yi çalıştırır. 3'ten iSCSI LUN'lardan bir ZFS yansıtılmış vdev oluşturulur. farklı depolama düğümleri. Vdev'in üzerine bir ZFS havuzu oluşturulur ve bunun içinde bir veritabanına karşılık gelen bir dosya sistemi.

  3. Bir disk veya depolama düğümü başarısız olduğunda, ilgili ZFS vdev bozulmuş modda çalışmaya devam edecektir (ancak yine de 2 yansıma diskine sahiptir). Başarısız disk veya depolama düğümünü değiştirmek için vdev'e farklı (yeni) bir disk atanır. ZFS yeniden ortaya çıkıyor. Başarısız bir depolama düğümü veya diski, tekrar kullanılabilir hale geldiğinde her zaman tamamen geri dönüştürülür.

  4. Bir veritabanı düğümü başarısız olduğunda, bu düğüm tarafından önceden kullanılan LUN'lar ücretsizdir. ZFS vdev / havuzunu, başarısız veritabanı düğümünün kalan LUN'larından yeniden yaratan yeni bir veritabanı düğümü açılır. Yüksek kullanılabilirlik nedenleri için veritabanı düzeyinde çoğaltmaya gerek yoktur.

Olası sorunlar

  • Vdev'in degradyonunu nasıl tespit edebilirim? Her 5’i kontrol et. ZFS ile mevcut herhangi bir bildirim hırsızlığı?

  • Vdev oluşturan mevcut LUN'lardan yeni bir havuz oluşturmak mümkün mü? Herhangi bir tuzak?


4
2017-08-21 14:56


Menşei


Neden böyle bir canavarı düşünüyorsun? Açıkladığınız şey için düşünebildiğim en iyi açıklama, "Teknik olarak mümkün, ancak akılsız" dır. - voretaq7
Ana neden: ZFS RAID'in yerel fiziksel diskler üzerinde kullanılabileceği ve yalnızca iSCSI LUN'ları olarak ihraç edildiği bir "standart" mimariyle, tam depolama düğümlerinin arızalarına karşı koruma sağlamak için ek bir fazlalık olması gerekir. Başka bir deyişle, bizim durumumuzda, veritabanı çoğaltması. Ve bu da karmaşık. Neden böyle değil? - oberstet
Şeyleri ayarlamak için oldukça standart olmayan bir yol olmanın yanı sıra (kelimenin tam anlamıyla asla Böyle bir konfigürasyon gördü, laboratuarlarda bile - eğer bunu belgeliyor ve cehennemden çıkarıyorsanız!) bir dizi ağ bağlantısını denklemle ilişkilendiriyorsunuz, buna bağlı gecikme ve başarısızlık şansları var. Zaten yerel diskli N depolama düğümlerine sahip olduğunuz için neden böyle bir şey düşünmeyin HAST & düğüm hatası koruması için geleneksel yük devretme araçları? - voretaq7
HAST'a işaret ettiğiniz için teşekkürler! HAST kullanımı oldukça benzerdir: fiziksel diskleri tutan ve veritabanı çoğaltma seviyesinin altında olan depolama düğümlerinin üstünde fazlalık. Ancak HAST sadece 2 düğüm destekler, sadece 1 aktif olabilir. ZFS aynası ayrıca 3 depolama düğümünü de destekler ve tüm verileri okumak için okları artırabilir. HAST CARP .. kullanır. Ek karmaşıklık. Mimarlığın kötüye gittiği konusunda: muhtemelen haklısınız, neden merak ediyorum? SAN LUN'ları üzerinden ZFS vdevs oluşturma bile önerilmektedir: hub.opensolaris.org/bin/view/Community+Group+zfs/... - oberstet
CARP gerçekten bu kadar karmaşık değil (cevabım ve bağlantılı dokümanlara bakın) - gerçekten temelde bir şey yok yanlış önerdiğin şeyle, ama bence yapılmadığını (veya en azından belgelenmediğini), bu yüzden kenar koşullarının hepsi bilinmez ve test edilmeye ihtiyacı olacak. Bunu bir blog gönderisini uygularsanız veya burada kurulumunuzu ve testte karşılaştığınız tuhaflıkları detaylandıran bir yanıt çok beğenilir - önerdiğiniz tasarıma bazı avantajlar katabilirim. Ayrıca üzerine atlayabilirsiniz SF Sohbet tasarımdan daha fazla konuşmak. - voretaq7


Cevaplar:


Sorunuza doğrudan bir cevap değil, ama bu tür bir şey için daha geleneksel bir mimari kullanmak HAST ve SAZAN Depolama fazlalığı ile ilgilenmek.


Temel bir taslak (daha iyi detaylar için bağlantılı belgelere bakın):

Makine A ("Master")

  • HAST daemonunu yapılandırın ve her havuz üyesi cihaz için uygun bir kaynak oluşturun.
  • HAST cihazlarını kullanarak, tek bir sistemde yaptığınız gibi ZFS yansıtılmış cihazınızı oluşturun.

Makine B ("Köle")

  • HAST daemon'unu Master'da yaptığınız şeye benzer şekilde yapılandırın, ancak ikincil / bağımlı bir düğüm olarak getirin.
    (HAST sizin için Master'dan Köle'ye tüm verileri yansıtacaktır)

Her iki makine


Buradaki büyük uyarı, HAST'ın yalnızca bir Master / Slave seviyesinde çalıştığıdır. Bu nedenle, dışa aktarmak istediğiniz her bir LUN / set LUN için makineler çiftine ihtiyacınız vardır.

Farkında olmanız gereken bir başka şey ise, depolama mimarinizin önerilen tasarımda olduğu kadar esnek olmayacağıdır:
HAST ile bir çift makineye yerleştirebileceğiniz disk sayısı ile sınırlıdır.
Teklif ettiğiniz ISCSI mesh benzeri yapı ile teorik olarak daha fazla LUN ihraç eden ve istediğiniz kadar büyütebileceğiniz (ağınızın sınırına) daha fazla makine ekleyebilirsiniz.

Esneklikteki bu tradeoff, size herhangi bir FreeBSD yöneticisinin kutudan anlayacağı (ya da el kitabını okuyabileceğini ve anlayabildiğini) test edilmiş, kanıtlanmış, belgelenmiş bir çözümü satın alır - benim için değerli bir trade-off :-)


8
2017-08-21 16:05





"zpool status -x", tüm havuzların sağlıklı olup olmadığını veya çıkmayanların durumlarını çıkarır. Bir iSCSI LUN vdev çevrimdışıysa, bu komut etrafında bir komut dosyası çalıştıran bir cron işi, düzenli olarak cron uyarıları almanın bir yolunu vermelidir.

"zpool import" mevcut zpool'u iSCSI LUNs vdevs'ten içe aktarabilmelidir. Havuzu temiz bir şekilde dışa aktarılmadıysa içe aktarmayı zorlamanız gerekebilir, ancak veritabanı meta verisi başarısız olursa, iç meta veriler verileri tutarlı bir halde tutmalıdır.


4
2017-08-21 15:32



Periyodik olarak çalışan zpool durumu, tamam. Ama "olay odaklı" bir şey yok mu? Başarısız bir disk gibi olayları yayabilecek bir ZFS Dtrace sağlayıcısı var mı? Zpool içe aktarma ile ilgili olarak: bir havuzu yeniden oluşturmak için gereken tüm bilgiler vdevs (ve vdev mirror ile, dolayısıyla da redundently) içinde saklanır? Ev sahibinden hiçbir bilgi (tamamen öldü) gerekli midir? - oberstet
Çevrimdışı bir diskin fark edilmesine dair herhangi bir olayın farkında değilim, belki tasarımınızda belki de iSCSI başlatıcısı bir hedefle iletişim kuramadığında veya LUN kullanılabilirliğini doğrudan izlemek için başka bir yolla proaktif izleme yapabilir. - Thomas G
Onun daha da zor. Tüm FreeBSD9 2 depolama VM ve 2 veritabanı VMs bir test kurulumu kullanıyorum. 2 depolama düğümünden LUN üzerinden 2 yönlü yansıtılmış havuz oluşturuldu. Bir depolama düğümünün gitip tekrar açılmasından sonra yeniden boyutlandırmayı doğrulayabilirim. Ancak, sol depolama düğümü için veritabanı düğümündeki iscontrol'ü öldürmem gerekiyordu. Bunu yapmadan iscontrol sonsuza dek sessizce yeniden bağlanmaya çalışır. Sadece ZFS havuzuna eriştikten sonra başlıyor. Ancak, yeniden denediği sürece herhangi bir ZFS havuzu komutu kilitleniyor. Daha fazla deney yapmamız gerekiyor. Kendisini düzenleyemeden iscontrol'ü çalıştırabilir miyim? - oberstet