RAID-контроллерлер серверлерге: Smart Array, PERC, MegaRAID

Неліктен RAID-контроллерлерді салыстыру керек

RAID-контроллерді көбінесе «тек RAID жасайтын қорап» деп ойлайды. Шын мәнінде, дәл сол контроллер шешеді: жазбалар дискке қалай түседі, кэш қалай жұмыс істейді, қуат өшкенде не болады және массивті қалпына келтіру қанша уақыт алады. Сондықтан контроллерлерді процессорлар немесе дискалар сияқты мұқият салыстырған жөн.

Мәселелер әдетте тестілерде емес, жүктеме нақты болғаннан кейін көрінеді: виртуалды машиналар жазу кешігулері себепті «жабысып» қалуы мүмкін, дерекқорлар пиковый уақытта IOPS жоғалтады және кезекке тіреледі, rebuild тым ұзақ жүріп, өнімділікті «жеп» қояды. Тағы бір тәуекел — қуат өшу: егер кэш дұрыс қорғалмаса, соңғы жазбалардың бір бөлігін жоғалтуға болады.

Тіпті бірдей дискылар әртүрлі контроллерлерде әрқалай көрінеді. Кэштеу алгоритмдері, кэш көлемі мен түрі, жазу саясаты (write-through немесе write-back), кезекпен жұмыс істеу және прошивкадағы әдепкі мәндер өзгереді. Бір контроллерде сол SSD жылдам және тұрақты кешігулер көрсетсе, екіншісінде аралас жүктемеде (ВМ + БД) «тартылып» көрінуі мүмкін.

Көп жағдайда маңызды үш нәрсе бар: болжалдығы (тұрақты кешігулер), жазу жылдамдығы (журналдар мен кіші блоктар үшін) және сенімділік, соның ішінде кэш қорғанысын қызмет көрсету. Салыстыру сізге не алғаныңызды түсінуге көмектеседі: синтетикалық максимум ба, әлде жұма кешінде тосын сый болмайтын мінез-құлық па.

Жауапкершілік шекарасын есте ұстаңыз. Контроллер RAID-логикасы, кэш және жазу қауіпсіздігі үшін жауапты. Бірақ нәтиже дискылардан, RAID деңгейінен, ОС пен гипервизор баптауларынан, файлдық жүйеден және дерекқор параметрлерінен де тәуелді. Виртуализация мен бір‑екі дерекқоры бар стойкада кэш саясаты дұрыс болмаса, жылдам дискыларды тұрақты микрофриз көзіне айналдыру оңай, тіпті «темір» формальды түрде бірдей болса да.

Smart Array, PERC, MegaRAID: бұл не және қай жерде кездеседі

Қарапайым тілмен айтқанда, осы үш отбасы бір міндетті шешеді: сервердегі дискыларды басқарып, қажетті RAID, болжамды жылдамдық пен деректерді қорғауды алу. Айырмашылық көбінесе басқару, опциялар жиынтығы және жүзеге асырудың детальдарында.

Smart Array көбінесе HPE серверлерінде, PERC — Dell-де, MegaRAID — Broadcom шешімдерінде және әртүрлі OEM-та бар. Нәтижеге әсер ететін типтік стек: контроллер (немесе HBA/passthrough), оның кэші, кэш қорғаныс модулі, бэкплейн (SAS/SATA, кейде экспандермен) және өздері дискылар (HDD/SSD, SAS/SATA; NVMe әдетте бөлек схема ретінде жүреді).

Араласпауы тиіс терминдер:

• write-back және write-through: кэш арқылы жазу және тікелей дискке жазу;
• read-ahead: алдын ала оқу, әрдайым пайдалы емес;
• stripe (полоса өлшемі): деректер дискыларға қалай "кесілетіні";
• patrol read/consistency check: фондық тексерістер, жүктемеге әсер етуі мүмкін.

Кез келген салыстырудың шектеуі қарапайым: бір контроллер әртүрлі прошивкада, драйверде, дискылар мен баптауларда әрқалай мінез көрсете алады. Сондықтан қорытындыны нақты модельге, прошивка нұсқасына және сценарийге (виртуализация, дерекқор, файл сервер немесе аралас жүктеме) байлаңыз.

