Redfish API арқылы серверлерді инвентаризациялау: сериялық нөмірлер және CMDB

Нақты не жинау керек және CMDB-ке неліктен керек

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

Көбінесе мәліметтер жоғалып кетеді, оларды апат немесе сатып алу кезінде төте тауып алу керек болады. Шассидің сериялық нөмірі біршама тіркеледі, ал қуат блоктарының, дисктердің немесе желілік карттардың сериялық нөмірлері басқару интерфейсінде ғана қалып қояды. BIOS/UEFI, BMC және дисктер мен контроллерлердің прошивкалары да осыған жатады. Жұмыс істеп тұрғанда бұл туралы ұмтыла береді, ал үйлеспеушілік немесе осалдық болса, парктің жартысы әртүрлі нұсқаларда екені бірден белгілі болады.

iDRAC/iLO арқылы қолмен жинап, Excel-ге тасымалдау үш себеппен нашар масштабталады. Бұл ұзақ: ондағы серверлерге сағаттар мен күндер кетеді. Қателер міндетті: толтырылмаған өрістер, шатасқан слоттар, қате көшірілген мәндер. Және деректер тез ескіріп қалады: прошивка жаңартылды, диск ауыстырылды, датчик ауытқыды, ал файл бұрынғы күйінде қалды.

CMDB әдетте екі нәрсені талап етеді: біртекті деректер форматы және тұрақты сәйкестендіру кілттері.

Біртекті формат дегеніміз — мәндердің қалай болады екендігін алдын ала шешу: күндер, нұсқалар, өлшем бірліктері, өндірушілердің атаулары. Адам үшін “BIOS 2.3.1” және “2.3.1 (BIOS)” бірдей болса да, іздеу мен есептер үшін бұл әртүрлі жолдар.

Тұрақты сәйкестендіру кілттері CMDB-ге есеп береді: сол сервер екенін түсіну үшін, тіпті хостты өзгертіп немесе басқа стойкаға қозғалтып жіберсеңіз де. Әдетте негізгі кілт — шассидің сериялық нөмірі (Serial), компоненттер үшін — “сериялық нөмір + тип + слот/позиция” комбинациясы. Сонда bay 3-тегі диск ауыстырылды деу жаңа диск пайда болды ма деген белгі емес, нақты оқиға болады.

Redfish-тен әр сервер үшін жинауға тұратын практикалық минимум:

• Идентификаторлар: шассидің сериялық нөмірі, модель, өндіруші, asset tag, UUID (болса).
• Прошивкалар: BIOS/UEFI, BMC нұсқасы, контроллерлер мен дисктердің прошивка нұсқалары (берілсе).
• Компоненттер: CPU, жедел жады, дисктер, RAID/HBA, желілік адаптерлер, қуат блоктары, вентиляторлар.
• Датчиктер мен күй: температуралар, қуат, вентилятор статустары, жалпы health, белсенді қателер.

Инвентаризация жетістігін “біз бірдеңе жинадық” деп емес, мына төрт көрсеткішпен өлшеу ыңғайлы:

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

Redfish жай сөзбен: инвентаризацияға не береді

Redfish — стандартталған API, ол сервердің BMC басқару компьютерінен деректер оқуға (және кейде өзгертуге) мүмкіндік береді. Негізінде сіз сервер ішіндегі “басқару компьютеріне” сұраныс жіберіп, жабдық туралы фактілер аласыз, тіпті негізгі ОС өшірілген немесе әлі орнатылмаған болса да. Сондықтан Redfish арқылы жинау CMDB үшін сенімді негізге айналады.

Ең үлкен артықшылығы — агенттер қажет емес. ОС қайсы, SSH/WinRM бар ма, жүйе жүктелді ме — бұларға тәуелді емессіз. Егер BMC желіде және тіркелгі деректері бар болса, көп пайдалы нәрсені жинауға болады.

