Сервер стресс-тестін 24 сағатта қалай өткізу керек

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

Қабылдау кезіндегі негізгі қате «әлсіз» утилитаны таңдаудан туындамайды. Инженерлер жүктемені іске қосып, CPU көрсеткіші 100% болғанын көреді де, бірнеше сағаттан соң серверді жарамды деп жариялайды. Жүктелу пайызы машиналық қателер, ECC түзетулері, жазба тұтастығы, троттлинг немесе қуат желісінің біреуінің істен шығуы туралы ештеңе айтпайды. Сынақтың бастапқы күй суреті, уақыт бойынша телеметриясы және нақты ауытқуды қайта тексеруге не құрамдасты ауыстыруға жіберетін ережесі болғанда ғана мәні бар.

Толық тексеруді 24 сағатқа қалай сыйғызуға болады

Бір жүктемені мүмкіндігінше ұзақ ұстаудың орнына, тәулік ішінде әртүрлі жұмыс режимдерін жасап, күмәнді сәтті қайталауға уақыт қалдыру керек. Мен қолданатын кесте мынадай:

1. 0-1 сағат: жинақтама мен микробағдарламаларды салыстыру, BMC, SMART, EDAC журналдарының, температуралардың, желдеткіш айналымдарының және қуат блоктары көрсеткіштерінің бастапқы күйін жазу.
2. 1-5 сағат: алгоритмдерді қысқа аралықпен ауыстыратын есептеу жүктемесі, одан кейін CPU мен жадқа бірлескен жүктеме беру.
3. 5-11 сағат: ECC пен жүйелік журналды бақылай отырып, қолжетімді RAM көлемінің бәрін тексеру.
4. 11-18 сағат: әр жинақтауышты алдымен оқу арқылы, содан соң қайта жазуға рұқсат етілген дискілерде тексеру үлгісін жазу арқылы сынау.
5. 18-22 сағат: CPU, RAM және дискілерге бір уақытта жүктеме беріп, температураны, жиілікті, желдеткіштерді және қуатты бақылау.
6. 22-24 сағат: қуат резервін басқарылатын тәсілмен тексеру, серверді салқындату, күмәнді тестіні қайталау және журналдардың соңғы күйін жазу.

Бұл кесте барлық сервер бірдей операция санын орындауы керек дегенді білдірмейді. RAM көлемі үлкен әрі ондаған дискісі бар екі процессорлы құрылғы әр жад ұяшығы мен диск секторын толық айналып үлгермеуі мүмкін. Ондай жағдайда тұтастық, контроллер қателері және бірлескен шекті жүктеме басымдық алады. Нақты тексерілген дерек көлемін есепке міндетті түрде енгізіңіз. Тексерілген байт саны көрсетілмеген «жад тексерілді» деген тіркес әдістемедегі олқылықты жасырады.

Іске қоспас бұрын төрт шектеуді анықтаңыз. Біріншісі, жинақтауыштардағы деректерді жоюға бола ма. Екіншісі, алаң резервтік қуат блоктарының біреуін ажыратуға рұқсат ете ме. Үшіншісі, сервер кірісіндегі ауа температурасы қандай. Төртіншісі, BIOS, BMC, контроллер және диск микробағдарламаларының қай нұсқалары жеткізуге бекітілген. Жауаптардың біреуі белгісіз болса, оны сынақ бағдарламасындағы ерекшелік ретінде жазыңыз. Дискіні бұзатын тестіні жай оқумен үнсіз ауыстырып, екі режимді тең деп көрсетуге болмайды.

Серверді кейін жұмыс істейтін жинақтамасында тексеріңіз: дәл сол жад модульдері, HBA немесе RAID контроллері, жинақтауыштар, желілік карталар, қуат блоктары және BIOS профилі болуы керек. Тестіден кейін DIMM орнын ауыстыру нақты жад арнасы бойынша қорытындыны жарамсыз етеді. Тестіден кейін микробағдарламаны жаңартсаңыз, кемінде қысқа қайталау қажет, өйткені қуатты басқару, желдеткіштер, жадты үйрету және қателерді өңдеу өзгеруі мүмкін.

