Hangi donanım yazılımı sürümü en "doğru" ve "çalışıyor"? Bir depolama sistemi %99,9999 hata toleransını garanti ediyorsa bu, yazılım güncellemesi olmadan bile kesintisiz çalışacağı anlamına mı gelir? Veya tam tersine, maksimum hata toleransı elde etmek için her zaman en son ürün yazılımını mı yüklemelisiniz? Bu soruları deneyimlerimize dayanarak cevaplamaya çalışacağız.
Küçük giriş
İster bir işletim sistemi ister bir cihazın sürücüsü olsun, yazılımın her sürümünün genellikle kusurlar/hatalar ve ekipmanın hizmet ömrünün sonuna kadar "görünmeyebilecek" veya "açık" olabilecek diğer "özellikler" içerdiğini hepimiz anlıyoruz. yalnızca belirli koşullar altında. Bu tür nüansların sayısı ve önemi, yazılımın karmaşıklığına (işlevselliğine) ve geliştirme sırasındaki testlerin kalitesine bağlıdır.
Çoğu zaman, kullanıcılar "fabrikadan gelen donanım yazılımını" (ünlü "çalışıyor, bu yüzden onunla uğraşmayın") kullanmaya devam ederler veya her zaman en son sürümü yüklerler (onların anlayışına göre, en yenisi en çok çalışan anlamına gelir). Farklı bir yaklaşım kullanıyoruz; kullanılan her şeyin sürüm notlarına bakıyoruz ve her ekipman parçası için uygun donanım yazılımını dikkatli bir şekilde seçin.
Bu sonuca, dedikleri gibi, tecrübeyle ulaştık. Operasyon örneğimizi kullanarak, yazılım güncellemelerini ve açıklamalarını derhal izlemezseniz, depolama sistemlerinin vaat edilen %99,9999 güvenilirliğinin neden hiçbir anlam ifade etmediğini anlatacağız. Benzer bir durum herhangi bir üreticinin donanımında da meydana gelebileceğinden, bizim durumumuz herhangi bir satıcının depolama sistemi kullanıcıları için uygundur.
Yeni Bir Depolama Sistemi Seçmek
Geçen yılın sonunda altyapımıza ilginç bir veri depolama sistemi eklendi: IBM FlashSystem 5000 serisinden, satın alındığında Storwize V5010e olarak adlandırılan genç bir model. Artık FlashSystem 5010 adı altında satılıyor, ancak aslında içinde aynı Spectrum Virtualize bulunan aynı donanım tabanıdır.
Bu arada, birleşik bir yönetim sisteminin varlığı, IBM FlashSystem arasındaki temel farktır. Daha genç serilerin modelleri için pratikte daha üretken modellerden farklı değildir. Belirli bir modelin seçilmesi yalnızca, özellikleri şu veya bu işlevin kullanılmasını mümkün kılan veya daha yüksek düzeyde ölçeklenebilirlik sağlayan uygun donanım tabanını sağlar. Yazılım, donanımı tanımlar ve bu platform için gerekli ve yeterli işlevselliği sağlar.
IBM FlashSystem 5010
Kısaca 5010 modelimiz hakkında. Giriş seviyesi çift denetleyicili blok depolama sistemidir. NLSAS, SAS, SSD diskleri barındırabilir. Bu depolama modeli, NVMe sürücülerinin performansını gerektirmeyen sorunları çözecek şekilde konumlandırıldığından NVMe yerleşimi mevcut değildir.
Depolama sistemi, arşiv bilgilerinin veya sık erişilmeyen verilerin barındırılması için satın alındı. Bu nedenle, işlevselliğinin standart seti bizim için yeterliydi: Katmanlama (Easy Tier), Thin Provision. NLSAS disklerde 1000-2000 IOPS seviyesindeki performans da bizim açımızdan oldukça tatmin ediciydi.
Deneyimimiz - aygıt yazılımını nasıl zamanında güncellemediğimiz
Şimdi yazılım güncellemesinin kendisi hakkında. Satın alma sırasında sistem zaten Spectrum Virtualize yazılımının biraz eski bir sürümüne sahipti: 8.2.1.3
Firmware açıklamalarını inceledik ve bir güncelleme planladık. 8.2.1.9. Biraz daha verimli olsaydık, bu makale mevcut olmayacaktı; hata daha yeni bir aygıt yazılımında ortaya çıkmayacaktı. Ancak bazı nedenlerden dolayı bu sistemin güncellenmesi ertelendi.
Sonuç olarak, küçük bir güncelleme gecikmesi, bağlantıdaki açıklamada olduğu gibi son derece rahatsız edici bir tabloya yol açtı: .
Evet, bu sürümün donanım yazılımında APAR (Yetkili Program Analiz Raporu) HU02104 adı verilen rapor alakalıydı. Aşağıdaki gibi görünür. Yük altında, belirli koşullar altında önbellek taşmaya başlar ve ardından sistem, havuz için G/Ç'yi devre dışı bıraktığı koruyucu moda geçer. Bizim durumumuzda RAID 3 modunda bir RAID grubu için 6 diskin bağlantısının kesilmesi gibi görünüyordu, bağlantı kesilmesi 6 dakika sürüyor. Daha sonra Havuzdaki Birimlere erişim yeniden sağlanır.
IBM Spectrum Virtualize bağlamında mantıksal varlıkların yapısına ve adlandırılmasına aşina olmayan varsa, şimdi kısaca açıklayacağım.
Depolama sistemi mantıksal öğelerinin yapısı
Diskler MDisk (Yönetilen Disk) adı verilen gruplarda toplanır. MDisk, klasik bir RAID (0,1,10,5,6) veya sanallaştırılmış bir DRAID (Dağıtılmış RAID) olabilir. DRAID'i kullanmak dizinin performansını artırmanıza olanak tanır, çünkü... Gruptaki tüm diskler kullanılacak ve arızalı diskteki tüm verilerin değil, yalnızca belirli blokların geri yüklenmesi gerekeceğinden yeniden oluşturma süresi kısalacaktır.
RAID-5 modunda Dağıtılmış RAID (DRAID) kullanılırken veri bloklarının diskler arasında dağıtımı.
Bu diyagram, bir disk arızası durumunda DRAID yeniden yapılandırmasının nasıl çalıştığının mantığını gösterir:
Bir disk arızalandığında DRAID'in yeniden oluşturulmasının mantığı
Daha sonra bir veya daha fazla MDisk, Havuz adı verilen bir yapı oluşturur. Aynı havuz içerisinde, aynı türdeki disklerde farklı RAID/DRAID düzeylerine sahip MDisk'in kullanılması önerilmez. Bu konuya çok fazla girmeyeceğiz çünkü... Bunu aşağıdaki makalelerden birinde ele almayı planlıyoruz. Aslında Havuz, ana bilgisayarlara bir veya başka bir blok erişim protokolü kullanılarak sunulan Birimlere bölünmüştür.
Yani, yukarıda açıklanan durum sonucunda APAR HU02104Üç diskin mantıksal arızası nedeniyle MDisk'in işlevselliği sona erdi ve bu da Havuzun ve ilgili Birimlerin arızalanmasına neden oldu.
Bu sistemler oldukça akıllı olduğundan, bir sorun oluşması durumunda otomatik olarak IBM desteğine hizmet isteği gönderen IBM Storage Insights bulut tabanlı izleme sistemine bağlanabiliyorlar. Bir uygulama oluşturulur ve IBM uzmanları uzaktan tanılamayı gerçekleştirir ve sistem kullanıcısıyla iletişim kurar.
Bu sayede sorun oldukça hızlı bir şekilde çözüldü ve destek servisinden sistemimizi daha önce seçilen ve o sırada zaten düzeltilmiş olan donanım yazılımı 8.2.1.9'a güncellememiz için hızlı bir öneri alındı. Onaylıyor .
Sonuçlar ve önerilerimiz
Dediği gibi: "Sonu iyi olan her şey iyidir." Ürün yazılımındaki hata ciddi sorunlara neden olmadı - sunucular mümkün olan en kısa sürede ve veri kaybı olmadan geri yüklendi. Bazı istemciler sanal makineleri yeniden başlatmak zorunda kaldı ancak genel olarak tüm altyapı öğelerinin ve istemci makinelerin günlük yedeklerini aldığımız için daha olumsuz sonuçlara hazırlıklıydık.
%99,9999 oranında kullanılabilirlik vaat eden güvenilir sistemlerin bile dikkat ve zamanında bakım gerektirdiğine dair onay aldık. Duruma dayanarak kendimiz için bir takım sonuçlar çıkardık ve önerilerimizi paylaştık:
-
Güncellemelerin yayınlanmasını izlemek, potansiyel olarak kritik sorunların düzeltilmesi için Sürüm Notlarını incelemek ve planlanan güncellemeleri zamanında gerçekleştirmek zorunludur.
Bu, örgütsel ve hatta oldukça açık bir noktadır ve görünüşe göre odaklanmaya değmez. Ancak bu "düz zeminde" oldukça kolay tökezleyebilirsiniz. Aslında yukarıda anlattığımız sıkıntıları ekleyen de bu an oldu. Güncelleme düzenlemelerini hazırlarken çok dikkatli olun ve bunlara uyumu daha az dikkatli bir şekilde izleyin. Bu nokta daha çok “disiplin” kavramıyla ilgilidir.
-
Sistemi en son yazılım sürümünde tutmak her zaman daha iyidir. Üstelik mevcut olan, daha büyük bir sayısal değere sahip olan değil, daha sonraki bir çıkış tarihine sahip olanıdır.
Örneğin IBM, depolama sistemleri için en az iki yazılım sürümünü güncel tutuyor. Bu yazının yazıldığı sırada bunlar 8.2 ve 8.3'tü. 8.2 güncellemeleri daha erken çıkıyor. 8.3 için de benzer bir güncelleme genellikle hafif bir gecikmeyle yayınlanır.
Sürüm 8.3'ün bir dizi işlevsel avantajı vardır; örneğin, bir veya daha fazla yeni disk ekleyerek MDisk'i (DRAID modunda) genişletme yeteneği (bu özellik, sürüm 8.3.1'den beri ortaya çıkmıştır). Bu oldukça basit bir işlevsellik ama 8.2'de ne yazık ki böyle bir özellik yok.
-
Herhangi bir nedenden dolayı güncelleme mümkün değilse, Spectrum Virtualize yazılımının 8.2.1.9 ve 8.3.1.0 sürümlerinden önceki sürümleri için (yukarıda açıklanan hatanın ilgili olduğu durumlarda), bu durumun ortaya çıkma riskini azaltmak için IBM teknik desteği şunları önerir: aşağıdaki şekilde gösterildiği gibi sistem performansını havuz seviyesinde sınırlamak (resim GUI'nin Ruslaştırılmış versiyonunda çekilmiştir). 10000 IOPS değeri örnek olarak gösterilmiş olup sisteminizin özelliklerine göre seçilir.
IBM depolama performansını sınırlama
-
Depolama sistemlerindeki yükü doğru hesaplamak ve aşırı yüklemeden kaçınmak gerekir. Bunu yapmak için IBM boyutlayıcıyı (erişiminiz varsa) veya ortakların yardımını veya üçüncü taraf kaynaklarını kullanabilirsiniz. Depolama sistemindeki yük profilini anlamak zorunludur çünkü MB/sn ve IOPS cinsinden performans, en azından aşağıdaki parametrelere bağlı olarak büyük ölçüde değişiklik gösterir:
-
işlem türü: okuma veya yazma,
-
işlem bloğu boyutu,
-
toplam G/Ç akışındaki okuma ve yazma işlemlerinin yüzdesi.
Ayrıca işlemlerin hızı, veri bloklarının nasıl okunduğuna da bağlıdır: sıralı veya rastgele sırayla. Uygulama tarafında birden fazla veri erişim işlemi yapılırken bağımlı işlemler kavramı bulunmaktadır. Bunu da dikkate almanız önerilir. Tüm bunlar, işletim sisteminin, depolama sisteminin, sunucuların/hipervizörlerin performans sayaçlarından gelen verilerin tamamının görülmesinin yanı sıra uygulamaların, DBMS'lerin ve disk kaynaklarının diğer "tüketicilerinin" işletim özelliklerinin anlaşılmasına da yardımcı olabilir.
-
-
Son olarak, yedeklerinizin güncel ve çalışır durumda olduğundan emin olun. Yedekleme zamanlaması, işletme için kabul edilebilir RPO değerlerine göre yapılandırılmalı ve kabul edilebilir bir RTO değeri sağlamak için yedeklemelerin periyodik bütünlük kontrolleri doğrulanmalıdır (oldukça az sayıda yedekleme yazılımı satıcısı, ürünlerinde otomatik doğrulamayı uygulamıştır).
Sonuna kadar okuduğunuz için teşekkür ederiz.
Soru ve yorumlarınızı yorumlarda cevaplamaya hazırız. AyrıcaDüzenli promosyonlar düzenlediğimiz (IaaS'de indirimler ve VPS'de %100'e varan promosyon kodları için hediyeler), Habr blogunda ilginç haberler yazdığımız ve yeni makaleler duyurduğumuz.
Kaynak: habr.com