Көбіне агентсіз қолжетімді: сериялық нөмір мен модель, өндіруші, UUID, CPU мен жедел жады құрамы, желілік интерфейстер, дискілер мен контроллерлер, BIOS және жеке прошивкалардың нұсқалары, датчик оқулары (температура, вентилятор, қуат) және health статусы. Бұл “не тұрған” және “қандай прошивка” деген сұрақтарға тез жауап беруге көмектеседі.

Redfish деректері бірнеше бөлімдерге бөлінген. Көп жағдайда кездесетіндер:

• Systems: есептеу түйіні логикасы (идентификаторлар, CPU/RAM, жүктеу, кейде сақтау және NIC).
• Chassis: физикалық бөлік (датчиктер, қуат, вентиляторлар, кейде модульдердің инвентаризациясы).
• Managers: BMC өзі (нұсқа, желі, оқиғалар, аккаунттар).
• UpdateService: жаңартулар туралы мәлімет және кейде орнатылған firmware тізімі.

Шектеулерді де ескеру керек.

Біріншіден, құқықтар. «Тек оқу» есептік жазба қауіпсіз, бірақ кей кезде кей өрістерді бермеуі мүмкін. Администратор құқықтары көбірек деректер береді, бірақ тәуекелдерді арттырады.

Екіншіден, вендорлар арасында бірдей бөлім әртүрлі толтырылады: кей жерде сериялық нөмір бір өрісте, кейде басқа жерде, ал кейбір деректер OEM-блоктарда жасырылады.

Үшіншіден, толық қолдау болмай қалуы мүмкін. Мысалы, датчиктер бар, ал компоненттердегі прошивкалар жартылай ғана шығады.

Практикалық мысал: парк әртекті ұрпақ серверлерден тұрады, дата-орталық және ИИ түйіндері бар. Кей жерде Redfish толық firmware тізімін қайтарады, кей жерде тек BIOS нұсқасын ғана. Бұл қалыпты жағдай. Бастысы — бос өрістерге қатысты “қирап кетпеу”, деректерді мұқият нормализациялау және CMDB-ге не оқылды, не оқылмағанын тіркеу.

Дайындық: қолжетімділіктер, қауіпсіздік және мақсаттар тізімі

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

BMC-ге қолжетімділіктер: минималды құқықтар және біртұтас тәсіл

Әр сервер үшін BMC IP-адресі (iDRAC, iLO, XClarity және т.б.) және деректер оқи алатын есептік жазба қажет. ReadOnly рөлі әдетте сериялық нөмірлерді, прошивка нұсқаларын, компонент инвентарын және телеметрияны алу үшін жеткілікті.

Алдын ала қолыңызда қысқа тізімді дайындаңыз:

• BMC IP-адрестері және хост атауы (болса)
• инвентаризацияға арналған бөлек сервис-аккаунт (read-only)
• қай сайттар мен желі сегменттері жинаушыға қолжетімді екенін көрсету
• құрылғыларды шатастырмау үшін атау ережесі (мысалы, SITE-RACK-U)

Серверлер тізімінің дереккөзі

"шамамен 200 сервер чаттыда" сияқтыға сенбеңіз. Бір файл немесе кесте болуы керек, әр жазбада ең кемі: инвентарлық нөмір, сайт, бөлме немесе аймақ, стойка және юнит, иесі немесе бөлімше болу керек. Бұл тізім Redfish деректерін CMDB-дегі объектімен байланыстыруға көмектеседі, тіпті сериялық нөмір уақытша оқылмаса да.

Қауіпсіздік: парольдер, аудит және қолжетімділік шекаралары

Парольдерді скриптте сақтамаңыз және командалық жолда жібермеңіз. Құпияларды қорғалған сақтауда қолданыңыз немесе ең болмағанда жинауды іске қосатын сервердегі ортаның айнымалыларында сақтаңыз.

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

Қолжетімділікті тексеру: желі, HTTPS және сертификаттар

Масштабты іске қоспас бұрын аздаған серверлерде жылдам тексеру жасаңыз. Тексеріңіз:

• жинағыш пен BMC желісі арасындағы маршрутизация мен фильтрлер
• 443 порт және HTTPS дұрыс жауап беретіні
• TLS нұсқалары талаптары (ескі BMC-лар жаңа саясаттарға сай келмеуі мүмкін)
• сертификаттардың күйі: сенімді, өзіне қол қойылған, мерзімі өткен

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