Уақыттың бәрін құрал орнатуға жұмсамаңыз. Жүктеу бейнесін, пакеттерді, job-файлдарды және метрика жинау скриптін дәл сол архитектурадағы құрылғыда алдын ала дайындаңыз. Бейне BMC, RAID контроллерін, NVMe және EDAC жүйесін көретінін, ал жүйелік уақыт жұмыс желісінсіз синхрондалатынын тексеріңіз. Оқшауланған ортада репозиторий болмауы мүмкін, сонда қабылдаудың төрт сағаты тәуелділіктерді іздеуге кетеді. Утилита нұсқаларын да есепке енгізіңіз: smartctl мен stress-ng шығарылымдары жаңа құрылғылар мен датчиктерді әртүрлі таниды.

Бастапқы күй жаңа ақауды ескі жазбадан ажыратады

Жүктеме бермей тұрып сервер күйін сақтап, сынақтан кейін әр есептегіш өсімін есептей алатындай етіңіз. Бастапқы мәнсіз абсолют қате саны жиі жаңылыстырады. SEL ішінде жинау кезінде ажыратылған желдеткіштен туған оқиға қалуы мүмкін, ал NVMe Error Information есептегішінде тасымалдағыштың бүлінуіне қатысы жоқ жазбалар кездеседі. Шешімге сіздің тестіңіз кезінде пайда болған жаңа жазба, оның түрі және жүктемемен байланысы негіз болуы керек.

Құрамдастардың сериялық нөмірлері мен физикалық орнын тіркеңіз. DIMM үшін сокет, арна және слот байланысы, диск үшін ұя мен контроллер идентификаторы, қуат блогы үшін PSU1 немесе PSU2 орны қажет. Бір lshw суреті бұл картаны алмастырмайды. Операциялық жүйе құрылғыны көрсеткенімен, техник ақаулы бөлшекті табатын физикалық мекенжайды әрдайым бермейді.

Linux жүйесіндегі ең аз бастапқы деректерді мына командалармен жинауға болады:

ipmitool sensor list
ipmitool sel elist
smartctl -x /dev/sda
smartctl -x /dev/nvme0
journalctl -k -b

ipmitool sel elist қысқа SEL тізімінен пайдалырақ, өйткені кеңейтілген нәтиже оқиғаны Sensor Data Record жазбасымен салыстырып, датчиктің атын береді. IPMItool нұсқаулығында elist режимі дәл осылай сипатталған. Бастапқы нәтижені, BMC уақытын және жүйелік уақытты сақтаңыз. Сағаттар сәйкес келмесе, «алдымен қызып кетті, кейін қайта жүктелді» деген реттілікті керісінше оқып қалу оңай.

ECC үшін сынаққа дейін және кейін EDAC есептегіштерін сақтаңыз немесе rasdaemon арқылы оқиғаларды жинаңыз. Linux ядросының құжаттамасы corrected, uncorrected, deferred және fatal қателерін бөлек қарайды. Бұлар бір оқиғаның төрт атауы емес. Corrected error ECC деректерді түзеткенін білдіреді, ал uncorrected error жүйе жұмысын жалғастырса да, қатені түзету мүмкін болмағанын көрсетеді. Deferred error кейін бағдарлама зақым белгісі қойылған жад аймағына жүгінгенде көрінуі мүмкін. Сондықтан есептегі жалпы «hardware errors» саны пайдасыз, санаттарды бөлек сақтау керек.

Бастапқы күйді сақтамай тұрып SEL мен SMART деректерін тазаламаңыз. Сурет сақталған соң, рәсім таза сынақ терезесін талап етсе және тапсырыс беруші саясаты рұқсат етсе, SEL журналын тазалауға болады. Онда есепке екі файл да кіруі керек: тазалауға дейінгі журнал және сынақ журналы. SMART есептегіштері әдетте нөлге түсірілмейді, сондықтан олардың айырмасын есептеңіз.