Контроллер кэштері: жылдамдық пен кешігулерге әсері

RAID-контроллер кэші — картада орналасқан жылдам жады, ол дискілер бос болғанша кейбір операцияларды өзінде ұстайды. Негізгі пайда көбінесе жазуға байланысты: кэш шоқыларды тегістейді, кешігулерді азайтады және сервердің кіші синхронды операцияларда «кәсіптеуін» болдырмайды.

Негізгі қосқыш — жазу режимі.

write-back режимінде контроллер жазбаны дербес кэшке түскеннен кейін растауды береді және кейінірек оларды дискке итереді. Бұл виртуализация мен дерекқорларда жылдамдықты көтеріп, кешігулерді азайтады, бірақ қуат өшкен жағдайда кэшті сақтай алатын қорғаныс қажет.

write-through режимінде растау тек дискіге жазылғаннан кейін беріледі. Бұл жылдамырақ етпейді, бірақ кэшті жоғалту қаупін азайтады.

Практикалық бағдар:

• Write-back — егер кэш қорғалған болса, ВМ, дерекқорлар мен көп кішкентай жазбалары бар файл қызметтері үшін;
• Write-through — егер кэш қорғанысы жоқ/бұзылған болса немесе диагностика кезінде тұрақсыздық болса.

Кэш көлемі маңызды, бірақ «сиқыр емес». Үлкен кэш бірдей емес жүктемелерді жақсы ұстайды: ондаған ВМ бір уақытта лог жазғанда, деректер жаңартқанда, snapshot жасағанда көмектеседі. Дегенмен типтік дерекқор үшін кэш дискі жүйесін емдемейді: ол тек кезекті секундтармен кейінге қалдыруы мүмкін.

Read-ahead туралы бөлек. Алдын ала оқу тізбекті қолжетімділік кезінде пайдалы (есептер, бэкаптар). VM мен OLTP-типтегі дерекқордағы кездейсоқ профильде ол кейде кэшті қажетсіз блоктармен толтырып, зиян келтіруі мүмкін. Көп жағдайда қауіпсіз нұсқа — adaptive, контроллер тізбекті және кездейсоқ қатынауды ажыратуға тырысады.

Батарея және кэш қорғаныс модулі: тәуекелдер мен қызмет көрсету

Write-back режимінде кэш жазуды жылдамдатады, өйткені деректер алдымен кэшке түсіп, кейін дискке жазылады. Шарт біреу: контроллер кенет қуат өшкенде кэштегі деректерді сақтай білуі керек. Мұның үшін батарея немесе суперконденсатор сияқты кэш қорғаныс модулі қажет.

Атаулары шатастыруы оңай.

BBU (battery backup unit) — кэшті «тірі» ұстауға арналған батарея.

FBWC (flash-backed write cache) — HPE-де қуат жоғалғанда кэштегі деректер флешке сақталады, ал сол «ағысты» жүзеге асыруға батарея немесе суперконденсатор энергия береді.

CacheVault Broadcom MegaRAID пен Dell PERC-та әдетте суперконденсатор + флеш модулі түрінде ұйымдастырылған, бұл кэшті ұзақ батареяға тәуелсіз сақтауға көмектеседі.

Мұнда әлсіз тұсы — жылдамдық емес, қызмет көрсету. Батареялар уақыт өте келе сыйымдылығын жоғалтады. Суперконденсаторлар әдетте ұзағырақ өмір сүреді, бірақ олар да тозып, істен шығуы мүмкін. Эксплуатацияда бұл қатты білінеді: контроллер кэш қорғанысын сенімсіз деп есептейді.

Модульді тексеру қажеттігін көрсететін белгілер:

• мониторингте немесе логтарда Battery/Capacitor failed, Cache protection not present, Cache disabled сияқты хабарламалар;
• кэш өшірілген немесе Degraded күйінде көрсетіледі;
• контроллер write-through-қа ауысады және кешігулер кенет өседі;
• қайта жүктегеннен кейін инициализация уақыты ұлғаяды, кэш сақталғаны туралы ескертулер көрінеді.