Қадамдап: сериялық нөмірлер, прошивкалар және датчиктер үшін сұраулар

Бастау үшін ServiceRoot-тан бастаңыз: ол қандай бөлімдер қолжетімді екенін айтады. Негізгі жол көбінесе: /redfish/v1. Одан әрі @odata.id сілтемелеріне қарай жүру жақсырақ — URL-ды болжауға тырыспаңыз: вендорлар арасында құрылым әртүрлі.

# Пример: базовая проверка, что Redfish жив
curl -k -u user:pass https://BMC_HOST/redfish/v1

1) Systems және Chassis табыңыз және олардың бар-жоғын тексеріңіз

Керекті коллекциялар әдетте /redfish/v1/Systems және /redfish/v1/Chassis жолдарында болады. Коллекцияны ашып, Members ішіндегі элементтерді алыңыз (көбінесе бірнеше болады).

Жұмыс схемаcы:

• GET /redfish/v1 және Systems, Chassis, Managers, UpdateService сілтемелерін сақтаңыз (болса)
• Коллекцияға GET, содан кейін әр элемент үшін Members[i][email protected] бойынша өтіңіз
• Әр объектіден негізгі өрістер мен ішкі компоненттердің сілтемелерін (Storage, NetworkAdapters, Sensors және т.б.) алыңыз

2) Сериялық нөмір мен модель: System және Chassis-ты салыстырыңыз

Көбінесе сериялық нөмір мен модель system объектісінде болады: SerialNumber, Model, Manufacturer, кейде SKU және PartNumber. Бірақ шассидің және жүйенің сериялық нөмірлері әр түрлі болуы мүмкін (мысалы, корпус ішіндегі модуль).

Практика қарапайым: екі мәнді де сақтап, кейін салыстырыңыз.

• System: GET /redfish/v1/Systems/<id> -> SerialNumber, Model, UUID (бар болса)
• Chassis: GET /redfish/v1/Chassis/<id> -> SerialNumber, PartNumber, AssetTag

Егер сериялық нөмірлер түрлі болса, бұл міндетті қате емес. Қате — сіз бірін үміт етіп, CMDB-де дереккөз көрсетпей жазып қоюыңыздан басталады.

3) Прошивкалар: BIOS, BMC және компоненттер қайдан іздеу керек

Ең ыңғайлы нұсқа — егер FirmwareInventory қолжетімді болса: GET /redfish/v1/UpdateService/FirmwareInventory және Members арқылы өтіңіз. Онда көбінесе Version, SoftwareId немесе Id, сонымен қатар компонент типі бар.

Егер FirmwareInventory жоқ болса, комбинирленген жинау қолданыңыз:

• BIOS: /redfish/v1/Systems/<id>/Bios (немесе BIOS нұсқасы System ішінде)
• BMC: /redfish/v1/Managers/<id> (әдетте FirmwareVersion өрісі)
• RAID және дисктер: /redfish/v1/Systems/<id>/Storage -> контроллерлер -> Drives
• NIC: /redfish/v1/Systems/<id>/NetworkAdapters (қолдау болса)

"Ағымдағы" мен "қолжетімді" айырмашылығын анықтау үшін өріс орнатылған нұсқаны сипаттайтынын (мысалы, инвентарлық жазбадағы Version) тексеріңіз. Егер нұсқаудың екі түрін көрсеңіз, оларды әртүрлі атпен сақтап, араластырмаңыз.

4) Датчиктер: температура, вентиляторлар, қуат

Датчиктер көбіне шассиде болады: GET /redfish/v1/Chassis/<id>/Thermal және /redfish/v1/Chassis/<id>/Power. Онда әдетте Temperatures, Fans, PowerSupplies массивтері бар.

Тек мәнді ғана емес, Status.State және Status.Health сияқты күйді де қараңыз. Шекті мәндер (мин, макс, критикалық) қасында болуы мүмкін, оларды сақтау пайдалы: сол модель үшін қандай мән шын мәнінде критикалық екенін білесіз.