Бағдарламалық қайта жүктеумен шектелмей, бір рет қуатты толық өшіріп іске қосыңыз. Қуат түгел алынғанда BMC, контроллерлер мен жинақтауыштар басқа инициализация жолынан өтеді, жад қайта үйретіледі, резервтік блоктар жүктемені бөлу режимін келіседі. POST тоқтап қалуы, арнаның жоғалуы, дискінің ұзақ іске қосылуы, кеш батареясының немесе суперконденсатордың қатесі осы кезде көрінеді. Рәсім қуатты толық алуға тыйым салса, cold boot тексерілмегенін жазыңыз. Warm reboot сәтті өтуі бұл тәуекелді жаппайды.

CPU датчигін ғана емес, сервер кірісіндегі ауа температурасын жазыңыз. Ашық есік жанында 18 °C кезінде тексерілген серверді тығыз стойкада 27 °C кезінде тұрған сервермен әділ салыстыруға болмайды. Жоғарғы шектерді нақты платформа мен процессордың құжаттамасынан алыңыз. «80 °C-тан төмен болса жеткілікті» деген әмбебап сан дұрыс емес: датчиктердің орны, рұқсат етілген шегі және троттлинг логикасы әртүрлі.

Процессорды қателер мен тұрақты жиілік бойынша бағалаңыз

Жарамды CPU әртүрлі есептеу жүктемесін MCE, қатып қалу және тексеру қатесінсіз аяқтап, жылулық тепе-теңдік орнағаннан кейін күтілетін жиілік режимін ұстауы керек. Бір алгоритм орындау блоктарын екіншісіне ұқсамай жүктейді. Бірдей бүтін сан операцияларын он сағат орындау матрица, бүтін сан, жылжымалы нүкте және кешті қамтитын бірнеше режимнен аз мәлімет береді.

Алғашқы кезеңде мен stress-ng қолданамын. Оның нұсқаулығында verify режимі осы мүмкіндікті қолдайтын стрессорлардың нәтижесін тексеретіні, ал thermalstat Linux жүйесіндегі қолжетімді жылу аймақтарының көрсеткішін жинайтыны айтылған. Ескертуді мұқият оқыңыз: verify әр стрессорда жұмыс істемейді және тексерудің өзі операция санын азайтады. Сәтті exit code барлық жүктемені функционалдық тестіге айналдырмайды.

Барлық логикалық CPU үшін екі сағаттық қарапайым іске қосуды былай бастауға болады:

stress-ng -c 0 -t 2h

Сонымен қатар әр 10-30 секунд сайын сокеттер бойынша жиілікті, package power, температураны, желдеткіш айналымын және ядро оқиғаларын жинаңыз. Орташа мәнмен шектелмеңіз. Радиатордың дұрыс отырмауы немесе термопастаның ақауы көбіне бір сокеттің қатты қызуы, жиіліктің ерте төмендеуі және сол аймақтағы желдеткіштердің жылдамырақ айналуы арқылы көрінеді. Екі сокеттің орташа температурасы бұл айырманы жасырады.

Machine Check Architecture осындай оқиғаларды талдауға көмектеседі. Intel құжаттамасы тіркелетін аппараттық оқиғалар қатарына жүйелік шина, ECC, жұптық, кеш және TLB қателерін қосады. MCE жазбасы процессорға бірден үкім шығармайды, өйткені себеп жадта, шинада немесе қуатта болуы мүмкін. Бірақ қабылдау кезінде пайда болған жаңа uncorrected немесе fatal machine check себебі анықталғанша серверді «қабылданбады» күйіне ауыстырады. Түсіндірілмеген қайта жүктеу де екінші іске қосу сәтті өтсе де, ақау болып саналады.

Жиілікті жағдаймен бірге бағалау керек. Оны бір ядроға арналған жарнамалық ең жоғары жиілікпен емес, белсенді ядролар санына, орнатылған power limit, BIOS профилі мен кіріс ауа температурасына сай күтілетін режиммен салыстырыңыз. Жүктеме кезеңі ауысқанда қысқа төмендеу қалыпты. Thermal trip, BMC оқиғасы немесе желдеткіштің күрт өсуімен қатар жүретін ұзақ «ара тісі» салқындату мәселесін көрсетеді. Қызусыз тұрақты төмен қуат көбіне BIOS профиліне, қуат шегіне немесе микробағдарламаға байланысты.