Неліктен write-through қосылады? Бұл қорғаныс режимі: егер кэш сақтайтын құрал болмаса, жазулар тікелей дискіге барады, осылайша деректерді жоғалту тәуекелін азайтады. Виртуализация мен дерекқорларда мұндай ауысу әдетте бірден байқалады.

Практика қарапайым: әр жоспарлы қызмет көрсету кезінде кэш қорғанысын тексеріңіз, хабарландыруларды қадағалаңыз және модульді апат болғанға дейін емес, регламент бойынша ауыстырыңыз. Егер серверлер интегратор арқылы жеткізіліп, іске қосылса (мысалы, GSE.kz жобаларында), кэш пен оның қорғанысын қабылдау актісінде дереу қалдырып қою ыңғайлы болады — бұл өндірістік жүктеме астында себеп іздеуден құтқарады.

RAID деңгейлері және ВМ мен дерекқорларға арналған негізгі шешімдер

RAID таңдау "үлкен цифр жақсы" туралы емес. Виртуализация мен дерекқорлар үшін жазу кешігулері, болжамдылық және массивтің қалпына келу кезіндегі мінез-құлық маңызды. Дерекқорлар үшін журналдар (write-ahead log) және синхронды fsync өте маңызды: кез келген қосымша кешігу бірден көрінеді.

Қандай жағдайларда не таңдайды және неге

Практикада жиі таңдайтындар:

• RAID10 — ВМ мен «тірі» дерекқорлар үшін: жазу кешігулері төмен, қалпына келтіру жылдам, тосынсыйлары аз;
• RAID6 — үлкен файлдық сақтаулар мен бэкаптар үшін: дискіні үнемдейді, бірақ жазулар мен rebuild әдетте ауыр;
• RAID5 — егер жүктеме негізінен оқуға бағытталған және жазу/қалпына келтіру компромистерін түсінсеңіз.

RAID10 жазу кешігулері бойынша әдетте ұтады. RAID5/6 қалпына келтіру кезінде қосымша диск жүктемесі тудырады, ал тәуекел терезесі ұлғаяды: қалпына келтіру неғұрлым ұзақ болса, екінші ақау ықтималдығы соғұрлым көп (әсіресе үлкен HDD-лар үшін).

Hot spare және stripe size

Hot spare маңызды, егер тоқтау қабылданбайтын болса: контроллер дереу rebuild бастайды. Global spare бірнеше массив үшін икемді, Dedicated spare бір маңызды массив үшін логичнее болады (мысалы, дерекқорға арналған), себебі артық диск басқа пулға кетпеуі тиіс.

Stripe size-ты қарапайым ереже бойынша таңдаңыз: кіші операциялар көп болса, полоса аз болуы керек. Практикалық бағдарлар:

• 64K–128K — виртуализация және аралас жүктемелер үшін;
• 128K–256K — тізбекті ағымдар (бэкаптар, үлкен файлдар) үшін.

Күмансасыңыз келсе, 128K-пен бастап, тесттік ВМ мен тесттік БД-да кешігулерді тексеріңіз.

Виртуализация және дерекқорларға қадамдық баптау

HPE Smart Array, Dell PERC және Broadcom MegaRAID-та меню тармақтары ұқсас, бірақ опция атаулары өзгеше болуы мүмкін. Логика бір: жүктемелерді бөліп, кэш жазуды тек қауіпсіз жерде қосу.

Баптау алдында контроллер режимін (RAID керек пе), контроллер мен бэкплейн прошивкаларының өзекті нұсқаларын, дискылардың үйлесімділігін, кэш қорғанысының (BBU/CacheVault/FBWC) дұрыстығын, дұрыс драйверлер мен хосттағы мониторинг утилиталарын тексеріңіз.

Кейін әрекет ету қадамдары.