5) Коллекциялар, ішкі сілтемелер және пагинация

Redfish жиі коллекцияларды Members арқылы қайтарады. Егер элементтер көп болса (мысалы, дисктер немесе оқиғалар), пагинация болуы мүмкін. [email protected]-ты іздеп, сілтеме жоқ болғанша өтіңіз.

Деректерді нормализациялау: бәрін бірдей көрініске келтіру

Нормализация мақсаты — бір физикалық сервер CMDB-де әрқашан бір объект ретінде көрінуі. Redfish, ОС және есеп жүйелері оны әртүрлі атауы мүмкін. Осы болмауы тиіс.

Бір сервер — бір "канондық" атау

Алдымен сәйкестендіру ережесін таңдаңыз және барлық жерде қолданыңыз. Әдетте тұрақты уникалды идентификатор пен адамға түсінікті атаудың қосындысы жақсы жұмыс істейді.

Практикалық нұсқа: hostname (ОС-тен), AssetTag (инвентарлық нөмір) және BMC-тің көріп тұрған атауын жеке өрістерде сақтаңыз. "Канондық атауды" (display name) мысалы <site>-<rack>-<unit> немесе AssetTag бойынша жасаңыз. Сонда Redfish-тен System.Name=SRV-01 шықса да, DNS-та srv01.prod.local болса да есеп бұзылмайды.

Біртекті форматтар: күндер, нұсқалар, өлшем бірліктері

Redfish күні бір форматта, CMDB басқа формат күтеді, ал прошивкалар "1.2.3 (Build 456)" сияқты келеді. Алдын ала ережелер орнатыңыз:

• күндерді ISO 8601 форматында сақтаңыз (мысалы, 2026-01-19T10:15:00Z) және қажет болса "күні" ретінде бөлек етіңіз
• прошивка нұсқаларын екі түрде сақтаңыз: келген күйі (шикі мәтін) және салыстыру үшін нормаланған нұсқа
• датчик оқуларын стандарт бірліктерге келтіріңіз (температура - °C, қуат - W), бастапқы бірлікті де сақтаңыз

Компоненттер мен өрістерді сәйкестендіру

Компоненттерді (CPU, DIMM, PSU, дискілер, NIC) байланыстыру маңызды: не ауыстырылды екенін білу керек — модуль бе, жад планкасы ма, диск пе. Минимум компонент үшін: PartNumber, SerialNumber, FirmwareVersion және ата-аналық серверге сілтеме.

Типтік мәселе: бір вендор SerialNumber дейді, басқа SN, үшіншісі Oem ішінде жасырады. Маппинг қабатын (сәйкестендіру кестесін) жасап, әртүрлі көздерден приоритет бойынша канондық өрістерді толтырыңыз.

Бос өрістер және дедупликация

Бос мәндерді null ретінде сақтау жақсы, бос жол немесе "N/A" емес. Оны валидациялау жеңіл. Егер компоненттің сериялық нөмірі жоқ болса, уақытша кілт ретінде Redfish-тен келген Id + тип қолдансаңыз да, деректер сапасын белгілеңіз.

Дубликаттарды жасау үшін кілтті алдын ала анықтаңыз. Көбінесе бұл:

• System.UUID (тұрақты болса) немесе SerialNumber + Manufacturer + Model комбинациясы
• резерв ретінде AssetTag
• және соңғы опция — хост атауы

Жүктеу алдында қысқа тексеріс өткізіңіз: кілт тең болса — жазбаны жаңартыңыз, тең емес болса — жаңа жазба жасап, дереккөзі, жинау уақыты және деректер схемасының нұсқасын тіркеңіз.

Серверлер мен компоненттер үшін CMDB-де типтік өрістер

Есеп хаоса айналмасын десеңіз, CMDB екі сұраққа жауап беруі тиіс: бұл қандай сервер және оның қазіргі жағдайы қандай. Идентификация кілттері ең маңызды: әйтпесе ОС-ны қайта орнатқанда немесе контроллерді ауыстырғанда дубльдер пайда болады.