Қайталану ақауды кездейсоқ шудан ажыратады. Бір сокетте матрицалық жүктеменің 40-минутында қате шықса, серверді салқындатып, сол режимді қайталаңыз және оқиғаға дейінгі уақытты белгілеңіз. Құрылым мен кепілдік рәсімі рұқсат етсе, содан кейін тек бір күмәнді құрамдастың орнын ауыстырыңыз. CPU, DIMM және қуат блогын бірге ауыстырмаңыз, өйткені сәтті қайталау ештеңені нақтыламайды.

CPU кезеңін тоқтататын жағдайлар анық: uncorrected немесе fatal MCE, утилита тіркеген есептеу қатесі, қатып қалу, өздігінен қайта жүктелу, платформа сипаттамасынан жоғары температура немесе дәл сондай жағдайда эталон жинақтамада жоқ қайталанатын троттлинг. Бір corrected жазба автоматты түрде «жарамды» деген шешім емес, ол талдау мен қайталауды талап етеді.

Жад утилитадағы нөл қатеден көбірек дәлел беруі керек

RAM тексеруі мүмкіндігінше көп қолжетімді көлемге үлгілерді жазып, қайта оқудан және жад контроллері деңгейіндегі ECC бақылауынан тұрады. Пайдаланушы бағдарламасындағы нөл қате жадтың таза екенін дәлелдемейді, өйткені процесс деректі оқымай тұрып ECC битті түзетуі мүмкін. Керісінше қате қорытынды да болады: OOM killer тестіні аяқтайды немесе гипервизор жадты қайтарып алады, ал техник оны DIMM ақауы деп жазады.

Орнатылған операциялық жүйе барлық физикалық байтты бөле алмайды. Ядро, драйверлер және бағдарламаның өзі RAM бөлігін ұстап қалады. Бастапқы қабылдауда, егер жоспар қайта жүктеуге рұқсат етсе, stress-ng арқылы виртуалды жадтың ұзақ өтуін жүктелетін жад тестімен біріктірген дұрыс. Жүктелетін тест көбірек мекенжай кеңістігін көреді, ал Linux бірлескен жүктемеде EDAC, машиналық қателер және нақты микробағдарлама әрекетін көрсетеді. Бұл әдістер бір-бірін толықтырады.

Кезең алдында installed және usable memory көлемін, арналар сызбасын, жиілікті, ranks санын және ECC бар-жоғын жазыңыз. Қуатты толық өшіріп қосқаннан кейін жадты үйрету журналын тексеріңіз. Сервер төмен жиілікпен немесе ажыратылған арнамен жүктеліп, бәрібір «көп жад» көрсетуі мүмкін. Тапсырыс берілген жинақтамамен салыстыру дұрыс орнатылмаған бөлшекті стресс-тестіге дейін табады.

Өту кезінде үш тәуелсіз белгіні бақылаңыз:

• бағдарлама мекенжайы бар mismatch немесе verify error көрсетеді;
• EDAC не BMC corrected, uncorrected, deferred немесе fatal есептегішін арттырады;
• ядро MCE, бетті пайдаланудан шығару, арна немесе DIMM ақауын тіркейді.

Linux RAS құжаттамасы corrected errors мағынасын дәл сипаттайды: дерек әлі зақымданбағандықтан жүйе жұмысын жалғастырады, бірақ осындай оқиға беретін модульді алдын ала ауыстыру болашақ uncorrected error қаупін азайтуы мүмкін. Бұл кез келген тарихи CE үшін DIMM тастау керек дегенді білдірмейді. Жаңа серверге қойылатын тәжірибелік өлшем қатаңырақ: қабылдау уақытында CE өсімі нөл болуы керек. Бір DIMM немесе арнаға байланған жаңа қайталанатын CE, бағдарлама тоқтамаса да, модульді ауыстыруға немесе сокет пен тақшаны тексеруге негіз болады.