Алдымен әр түрлі жүктемелерге арналған массивтер құрыңыз. Дерекқорға дербес диск тобы бөлген тиімді, ал ВМ-дерге жалпы пул бөлек ұстаңыз. Мысалы: дерекқорға — SSD-те RAID10 (төмен кешігулер), ВМ сақтау үшін — RAID10 немесе талапқа қарай RAID6.

Содан кейін жазу саясатын орнатыңыз. Виртуализация мен дерекқорлар үшін write-back жиі қажет, бірақ тек кэш қорғанысы дұрыс болған кезде. Егер батарея немесе модуль разрядталған болса, контроллер көбіне write-through-қа ауысады және өнімділік кенет төмендейді — бұл алдын ала көріп алған дұрыс.

Одан кейін оқу параметрлерін тексеріңіз. Read-ahead тізбекті операцияларға пайдалы (бэкаптар), бірақ дерекқор кездейсоқ оқуларында зиян келтіруі мүмкін. Егер I/O policy таңдауға мүмкіндік болса, дерекқор үшін төмен кешігуді басым ететін режимді, файлдық жүктемелер үшін — өткізу қабілеттілігін басым ететін режимді таңдаңыз.

Финалдық блок — қызмет көрсету және бақылау: init-ті тез немесе толық сіздің окнчанызға сай таңдаңыз, consistency check (patrol read) жүйесін белсенділеңіз, деградация, диск қатесі және кэш статусы туралы ескертулер орнатыңыз. Содан кейін қысқа тест жасаңыз: алдымен ВМ жүктемесін қосып, кейін БД жүктемесін іске қосып, кешігулерді салыстырыңыз.

Прошивка, драйверлер және мониторинг: мәселені кеш байқамау үшін

Прошивка мен драйвер жұбы маңызды

Контроллердер жаңартудан кейін әртүрлі мінез көрсете алады. Типтік қате: контроллер прошивкасын жаңартқанмен, ОС немесе гипервизордағы драйверді жаңартпау (немесе керісінше). Нәтижесінде күтпеген кешігулер, жалған ескертулер, кэшпен мәселелер немесе кенет реконструкциялар пайда болуы мүмкін.

Жаңартудан бұрын нақты комбинацияны тексеріңіз: контроллер моделі, прошивка нұсқасы, драйвер нұсқасы және гипервизор/ОС нұсқасы (мысалы, ESXi, Windows Server, Linux). Өндірістік ортада терезе жоспарлап, оралу жоспарын сақтаңыз.

Жұмыс уақытында массивті тексерулер жүргізу

Patrol read және consistency check әлсіз дискіні ерте тауып, апатқа дейінгі қателіктерді көрсетеді. Бірақ олар көп деректер оқып, қосымша жүктеме тудырады. Оларды түнгі уақытта немесе демалыс күндерінде жоспарлаңыз; жоғары жүктелетін дерекқорларда жиілігін азайту керек. Қосқаннан кейін кешігулер қалай өзгергенін бақылаңыз.

Rebuild өнімділікті төмендетеді. Оны қызмет көрсету терезесінде өткізу, rebuild приоритетін және фондық операцияларға шектеу қою, hot spare ұстау және диск алмауды кейінге қалдырмау — тез өтуге көмектеседі.

Мониторингте тек «OK/Degraded» емес, жүктеме астындағы мінезді қараңыз. Міндетті көрсеткіштер: оқу/жазу latency (орташа және шыңдар), queue depth, кэш режимі (write-back немесе write-through), диск қатесі (media errors, timeouts, predictive failure), сондай-ақ rebuild, деградация және кэш/батарея мәселелері туралы оқиғалар.

Тағы кездесетін қателіктер және тұзақтар

Үлкен мәселелер көбіне контроллер моделінде емес, сатып алу мен баптау кезіндегі кішкентай шешімдерде жатыр.

Қауіпті кэш баптаулары

Жылдамдық үшін write-back-ты қосу, бірақ кэш қорғанысын дұрыстап орнатпау — типтік қате. Егер BBU немесе суперконденсатор модулі бұзылған, жалған не қосылмаған болса, қуат жоғалғанда соңғы жазбаларды жоғалтуға болады. Ереже: контроллер кэш қорғанысын «жақсы» деп көрсетпейінше, write-back қоспаңыз.