Идентификация және сервер карточкасы

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

• Шассидің сериялық нөмірі (Chassis Serial) — негізгі физикалық идентификатор
• System UUID — қосалқы кілт
• Asset Tag немесе инвентарлық нөмір — бухгалтерия мен ішкі процестермен байланыс
• Өндіруші және модель (Manufacturer, Model) — есептер және қызмет көрсету ережелері үшін
• Орналасу және жауапкершілік: сайт, стойка, юнит, иесі, маңызды деңгейі, рөлі (мысалы, виртуализация немесе дерекқор)

Эксплуатация контекстін де тіркеу орынды: орта (prod/test), домен немесе кластер, енгізу күні және соңғы тексеру күні. Бұл шынайы өзгерістерді ұзақ уақыт жиналмаған жинаумен шатастырмауға көмектеседі.

Компоненттер: не қарастыру және қай деңгейде

Компоненттерді сақтау жеңіл ауыстыруды көрсетуі тиіс: жад планкасы, диск немесе бүкіл сервер ауыстырылды ма. Көбінесе әр үлкен бөліктен жеке CI жасалады (CPU, RAM, дискілер, RAID, NIC, PSU, вентиляторлар) және серверге "бөліп-жинау" қатынасы болады.

Компонент үшін практикалық минимум: модель, сериялық нөмір (бар болса), сипаттамалар, слот/порт/позиция, бар-жоғы және Health статусы. Дисктер үшін өлшем, тип, bay позициясы және RAID массвқа қатысы маңызды.

Прошивкалар, драйверлер және өзгерістер тарихы

Прошивкаларды араластыруға болмайды: ағымдағы мән тез тексеру үшін, тарих — инцидент кейін талдау үшін.

Ыңғайлы модель:

• Ағымдағы: BIOS/BMC, RAID/HBA прошивкасы, NIC нұсқасы, backplane нұсқасы (бар болса)
• Тарих: дата, ескі нұсқа, жаңа нұсқа, өзгеріс көзі (планеттік қызмет көрсету, инцидент)
• Сәйкестік саясаты: берілген сервер типі немесе рөлі үшін мақсатты нұсқа

Күйлер, ескерту және тәуекелдер

Health (OK/Warning/Critical) сервер деңгейінде және кіші жүйелер үшін сақталуы пайдалы. Жанында "соңғы ескерту" мәтіні мен уақыты болсын: осылай мәселе ғана емес, оның жаңалығы да көрінеді.

Егер тәуекелдерді басқарсаңыз, EOL/EOS даталарын (қолдаудың аяқталуы, сатылымнан шығару) және "тұрақсыз аймақта" көрсеткішті қосыңыз. CMDB содан кейін жоспарлау құралына айналады: прошивкаларды жаңарту, дисктерді ауыстыру және зейнетке шығару тізімдерін оңай құруға болады.

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

CMDB-ге экспорт: формат, кесте және сапаны бақылау

Redfish арқылы жинаған соң деректерді CMDB-ге осылай жіберу керек, сонда CMDB уақыт өте жазбаларды дұрыс жаңарта алады. Көп кездесетін қате — әр жолы жаңа жазба жасау. Сондықтан сәйкестендіру кілттерін алдын ала анықтаңыз: мысалы, сериялық нөмір + өндіруші немесе тұрақты System UUID.

Экспорт форматы: не таңдау керек

Интеграция үшін JSON ыңғайлы: ол иерархиялық құрылымды (сервер -> қуат блоктары -> датчиктер) жақсы береді және типтер сақталады. Тез тексеру үшін CSV пайдалы: оңай ашып қай жерде өрістер жетіспейтінін көруге болады.

Практикада JSON CMDB-ге жіберіледі, әрі негізгі өрістердің қысқа CSV-сы сақталады (идентификаторлар, модель мен өндіруші, BIOS/BMC/RAID нұсқалары, негізгі датчик статустары, жинау уақыты).

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

Инкременттік жүктеу және кесте

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