Uncorrected, deferred және fatal error қабылдауды тоқтатады. Алдымен журналдарды, мекенжайды, syndrome, DIMM label және жүктеме кезеңін сақтаңыз. Содан кейін қуатты толық өшіріп қосып, тестіні бақыланатын жинақтамада қайталаңыз. Рұқсат етілген орын ауыстырудан соң оқиға DIMM соңынан ерсе, модульді ауыстырыңыз. Оқиға арнада немесе сокетте қалса, жалғағышты, процессордағы жад контроллерін немесе жүйелік тақшаны тексеріңіз. Мұндай нақтылау қайталама сапарларды азайтады: қолға бірінші түскен жад модулін ауыстыру сокеттегі майысқан контактіні жөндемейді.

Жад жылдамдығын әмбебап жарамдылық шегі емес, диагностикалық жағдай ретінде қолданыңыз. NUMA орналасуы, арна саны, ranks, қуат үнемдеу режимі және тест алгоритмі өткізу қабілетін өзгертеді. Сервер ішіндегі симметриялы тораптарды және сипаттамасы бірдей серверлерді салыстыру пайдалырақ. Бір сокеттегі елеулі әрі қайталанатын ауытқу DIMM сызбасы мен NUMA тексеруін талап етеді, бірақ рұқсат етілген пайызды платформа иесі тестіге дейін белгілеуі керек.

Дискіні жылдамдық графигінен кейін емес, деректі тексерген соң қабылдаңыз

Жинақтауыш күтілетін IOPS көрсетіп, сонымен бірге бүлінген блоктарды қайтаруы мүмкін. Сондықтан қабылдау тесті өнімділікті, дерек тұтастығын және тасымалдағыш күйін бөлек қарауы керек. Кідіріс графигі «құрылғы сұрауларды қалай орындайды» дегенге жауап береді, verify «жазылған байттар сол күйінде қайтты ма» дегенді тексереді, ал SMART пен контроллер журналдары аппараттық оқиғаларды түсіндіреді. Бұл дереккөздердің ешқайсысы қалғанын алмастырмайды.

Алдымен әр физикалық диск үшін smartctl -x нәтижесін сақтаңыз. RAID үшін нақты контроллердің синтаксисі мен утилитасы қажет, өйткені /dev/sda виртуалды том болуы мүмкін. NVMe үшін media and data integrity errors, available spare, critical warning және unsafe shutdowns мәндерін сақтаңыз. SAS пен SATA үшін құрылғы жарияласа, error log, self-test log, reallocated, pending және uncorrectable sectors көрсеткіштерін алыңыз. Атрибут атауы мен мағынасы өзгеше болғандықтан, бір шек кестесін барлық протоколға қолдануға болмайды.

smartctl нұсқаулығы маңызды жайтты айтады: кеңейтілген SMART тесті ондаған минуттан бірнеше сағатқа дейін созылуы мүмкін, ал нәтижені self-test log ішінен оқу керек. Команданы іске қосу нәтижеге тең емес:

smartctl -t long /dev/sda
smartctl -l selftest /dev/sda

Таза дискіде немесе арнайы тест бөлімінде fio үлгі жазып, оқу кезінде оны тексере алады. fio құжаттамасы verification функциясын бөлек режим деп көрсетеді және verify бар read workload бұрын жазылған файлды күтетінін ескертеді. Параметрлер есепте қалуы үшін нақты job-файл қолданамын:

[global]
ioengine=libaio
direct=1
filename=/dev/nvme0n1
verify=crc32c
verify_fatal=1
group_reporting=1

[write_verify]
rw=write
bs=1M
size=100%
do_verify=1

Бұл мысал көрсетілген құрылғының ішіндегісін жояды. Іске қосар алдында екінші инженер тұрақсыз /dev/nvme0n1 атына ғана сенбей, filename мәнін сериялық нөмірмен және диск ұясымен салыстыруы керек. Дерегі бар серверде алдын ала жасалған тест файлын немесе шектеулі бос бөлімді көрсетіңіз, бірақ тексерілген бет үлесін нақты жазыңыз. Файл тесті оның сыртындағы блоктарды тексермейді.

