Qaysi proshivka versiyasi eng "to'g'ri" va "ishlaydigan"? Agar saqlash tizimi xatoliklarga chidamliligini 99,9999% kafolatlasa, bu uning dasturiy ta'minotni yangilamasdan ham uzluksiz ishlashini anglatadimi? Yoki, aksincha, maksimal nosozlikka chidamliligini olish uchun har doim eng so'nggi dasturiy ta'minotni o'rnatishingiz kerakmi? Bu savollarga tajribamiz asosida javob berishga harakat qilamiz.
Kichik kirish
Biz hammamiz tushunamizki, dasturiy ta'minotning har bir versiyasi, xoh u operatsion tizim bo'lsin, xoh qurilma drayveri, ko'pincha uskunaning xizmat qilish muddati tugaguniga qadar "paydo bo'lmasligi" yoki "ochiq" bo'lishi mumkin bo'lgan nuqsonlar/xatolar va boshqa "xususiyatlar" ni o'z ichiga oladi. faqat ma'lum sharoitlarda. Bunday nuanslarning soni va ahamiyati dasturiy ta'minotning murakkabligi (funktsionalligi) va uni ishlab chiqish jarayonida sinov sifatiga bog'liq.
Ko'pincha foydalanuvchilar "zavoddan proshivka" da qoladilar (mashhur "u ishlaydi, shuning uchun u bilan aralashmang") yoki har doim eng so'nggi versiyani o'rnatadi (ularning tushunishicha, eng so'nggisi eng ishlaydigan degan ma'noni anglatadi). Biz boshqacha yondashuvdan foydalanamiz - biz foydalanilgan hamma narsa uchun reliz yozuvlarini ko'rib chiqamiz uskunalar va har bir uskuna uchun tegishli proshivkani diqqat bilan tanlang.
Biz, ular aytganidek, tajriba bilan shunday xulosaga keldik. Ishlash misolimizdan foydalanib, agar siz dasturiy ta'minot yangilanishlari va tavsiflarini zudlik bilan kuzatib bormasangiz, nima uchun saqlash tizimlarining va'da qilingan 99,9999% ishonchliligi hech narsani anglatmasligini aytib beramiz. Bizning ishimiz har qanday sotuvchining saqlash tizimlari foydalanuvchilari uchun mos keladi, chunki shunga o'xshash vaziyat har qanday ishlab chiqaruvchining apparatida sodir bo'lishi mumkin.
Yangi saqlash tizimini tanlash
O'tgan yilning oxirida bizning infratuzilmamizga qiziqarli ma'lumotlarni saqlash tizimi qo'shildi: sotib olish paytida Storwize V5000e deb nomlangan IBM FlashSystem 5010 liniyasidan kichik model. Endi u FlashSystem 5010 nomi ostida sotilmoqda, lekin aslida u xuddi shu Spectrum Virtualize bilan bir xil apparat bazasi.
Aytgancha, yagona boshqaruv tizimining mavjudligi IBM FlashSystem o'rtasidagi asosiy farqdir. Yosh seriyalarning modellari uchun u samaraliroq modellardan deyarli farq qilmaydi. Muayyan modelni tanlash faqat tegishli apparat bazasini ta'minlaydi, uning xarakteristikalari u yoki bu funksionallikdan foydalanishga imkon beradi yoki yuqori darajadagi miqyosni ta'minlaydi. Dasturiy ta'minot apparatni aniqlaydi va ushbu platforma uchun zarur va etarli funktsiyalarni ta'minlaydi.
IBM FlashSystem 5010
5010 modelimiz haqida qisqacha. Bu boshlang'ich darajadagi ikki nazoratli blokli saqlash tizimi. U NLSAS, SAS, SSD disklarini joylashtirishi mumkin. Unda NVMe joylashuvi mavjud emas, chunki bu saqlash modeli NVMe drayverlarining ishlashini talab qilmaydigan muammolarni hal qilish uchun joylashtirilgan.
Saqlash tizimi arxiv ma'lumotlarini yoki tez-tez kirmaydigan ma'lumotlarni joylashtirish uchun sotib olingan. Shuning uchun, uning funksionalligining standart to'plami biz uchun etarli edi: Tiering (Easy Tier), Thin Provision. NLSAS disklarida 1000-2000 IOPS darajasidagi ishlash ham biz uchun juda qoniqarli edi.
Bizning tajribamiz - qanday qilib biz proshivkani o'z vaqtida yangilamadik
Endi dasturiy ta'minotni yangilashning o'zi haqida. Sotib olayotganda tizim allaqachon Spectrum Virtualize dasturining biroz eskirgan versiyasiga ega edi, xususan: 8.2.1.3.
Biz proshivka tavsiflarini o'rganib chiqdik va yangilashni rejalashtirdik 8.2.1.9. Agar biz biroz samaraliroq bo'lganimizda, bu maqola mavjud bo'lmagan bo'lardi - xato yangiroq proshivkada yuz bermagan bo'lardi. Biroq, ma'lum sabablarga ko'ra, ushbu tizimni yangilash kechiktirildi.
Natijada, yangilanishning biroz kechikishi havoladagi tavsifda bo'lgani kabi juda yoqimsiz rasmga olib keldi: .
Ha, ushbu versiyaning proshivkasida HU02104 (Authorized Program Analysis Report) deb nomlangan APAR tegishli edi. U quyidagicha ko'rinadi. Yuklanish ostida, ma'lum sharoitlarda, kesh to'lib keta boshlaydi, keyin tizim himoya rejimiga o'tadi, bunda hovuz uchun I/U ni o'chiradi. Bizning holatda, RAID 3 rejimida RAID guruhi uchun 6 ta diskni ajratib qo'yish kabi ko'rinardi.Ajratish 6 daqiqa davomida sodir bo'ladi. Keyinchalik, Hovuzdagi hajmlarga kirish tiklanadi.
Agar kimdir IBM Spectrum Virtualize kontekstida mantiqiy ob'ektlarning tuzilishi va nomlanishi bilan tanish bo'lmasa, men hozir qisqacha tushuntiraman.
Saqlash tizimining mantiqiy elementlarining tuzilishi
Disklar MDisk (Managed Disk) deb nomlangan guruhlarga yig'iladi. MDisk klassik RAID (0,1,10,5,6) yoki virtuallashtirilgan - DRAID (Distributed RAID) bo'lishi mumkin. DRAID dan foydalanish massiv unumdorligini oshirish imkonini beradi, chunki... Guruhdagi barcha disklar ishlatiladi va qayta qurish vaqti qisqaradi, chunki faqat ma'lum bloklarni qayta tiklash kerak bo'ladi va muvaffaqiyatsiz diskdagi barcha ma'lumotlar emas.
RAID-5 rejimida Distributed RAID (DRAID) dan foydalanganda ma'lumotlar bloklarini disklar bo'ylab taqsimlash.
Va bu diagramma bitta diskda ishlamay qolganda DRAID qayta qurish qanday ishlashi mantiqini ko'rsatadi:
Bitta disk ishlamay qolganda DRAID qayta qurish mantig'i
Keyinchalik, bir yoki bir nechta MDisklar Hovuz deb ataladigan narsani hosil qiladi. Xuddi shu hovuz ichida bir xil turdagi disklarda turli RAID/DRAID darajalariga ega MDisk-dan foydalanish tavsiya etilmaydi. Biz bunga chuqurroq kirmaymiz, chunki... buni keyingi maqolalardan birida yoritishni rejalashtirganmiz. Haqiqatan ham, Hovuz xostlarga u yoki bu blok kirish protokoli yordamida taqdim etiladigan hajmlarga bo'lingan.
Shunday qilib, biz tasvirlangan vaziyat natijasida APAR HU02104, uchta diskning mantiqiy ishdan chiqishi tufayli MDisk ishlashni to'xtatdi, bu esa, o'z navbatida, Hovuz va tegishli Volumes ishlamay qolishiga olib keldi.
Ushbu tizimlar juda aqlli bo'lgani uchun ular IBM Storage Insights bulutli monitoring tizimiga ulanishi mumkin, bu esa muammo yuzaga kelganda avtomatik ravishda IBM qo'llab-quvvatlash xizmatiga xizmat so'rovini yuboradi. Ilova yaratiladi va IBM mutaxassislari masofadan turib diagnostika o'tkazadilar va tizim foydalanuvchisi bilan bog'lanadilar.
Buning yordamida muammo juda tez hal qilindi va qo'llab-quvvatlash xizmatidan tizimimizni o'sha paytda allaqachon tuzatilgan 8.2.1.9 proshivka dasturiga yangilash bo'yicha tezkor tavsiya olindi. Tasdiqlaydi .
Natijalar va tavsiyalarimiz
Aytishlaricha, "hammasi yaxshi bo'ladi, hammasi yaxshi bo'ladi". Mikrodasturdagi xato jiddiy muammolarni keltirib chiqarmadi - serverlar imkon qadar tezroq va ma'lumotlarni yo'qotmasdan tiklandi. Ba'zi mijozlar virtual mashinalarni qayta ishga tushirishga majbur bo'lishdi, lekin umuman olganda biz ko'proq salbiy oqibatlarga tayyor edik, chunki biz har kuni barcha infratuzilma elementlari va mijoz mashinalarining zahira nusxalarini yaratamiz.
99,9999% va'da qilingan ishonchli tizimlar ham e'tibor va o'z vaqtida texnik xizmat ko'rsatishni talab qilishini tasdiqladik. Vaziyatga asoslanib, biz o'zimiz uchun bir qator xulosalar chiqardik va tavsiyalarimizni baham ko'ramiz:
-
Yangilanishlarning chiqarilishini kuzatish, potentsial muhim muammolarni tuzatish uchun Relizlar eslatmalarini o'rganish va rejalashtirilgan yangilanishlarni o'z vaqtida amalga oshirish juda muhimdir.
Bu tashkiliy va hatto juda aniq nuqta bo'lib, unga e'tibor qaratishning hojati yo'q. Biroq, bu "darajadagi zaminda" siz osongina qoqilishingiz mumkin. Darhaqiqat, yuqorida tavsiflangan muammolarni qo'shib qo'ydi. Yangilash qoidalarini tuzishda juda ehtiyot bo'ling va ularga rioya qilishni diqqat bilan kuzatib boring. Bu nuqta ko'proq "intizom" tushunchasi bilan bog'liq.
-
Tizimni eng so'nggi dasturiy ta'minot versiyasi bilan saqlash har doim yaxshiroqdir. Bundan tashqari, hozirgisi kattaroq raqamli belgiga ega emas, balki keyinroq chiqarilgan sanaga ega.
Masalan, IBM o'zining saqlash tizimlari uchun kamida ikkita dasturiy ta'minotni yangilab turadi. Ushbu yozish vaqtida bular 8.2 va 8.3. 8.2 uchun yangilanishlar oldinroq chiqadi. 8.3 uchun shunga o'xshash yangilanish odatda biroz kechikish bilan chiqariladi.
8.3 versiyasi bir qator funktsional afzalliklarga ega, masalan, bir yoki bir nechta yangi disklarni qo'shish orqali MDiskni (DRAID rejimida) kengaytirish imkoniyati (bu xususiyat 8.3.1 versiyasidan beri paydo bo'lgan). Bu juda oddiy funksionallik, ammo 8.2-da, afsuski, bunday xususiyat yo'q.
-
Agar biron sababga ko'ra yangilash imkoni bo'lmasa, Spectrum Virtualize dasturiy ta'minotining 8.2.1.9 va 8.3.1.0 versiyalaridan oldingi versiyalari uchun (yuqorida tavsiflangan xato tegishli bo'lsa), uning paydo bo'lish xavfini kamaytirish uchun IBM texnik yordami tavsiya qiladi. quyidagi rasmda ko'rsatilganidek, hovuz darajasida tizimning ishlashini cheklash (rasm GUIning ruslashtirilgan versiyasida olingan). 10000 IOPS qiymati misol sifatida ko'rsatilgan va tizimingizning xususiyatlariga ko'ra tanlangan.
IBM saqlash unumdorligini cheklash
-
Saqlash tizimlaridagi yukni to'g'ri hisoblash va ortiqcha yuklanishdan qochish kerak. Buni amalga oshirish uchun siz IBM o'lchamidan (agar unga kirish imkoningiz bo'lsa) yoki hamkorlar yordamidan yoki uchinchi tomon resurslaridan foydalanishingiz mumkin. Saqlash tizimidagi yuk profilini tushunish juda muhim, chunki MB/s va IOPSda ishlash kamida quyidagi parametrlarga qarab katta farq qiladi:
-
operatsiya turi: o'qish yoki yozish,
-
operatsiya blokining o'lchami,
-
umumiy kiritish-chiqarish oqimidagi o'qish va yozish operatsiyalarining ulushi.
Bundan tashqari, operatsiyalar tezligi ma'lumotlar bloklarini o'qish usuliga ta'sir qiladi: ketma-ket yoki tasodifiy tartibda. Ilova tomonida bir nechta ma'lumotlarga kirish operatsiyalarini bajarishda bog'liq operatsiyalar tushunchasi mavjud. Buni ham hisobga olish maqsadga muvofiqdir. Bularning barchasi operatsion tizimning ishlash hisoblagichlari, saqlash tizimi, serverlar/gipervisorlar ma'lumotlari to'plamini ko'rishga yordam beradi, shuningdek, ilovalar, ma'lumotlar bazasi va disk resurslarining boshqa "iste'molchilari" ning ishlash xususiyatlarini tushunishga yordam beradi.
-
-
Va nihoyat, zaxira nusxalari yangilangan va ishlayotganligiga ishonch hosil qiling. Zaxiralash jadvali biznes uchun maqbul RPO qiymatlari asosida tuzilgan bo'lishi kerak va qabul qilinadigan RTO qiymatini ta'minlash uchun zaxira nusxalarining yaxlitligini davriy tekshirish tekshirilishi kerak (bir nechta zaxira dasturiy ta'minot ishlab chiqaruvchilari o'z mahsulotlarida avtomatlashtirilgan tekshirishni amalga oshirgan).
Oxirigacha o'qiganingiz uchun rahmat.
Izohlarda savollaringiz va sharhlaringizga javob berishga tayyormiz. Shuningdek, unda biz muntazam aktsiyalarni o'tkazamiz (IaaS-da chegirmalar va VPS-da 100% gacha reklama kodlari uchun sovg'alar), qiziqarli yangiliklarni yozamiz va Habr blogida yangi maqolalarni e'lon qilamiz.
Manba: www.habr.com