• last_seen (соңғы сәтті жинау)
• өрістер жинағының hash/etag (нені өзгертті тез білу үшін)
• дереккөзі (Redfish endpoint, есептік жазба/роль)
• жаңарту статусы (жасалды, жаңартылды, өткізіліп қалды)
• өткізілу себебі (қолжетімсіз, таймаут, өріс жоқ)

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

Логтар және сапаны бақылау

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

Сапаны бақылау қарапайым метрикаларда болуы тиімді: негізгі өрістерді толтыру пайызы, жаңартылмаған хосттар тізімі және соңғы экспортпен салыстыру. Егер кеше серверде прошивка мен 12 датчик болған, ал бүгін 0 шықса, жазба күмәнді деп белгіленіп, ескі мәндерді растаусыз өшірудан сақтаңыз.

Мысал сценарий: шағын сервер паркін инвентаризациялау

20 сервер бар: екі сайтта — негізгі ЦОД-та 12, резервті бөлмеде 8. Өндірушілер әртүрлі, бұл BMC-тан көрінеді: бір жерде Redfish бәрін қайтарады, бір жерде өрістер басқа атпен келеді, ал екі машинаның BMC-ларын ескіреді.

Бастапқыда "мақсат картасын" жасаңыз — қарапайым сәйкестендіру кестесі: түйін атауы, BMC IP/DNS, сайт, стойка мен юнит, жауапты иесі. Бұл опрос хаосқа айналуын болдырмайды.

Содан кейін Redfish опросын іске қосып, басты сәйкестендіру кілтін шешіңіз. Практикада екі мән бірден сақтайды: SerialNumber (желіден) және AssetTag (ұйымның инвентарлық нөмірі). CMDB-де басты кілт көбіне AssetTag болады, себебі ол жүйелік платаны ауыстырғаннан кейін де қалып қалуы мүмкін. AssetTag болмаса, уақытша BMC IP + SerialNumber жұбын қолдану ыңғайлы.

Нормализациядан кейін жазба бір объект ретінде көрінеді: модель, өндіруші, сериялық нөмір, UUID, желі интерфейстері мен MAC-тар, CPU мен RAM құрамы, дискілер, BIOS нұсқасы, BMC нұсқасы және негізгі сенсорлар (температура, вентиляторлар, қуат) бірліктерімен.

Әдетте не шығады: 1-2 серверде Redfish-тегі сериялық нөмір жапсырмадағыдан әртүрлі (көбінесе платаны ауыстырғанда), 3-5 машинада BMC нұсқасы едәуір ескі, ал бір стойкада температура «ыстық нүкте» ретінде көрінеді (кіріс температура артық).

Нәтиже пайдалы болу үшін иелерге екі артефакт дайындаңыз: CMDB үшін экспорт және деректер сапасы туралы қысқа есеп. Есепте қай өрістер бос, сәйкестік қақтығыстары, қандай прошивкаларды жаңарту қажет және қай стойкаларды салқындатуды тексеру керек — осының бәрі болуы керек.

Redfish жинаудағы типтік қателер және оларды қалай болдырмау

Скрипт сұрақтар жіберіп, жауаптар алса да, CMDB жиі «ластанған» шығады. Төменде ең жиі кездесетін қателер және ұсыныстар.

• System және Chassis-ты шатастырып, әртүрлі сериялық нөмірлер алады. Көп серверде жүйе мен шассидің сериялық нөмірі әртүрлі болуы мүмкін, және екеуі де өз міндетін атқарады. Алдын ала қай сериялық нөмір Server CI үшін негізгі екенін шешіңіз, екіншісін бөлек өріске сақтаңыз. Маңдайшаны (field source) міндетті түрде тіркеңіз.

• Датчиктерді бірліктерсіз жинап, модельдер арасында салыстыра алмай қалады. Температура сан ретінде немесе мән+бірлік ретінде, кейде әртүрлі дәлдікпен келеді. "Шикі" және "нормаланған" мәндерді бөлек сақтаңыз. Нормаланғанда бір жүйеге (°C, W, RPM) келтіріп, бастапқы бірлікті бөлек өріске жазып қойыңыз.

