ZFS - tekilleştirilmiş zvol veya veri kümesinin yok edilmesi sunucuyu durdurur. Nasıl kurtarılır?

Nexentastor'u 12 Midline (7200 RPM) SAS sürücülü bir HP ProLiant DL180 G6 üzerinde çalışan ikincil bir depolama sunucusunda kullanıyorum. Sistemde bir E5620 CPU ve 8GB RAM var. ZIL veya L2ARC cihazı yok.

Geçen hafta, iSCSI aracılığıyla bir VMWare ESX ana bilgisayarında paylaşılabilecek veri tekilleştirme ve sıkıştırma özellikli 750 GB'lık seyrek bir zvol oluşturdum. Daha sonra bir Windows 2008 dosya sunucusu görüntüsü oluşturdum ve ~ 300GB kullanıcı verilerini VM'ye kopyaladım. Sistemden memnun kaldığımda, sanal makineyi aynı havuzdaki bir NFS mağazasına taşıdım.

NFS veri deposundaki VM'lerimle çalışmaya başladıktan sonra, orijinal 750GB zvol'u kaldırmaya karar verdim. Bunu yapmak sistemi durdurdu. Nexenta web arayüzüne ve NMC'ye erişim durdu. Sonunda ham bir kabuk elde edebildim. Çoğu işletim sistemi işlemi iyiydi, ancak sistem zfs destroy -r vol1/filesystemkomutun üzerinde duruyordu. Çirkin. Aşağıdaki iki OpenSolaris bugzilla girdisini buldum ve şimdi makinenin bilinmeyen bir süre için tuğlalanacağını anladım. 14 saat oldu, bu yüzden sunucuya yeniden erişim kazanmak için bir plana ihtiyacım var.

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390

ve

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=593704962bcbe0743d82aa339988?bug_id=6924824

Gelecekte, muhtemelen buzilla geçici çözümlerinden birinde verilen tavsiyeyi alacağım:

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

Güncelleme: Sistemi kapanmaya zorlamak zorunda kaldım. Yeniden başlatıldığında, sistem durur Importing zfs filesystems. 2 saattir böyle.

Bu çözüldü. Anahtarları, tekilleştirilen birimlerin, silinmeden önce tekilleştirme bayrağını kapatması gerektiğidir. Bu, zvol veya dosya sistemi seviyesinde olduğu kadar havuz düzeyinde de yapılmalıdır. Aksi takdirde, silme işlemi temel olarak tekilleştirilir. ZFS veri tekilleştirme tablosuna başvurulduğu için işlem zaman alıyor. Bu durumda RAM yardımcı olur. Geçici olarak sisteme 16 ek Gigabayt RAM ekledim ve sunucuyu tekrar çevrimiçi duruma getirdim. Zpool 4 saat içinde tamamen ithal edildi.

Ahlaki muhtemelen, tekilleştirmenin süper cilalı olmaması ve RAM'in performansı için çok önemlidir. Çevreye bağlı olarak 24GB veya daha fazlasını öneriyorum. Aksi takdirde, ZFS tekilleştirmesini kapalı bırakın. Ev kullanıcıları veya daha küçük sistemler için kesinlikle makul değildir.

Sun / Oracle ZFS 7000 serisi cihazların uzun süredir kullanıcısı olarak, soru indirmeden cilalanmadığını söyleyebilirim. Satışları asla teslimatla karıştırmayın! Satış temsilcileri size "Ah, düzeltildi" diyecektir. Gerçek hayatta - gerçek hayatımda - 24GB'ın "DDT tablolarını" işlemek için yeterli olmadığını söyleyebilirim. Yani, tekilleştirme tablosunu depolayan arka uç dizini. Bu tablo sistem belleğinde bulunmalıdır, böylece her bir G / Ç, diske yazılması gerekip gerekmediğini anlamak için uçuş sırasında yakalanır. Depolama havuzunuz büyüdükçe, daha fazla veri değişikliği, bu tablo daha büyük ve sistem belleğine olan talep artar. Bu bellek, ARC (önbellek) ve zaman zaman işletim sisteminin kendisi pahasına gelir - bu nedenle, bazı komutlar ön planda, bazıları arka planda gerçekleştiği için kilitlenmeleri yaşarsınız. CLI'de aksi belirtilmedikçe, havuz silme işlemi ön planda olur. GUI sihirbazları bunu yapmayacak.

Veri tekilleştirilen bir birimde tanımlanan bir paylaşım içindeki NFS verilerinin toplu olarak silinmesi bile, ZFS'ye "yazma" yı işlemek için yeterli belleğiniz yoksa verileri silmesini söyleyen sisteminizi yarıya indirir.

Toplamda, hafızanızı maksimize etmediyseniz ve o zaman bile, ARC ve DDT'yi kısıtlayarak işletim sistemi için bellek ayırmanın bir yolunu bulun (ve DDT'yi doğasıyla kısıtlayabileceğinizi sanmıyorum, sadece tam olarak bağlı bir endeks G / Ç'nize) - daha sonra büyük silmeler veya destory zvol / havuzları sırasında bekletilirsiniz.