Тізбекті өтуден кейін болжамды жұмысқа жақын кезек тереңдігімен аралас кездейсоқ жүктеме қосып, орташа IOPS-пен шектелмеңіз. Bandwidth, қателер, орташа және шеткі кідіріс, кезек тереңдігі, диск температурасы және контроллер оқиғалары қажет. Нақты p99 шегін жоба белгілейді, өйткені дерекқор массиві мен архивтік HDD талаптары бөлек. Қабылдау кезінде бірдей дискілердің арасындағы ауытқулар да маңызды. Қайталанатын таймауттар, reset controller, байланыс үзілуі немесе бір құрылғы кідірісінің күрт өсуі «SSD ерекшелігі» емес.

Контроллер кеші көріністі өзгертеді. Қысқа жазба қорғалған кешке толық сыйып, массив тұрақты ұстай алмайтын жылдамдықты көрсетуі мүмкін. Кештен үлкен көлем жазып, тұрақты режимді күтіңіз. Жинақтама соны талап етсе, write back режимі батареямен немесе суперконденсатормен қорғалғанын, ал қорғаныс ақауы контроллер журналында жасырынбағанын тексеріңіз. Нәтижені жақсарту үшін write through режимін write back режиміне ауыстырмаңыз. Қабылдау бекітілген қауіпсіз баптауды өлшеуі керек.

Verify mismatch, жаңа media or data integrity errors, uncorrectable sectors, дискінің массивтен шығуы немесе сәтсіз extended self-test сөзсіз қабылдамауға негіз болады. Жаңа SATA дискісіндегі reallocated не pending sectors өсімі де ауыстыруды талап етеді. Талдаусыз жалғыз NVMe error log entry жеткіліксіз, өйткені кей жазба қолдау көрсетілмейтін команда туралы хабарлайды. Status field, тестіге дейінгі және кейінгі есептегіштер, ядро журналы және оқиға уақытының сәйкестігін қараңыз.

Қуатты бірлескен жүктемеде тексеріңіз

Қуат ақауы жеке CPU тестінде емес, процессорлар, жад пен дискілер бір уақытта қуат сұрап, желдеткіштер жоғары айналымға жеткен сәтте жиі көрінеді. Сондықтан жүктеменің соңғы төрт сағатында ішкі жүйелер қатар жұмыс істеуі керек. Есептеуді, жадты бөлу мен тексеруді, рұқсат етілген тест аймақтарына жазуды және желілік адаптерлер қабылдауға кірсе, желі трафигін іске қосыңыз.

BMC арқылы әр PSU үшін input power, output power, ток немесе күй, кернеу, кіріс және шығыс температурасы, fan RPM, redundancy state және SEL жинаңыз. Датчиктер жиыны платформаға байланысты. Жоқ көрсеткішті нөл деп алмаңыз, есепте «датчик берілмейді» деп жазыңыз. Жұмыс істеп тұрған блоктағы нөл ватт оқу қатесін, BMC микробағдарламасының мәселесін немесе жүктемені іс жүзінде бөлмейтін блокты көрсетуі мүмкін.

Өту түрін бақылаңыз. Дискіге жазу қосылғанда қуат өседі, желдеткіштер кідіріспен жауап береді, температура бір деңгейге тұрақтайды. CPU жиілігі Power Unit redundancy lost немесе voltage threshold event оқиғасымен бір уақытта түссе, алдымен салқындатуды емес, қуатты тексеріңіз. Бүкіл стойкадағы кіріс температурасы өссе, себеп серверде емес, ыстық ауаның кері айналуында болуы мүмкін.

Резервті тексеру тәуелсіз PSU, тәуелсіз желілер және әр блоктың жүктемені жеке көтеретіні расталған серверде ғана бір кірісті физикалық ажыратуды білдіреді. Оны алаң маманы келісілген рәсім бойынша орындайды. Жалғыз көздің кабелін суырмаңыз, блоктың ішінде жұмыс істемеңіз және жүктелген өндірістік стойкада ақауды еліктетпеңіз. Бір тәуліктік қабылдау адамдар мен көрші жабдыққа қауіп төндіруді ақтамайды.

Рұқсат етілген тест алдында жүктеме PSU арасында бөлінгенін және әр кіріс қазіргі шекті қуатты көтеретінін тексеріңіз. Бір желіні ажыратып, қайта жүктеу мен қате жоқ екенін тексеріңіз, резерв жоғалуы туралы дұрыс оқиғаны күтіңіз, қуатты қалпына келтіріп, екінші желі үшін қайталаңыз. Сервер redundancy restored күйіне оралуы керек. Қате SEL оқиғасы да қабылдау ақауы, өйткені пайдалану қызметі сервердің бір блокпен қалғанын білмейді.