• Құқықтарды ескермеу: кей жүйелер 200 OK қайтарып, қажетті өрістерді жасырады. Тек жауап кодын емес, критикалық өрістердің толтырылуын тексеріңіз. Бақылау жиынтығы (SerialNumber, UUID, кемінде BIOS/BMC) жасап, бос болса мақсатты "недосбор" ретінде белгілеңіз.

• Прошивкаларды еркін мәтін ретінде сақтау және салыстыру жоғалту. "2.10", "2.9", "2.10a" сияқты мәндер мәтін ретінде сортталғанда қате шығады. DisplayVersion (вендор көрсеткен) және ComparableVersion (салыстыруға арналған сіздің форматыңыз) ретінде бөліңіз. Егер нұсқа семантикасы түсініксіз болса, кем дегенде сандар массиві мен суффиксті сақтаңыз әрі бастапқы мәнді өшірмеңіз.

• Жарамсыз сәйкестендіру кілті себебінен жаңа жазбалар жасауы. Дубльдердің жиі себебі — өзгеретін IP немесе хост атауы. Сервер үшін тұрақты идентификатор қолданыңыз: UUID, System сериялық нөмірі немесе (өндіруші + модель + сериялық нөмір) комбинациясы. Әртүрлі парк үшін кілт иерархиясы көмектеседі: алдымен UUID, болмаса сериялық нөмір, болмаса AssetTag.

Пилот жүргізбес бұрын практикалық тест: 2-3 түрлі модельді алып, күн аралығында деректерді екі рет жинап, CMDB-де бірдей CI-лар жаңартылып жатқанын, жаңа жазбалар жасалмағанын тексеріңіз.

Қысқа чеклист және келесі қадамдар

Экспорт алдында сапаны таңдап тексеріңіз. Бұл әдетте CMDB-ге қоқыс жіберіп, дубльдер жасауды болдырмайды.

Экспорт алдындағы жылдам тексеріс

• BMC HTTPS арқылы қолжетімді, есептік жазба жұмыс істейді, аты (DNS қолдансаңыз) тұрақты шешіледі.
• Сериялық нөмір, модель, UUID және asset tag толтырылған және логикалық сәйкестендірілген (мысалы, әр түрлі хосттарда бірдей UUID жоқ).
• Прошивкалар кем дегенде BIOS пен BMC үшін жиналған, нұсқалар бірдей форматқа келтірілген.
• Датчиктер (температура, қуат, вентиляторлар) бірліктерімен бірге келіп, статустары OK, Warning, Critical секілді түсініктірек өрістерге келтірілген.
• Экспортта CMDB-мен сәйкестендіру үшін бір тұрақты кілт бар (әдетте UUID немесе өндіруші+сериялық нөмір), және ол хост атауына тәуелді емес.

Егер сәйкессіздіктер табылса, "не дұрыс емес" қана жазып қоймай, "қалай шешті" деген жазбаны да тіркеңіз. Мысалы: сериялық нөмір BMC-да бос болған — BMC-ты жаңартқан соң өріс пайда болған, CMDB-ге түзету күні жазылды.

Келесі қадамдар

Кез келген уақытта барлық паркты қамтуға тырысуға қарағанда, кіші итерациялармен жүру жақсы.

• Әртүрлі тип пен ұрпақты қамтитын 5 серверден пилот жасаңыз, өріс толтыруды тексеріңіз.
• CMDB үшін минималды міндетті жиынтығын бекітіңіз (идентификаторлар, негізгі прошивкалар, датчиктер бойынша денсаулық) және жаңарту ережесін орнатыңыз.
• Жоспар жасаңыз: маңызды өрістерді жиі, прошивка мен инвентар деректерін сирек жинаңыз.
• Сапа бақылауын қосыңыз: толтыру пайызы, дубликаттарды іздеу, UUID/сериялық нөмірдің кенет өзгергені туралы алерт.
• Қысқа регламент құрыңыз: BMC қолжетімділіктері үшін кім жауапты, сәйкессіздіктер кім қарайды және өзгерістерден кейін деректер қаншалықты жылдам жаңартылады.

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