Екінші тұзақ — кэш қорғанысы деградациясында не болатынын тексермеу. Көп контроллерлер автоматты түрде write-through-қа ауысады, сонда өнімділік кенет және күтпеген түрде құлдырайды.

Дискылар мен массивтер: «шамамен бірдей» болғанда

Әртүрлі модельдер, прошивкалар немесе партиялардан дискыларды араластырған кезде өнімділіктің тұрақсыздығы пайда болады: бүгін барлығы жылдам, ертең кейбіреулері кідірістер бере бастайды. Бұл виртуализация мен дерекқорларда, байт/сектормен емес, кешігулер мен тұрақтылық маңызды болғанда анық көрінеді.

Тағы бір қасірет — бір үлкен RAID5/6-ны «бәріне» қолдану: гипервизор, ВМ сақтау және дерекқор журналдары. Фондық операциялар, rebuild және жазу шыңдары бәріне әсер етеді. Мүмкіндік болса, жүктемелерді бөліп, RAID-ты IOPS профиліне сай таңдаңыз.

Жүктеуден бұрын кем дегенде үш нәрсені тексеріңіз: кэш қорғанысы дұрыс па және write-back оның статусы бойынша қолмен қосылмаған ба; дискылар бір класс па және аралас үлгілер жоқ па; ВМ мен дерекқорлар бір томда кездейсоқ жатпаған ба.

Ұмытылатын мониторинг пен қызмет көрсету

Тамаша темір де деградацияны пайдаланушылардан бұрын білмесе көмектеспейді. Деградация, диск қателері, кэш және батарея статусы туралы ескертулер орнатыңыз және олардың нақты жететініне көз жеткізіңіз.

Patrol read пен rebuild-ты прайм-таймға қоймаңыз. VDI мен кіші дерекқоры бар стойкада қызмет көрсету жұмыс уақытында ВМ-лерге «фриз» береді. Интеграциялық жобаларда (соның ішінде GSE.kz) мұндай жұмыстар әдетте түнгі немесе демалыс терезесіне жылжытылады және қызмет көрсету терезесі құжатталады.

Жұмысқа енгізу алдындағы жылдам чек-лист

Жұмысқа шығар алдында контроллер дискыларды көріп қана қоймай, қауіпсіз режимде екеніне көз жеткізіңіз.

Бастау үшін кэш қорғанысын тексеріңіз: BBU/CacheVault/FBWC бар ма және олардың жағдайы қандай. «OK» статусы қалыпты. «Learn» — оқыту режимі (контроллер уақытша кейбір режимдерді шектеуі мүмкін). «Replace» немесе температура/сыйымдылық бойынша қателер — модульді ауыстыруға себеп.

Одан әрі жазу саясатын тексеріңіз. Write-back жылдам, бірақ оны кэш қорғанысы дұрыспағанда қосуға болмайды. Қорғаныс қалыпты болмаса, қауіпсіздігі үшін write-through қолдану дұрыс, тіпті тесттер төмен өнімділікті көрсетсе де.

Қысқа алдын ала тізім:

• жазу режимі кэш қорғанысының күйіне сәйкес келеді;
• hot spare орнатылған және дискілерді ауыстыру процесі анық (кім, қанша сағат, қайда қор);
• rebuild пен тексерістердің кестесі шың уақытқа түсіп тұрмайды;
• массив құрамы мен дискілердің орны тіркелген;
• ескертулер тесттік оқиғамен тексерілген.

Жұмысқа дейінгі практикалық тест жиі өзіне ақтайды: қауіпсіз уақытта бір дискіні шығарып, массив деградацияға өтетінін, ескертудің келетінін, rebuild басталатынын және кешігулер критикалық болмайтынын тексеріңіз. Осындай сынақтар нақты істен бұрын мәселелерді көрсетеді.

Мысал сценарий: бір стойкада виртуализация және дерекқор