Қуат тербелісі өздігінен ауыстыруға негіз емес. Платформа кернеуінің шектен шығуы, блок ақауы, ауысу кезінде жүктеменің жоғалуы, қайта жүктелу, электр ақауының иісі не дыбысы, қайталанатын power fault және резервті қалпына келтіре алмау негіз болады. Иіс, түтін, ұшқын немесе қалыптан тыс қызу байқалса, алаңның апаттық рәсімімен жүктемені дереу тоқтатыңыз. Таза журнал алу үшін қайта сынамаңыз.

Ауыстыру шешімін іске қоспай тұрып жазыңыз

Өлшемдер қате шыққаннан кейін пайда болса, команда оларды жеткізу мерзіміне бейімдеуге тырысады. Тестіге дейін әр ішкі жүйеге арналған шешім матрицасын келісіңіз:

Бұл матрицада «X температурасынан жоғары кез келген мән ақау» деген ереже әдейі жоқ. X саны нақты датчик пен платформа сипаттамасына жатады. Ортақ IOPS рұқсаты да жоқ. Біркелкі партия үшін эталон серверлердің медианасы мен ауқымы пайдалы, бірақ эталон да функционалдық өлшемдерден өтуі керек. Деректі бүлдіретін жылдам сервер бәрібір ақаулы.

Құрамдасты ауыстыру мен серверді түгел қабылдамауды ажыратыңыз. Бір диск немесе DIMM соңынан анық ерген қате әдетте бөлшекті ауыстырып, қатысты кезеңдерді қайталауға әкеледі. Жад арнасында қалатын оқиға, бір контроллер артындағы бірнеше дискінің қайталанатын reset әрекеті немесе екі PSU қуатының қатар төмендеуі ортақ торапты көрсетеді. Соңғы құрылғыларды ауыстыру себепті тек жасырады.

«Шектеумен қабылданды» мәртебесі әдістеменің құжатталған шектеуіне, мысалы саясат дайын массивке бұзатын жазба жасауға тыйым салғанда, жарайды. Ол түсіндірілмеген аппараттық қатеге қолданылмайды. «LBA аймағының 100%-ы оқылды, verify арқылы жазу орындалмады» деп жазыңыз, «дискілер стресс-тесттен өтті» демеңіз. Тапсырыс беруші қалған тәуекелді қабылдау не қабылдамауды өзі шеше алады.

GSE S200 Series серверлерін жеткізгенде жабдықтың өндірістен қолдауға дейінгі өмірлік циклін бақылайды, сондықтан мұндай матрицаны жинақтама және қабылдау хаттамасымен бірге келісуге болады. Ол кез келген басқа платформаға да пайдалы: өлшемдер инженер әдетіне емес, нақты жеткізілген тораптың сипаттамасына сүйенуі керек.

Есеп әр қорытындыны қайталауға мүмкіндік беруі керек

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

Тақырып бөлігінде сервер моделі мен сериялық нөмірін, слоттар бойынша құрамын, BIOS, BMC және микробағдарлама нұсқаларын, өнімділік профилін, операциялық жүйе мен ядроны, күнді, стойкадағы орынды және кіріс ауа температурасын көрсетіңіз. Тексерілмеген функцияларды бөлек жазыңыз: екінші желілік порт, GPU, нақты HBA немесе желдеткішті ыстықтай ауыстыру. Қамтудың ашық қалған жері жасырын болжамнан дұрыс.

Әр кезең үшін басталу және аяқталу уақытын, команданы немесе job-файлды, өңделген дерек көлемін, аяқталу күйін және есеп жинағындағы бастапқы журналға сілтемені жазыңыз. Метрикаларды бір уақыт жүйесімен жинаңыз. CSV немесе JSON суреттен ыңғайлы, өйткені одан максимумды тауып, уақыттық қатар құрып, екі сынақты салыстыруға болады. BMC скриншотын датчиктің физикалық орнын растайтын қосымша дәлел ретінде қалдырыңыз.