Офистік немесе шағын ЦОД-дағы стойканы елестетіңіз: екі физикалық хост виртуализацияға және бір маңызды ВМ дерекқормен (SQL Server немесе PostgreSQL). Күндіз көптеген кіші операциялар (есеп, есептер), түнде бэкаптар мен пакет тапсырмалары жүреді. Мұндай жағдайда маңыздысы — тесттердегі "жылдамдық" емес, тұрақты кешігулер мен айқын қызмет көрсету.

Массивтерді бөліп алу бәрінің бір-біріне кедергі келтірмеуіне көмектеседі. Жиі қолданылатын схема:

• ОС/гипервизор: 2 SSD-тен RAID1;
• ВМ-дер үшін Datastore: RAID10 (SSD немесе жылдам SAS);
• Дерекқор: бөлек массив;
• Дерекқор үшін: деректер RAID10-да, журналдар (log/WAL) бөлек RAID1 немесе RAID10-да, бэкаптар бөлек томда немесе сыртқы сақтау жүйесінде.

Негізгі мақсат — тұрақты кешігулер. Ол үшін кэш әдетте write-back режимінде жұмыс істеуі керек, бірақ тек кэш қорғанысы дұрыс болса. Қорғаныс жоқ немесе деградацияда болса, write-through ұстау қауіпсіз — растаулы жазбаларды кенет өшіру кезінде жоғалтудан лучше сақтайды.

Оқу үшін көбіне adaptive read-ahead жарайды. Дерекқор үшін агрессивті read-ahead зиян болуы мүмкін: сұраныстар көп жағдайда кездейсоқ, және артық оқу кезекке кедергі келтіруі мүмкін. ВМ сақтау үшін ол тізбекті операцияларда пайдалы болуы ықтимал, бірақ шешімді мегабайт/сек бойынша емес, кешігулер бойынша тексеріңіз.

Қызмет көрсету кестесін алдын ала жасаңыз: тоқсан сайын кэш қорғанысын тексеру және қатеңің есебі, айына бір рет patrol read/consistency check келісілген терезеде, сондай-ақ 1–2 қосалқы диск сол модельден және сыйымдылықтан сақтау.

Келесі қадамдар: қалай таңдап, сатып алудан бұрын тексеруге

Контроллерді бөлек тәуекел орталығы ретінде қараңыз. HPE Smart Array, Dell PERC және Broadcom MegaRAID атаулары ұқсас көрінуі мүмкін, бірақ нақты конфигурация ерекшеленеді: кэш көлемі, оның қорғалуының түрі, жұмыс режимдерін қолдау және кейде функциялар бойынша шектеулер.

Бірінші қадам — сіз не сатып алып жатқаныңызды нақтылау: сервер емес, контроллердің нақты моделі мен опциялары. Содан кейін бірнеше сұрақ қою уақытты үнемдейді: кэш көлемі қандай және қалай қорғалған, кэш қорғанысын қалай қызметтеу және деградацияны қалай анықтау, pass-through/HBA сияқты қажетті режимдер бар ма, сіздің ОС/гипервизор нұсқасымен үйлесімділігі расталған ба, қандай дискылар жоспарлануда және тексерілген модельдер тізімі бар ма.

Егер стенд немесе пилот бар болса, тек жылдамдықты ғана емес, проблемалар кезіндегі мінез-құлықты да тесттеңіз: өз профиліңіз бойынша latency өлшеңіз (ВМ миксі және бөлек БД профилі) және rebuild жүргізіңіз. Маңыздысы — кешігулердің қаншалықты өсетіні және екінші деградация кезінде не болатынын түсіну.

Қажет болса, интеграторды жобалау кезеңінен бастап тартыңыз. Қазақстанда GSE.kz, өндіруші және жүйелік интегратор ретінде, үйлесімділікті тексеріп, жүктеме профиліне сай конфигурация таңдауда және қызмет көрсетуді (кэш қорғаныс модульдері мен қосалқы дискыларды қоса алғанда) алдын ала жоспарлауда көмектеседі, осылайша барлық мәселені өндірісте шешудің қажеті болмайды.