Телеметрия жинағышы да істен шығуы мүмкін, сондықтан тест кезінде қатардың толықтығын тексеріңіз. Қайта жүктеуге дейінгі соңғы 20 минуттың жоғалуы ең пайдалы аралықты өшіреді. Әр сұрау нәтижесін тест серверінің жадында ұстамай, бірден басқа тасымалдағышқа немесе басқару құрылғысына жазыңыз. Команданың қайтару кодын және байланыс үзілуін бөлек белгілеңіз: жаңа жолдың болмауы датчик тоқтағанын, ОС қатып қалғанын немесе басқару байланысы жоғалғанын білдіруі мүмкін, бұлардың шешімі әртүрлі.

Әр кезеңнің қорытынды жолында өлшем мен шарт болуы керек. «Температура қалыпты» ештеңе дәлелдемейді. «CPU1 max 76 °C, inlet max 25 °C кезінде, платформа шегі 85 °C, thermal events 0» деген жазбаны тексеруге болады. Бұл сандар сіздің серверіңізге арналған әмбебап шек емес, жазба пішінін көрсетеді. Нақты өлшемдер мен модельдің ресми шегін қойыңыз.

Айырма нөл болса да, SEL, SMART және EDAC бастапқы және соңғы нәтижесін тіркеңіз. Есептегіштер үшін delta = after - before формуласын көрсетіңіз. SEL тазаланса, тазалауға дейінгі журнал мен команда уақытын қосыңыз. Диск атауын, WWN немесе serial мәнін физикалық slot-пен байланыстырыңыз. EDAC memory label мәнін қызмет көрсету нұсқаулығындағы слот белгісімен салыстырыңыз.

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

Соңғы мәртебенің үш анық мәні бар: «қабылданды», «қабылданбады» немесе «көрсетілген тексерілмеген режимдермен қабылданды». Құрамдасты ауыстырғаннан кейін есептің жаңа нұсқасын шығарып, кемінде қатысты кезең мен бірлескен шекті жүктемені қайталаңыз. Жад қатесінен кейін DIMM ауыстырып, ескі сәтті CPU тестіне қол қоюға болмайды: жад контроллері процессор ішінде, ал монтаж жылулық контактіні немесе арналар сызбасын өзгертуі мүмкін.

Бір тәуліктік тест бастапқы ақауды табады, бірақ пайдалануды алмастырмайды

Таза өткен 24 сағаттың өзі желдеткіштің тозуын, бірнеше жылдан кейінгі флеш-жад деградациясын немесе сирек жұмыс үйлесімінде шығатын микробағдарлама қатесін болжамайды. Қабылдау бастапқы істен шығу мен қате жинақтама қаупін азайтады. Одан кейін SEL, SMART, ECC, температура және қуат оқиғаларын тұрақты жинау, жинақтауыштардың жоспарлы self-tests рәсімі және алаң тәртібі бойынша резервті тексеру қажет.

Істен шығу бағасы жоғары немесе толық өту физикалық тұрғыда сыймайтын жерде сынақ уақытын ұзартыңыз. Үлкен RAM көлеміне бірнеше өту керек, сыйымдылығы үлкен HDD extended self-test пен толық жазуға уақыт талап етеді, GPU мен желілік үдеткіштер өз жүктемесін қосады. Температураны көтеріп немесе қорғанысты өшіріп тестіні жеделдетпеңіз. Онда қабылдау жағдайын бұзатын сынаққа айналдырып, кепілдікке қажет дәлелді жоғалтуыңыз мүмкін.

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

Таза өткен сынақтан кейін есеп жинағын нақты сериялық нөмірдің эталоны ретінде сақтаңыз. Бір айдан соң жаңа corrected ECC, media errors өсімі немесе температура айырмасының өзгеруі кезекші инженердің есімен емес, осы бастапқы күймен салыстырылады. Тест қайталанатын аппараттық оқиға берсе, іске қосу мерзімі үшін журналмен саудаласпаңыз. Бір тәулік өз құнын өтеді: ақау ауыстыру жоспарлы кезде көрінді, апаттық жұмысқа айналмады.