ТЗ‑дегі сервердің кеңейтілімділігі: артық төлемсіз резервті қалай бекіту

Неге алдын ала кеңейтуді ойлану керек және қателіктер қайда шығады

Серверді көбіне 12–18 айдан кейін толық ауыстырады — себебі ол бұзылғандықтан емес, оған жай ғана «өсіп кету» мүмкіндігі қалмағандықтан. PCIe слоттары бітеді, диск орындары толы, ускорительге қажетті PCIe жолдары жетіспейді, немесе блок питания қосымша жүктемені көтере алмайды. Бастапқыда арзан көрінген шешім платформа алмастырып, миграция мен тоқтап қалуға әкеледі.

Ең жиі болатын апгрейдтер бір жылдың ішінде болжамды: дискілер қосылады (немесе тезірек NVMe-ге ауысады), ОЗУ ұлғайтылады, екінші желілік карта 10/25/100G орнатылады, кейде GPU немесе HBA/RAID-контроллер қосылады. Осылардың көбін платформаның деңгейінде ескеру оңай, тіпті қазір компоненттерді сатып алмасаңыз да.

Ақша екі жерде жоғалады. Біріншісі — бәрін бірден «резервпен» сатып алу: артық дискілер, максималды CPU, қымбат NIC, олар бір жыл бойы тұрмайды. Екіншісі — негізге үнемдеу: бос корзиналары жоқ шасси, hot-swap жоқ, қажетті слоттары жоқ плата, резерві жоқ БП. Ондай кезде апгрейд жаңа серверден қымбатқа түседі.

Сервердің кеңейтілімділігі ТЗ-де жай ұран болмауы үшін өлшенетін нәрсені опциядан ажыратыңыз. Минимумды санмен бекіту керек: қанша бос PCIe слот болу керек (қанша нұсқа/ені), қанша диск орны қолжетімді және қандай түрлер (SAS/SATA/NVMe, hot-swap керек пе), БП‑ға қандай қуаттық резерв қажет, және желіні қалай кеңейтетін боласыз (бос порттар, SFP+/QSFP, қосымша NIC).

Ал нақты «қайсы компонентті қашан сатып аламыз» (GPU моделі, желінің жылдамдығы, диск көлемі) опция немесе 2‑ші кезеңге қалдырған жөн. Осылайша сіз өсуге дайындыққа төлейсіз, бірақ қазір қажет емес темірге емес.

Өсу болжамын жинаңыз: бір жылдан кейін не өзгереді

ТЗ-де серверді кеңейту мүмкіндігін артық төлемсіз қалдыру үшін 12–24 айға қарапайым болжам керек. "Қашанда өсеміз" емес, не және неге өзгере түсетінін нақты көрсетіңіз: жаңа қолданушылар, жаңа сервистер, база өсуі, бейнебақылау қосу, ауыр есептер.

Екі саннан бастаңыз: қазіргі жүктеме және 12‑айға күтілетін өсу. Егер болжам анық болмаса, аралық беріңіз (мысалы, +30–50%) және қайта қарау күнін алдын ала белгілеңіз.

Қандай метрикалар маңыздырақ

Сценарийге байланысты 2–3 негізгі метриканы таңдаңыз. Сол кезде резерв нүктелі болады, барлық жерде «максимум» емес:

• CPU — параллель тапсырмалар, виртуализация, шифрлау, аналитика өсуі.
• RAM — кэштелер, дерекқорлар, VM/контейнер саны.
• IOPS және сыйымдылық — дискілер әдетте CPU‑дан бұрын таусылады.
• Желі — өткізу қабілеті және қосылымдар саны.

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

Жабық кеңістіктің шектеулері, апгрейдті бұзатындар

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

Қарапайым мысал: қазір 1GbE және жұп SSD жетеді, бірақ бір жылдан кейін филиалдар көбейіп, желі арқылы резервтеу өседі. Болжамда бірден 10/25GbE‑ге көшу және сақтау көлемінің өсуі көрсетіледі. Сол кезде ТЗ‑де порттар мен қораптарға резервті негіздеу оңай, ал бәрін бірден «ең үлкенін» сатып алудың қажеті жоқ.

Қадамдар бойынша: ТЗ‑де кеңейтілімділікті қалай рәсімдеу

«Ең қуатты нұсқа» емес, өсу жолын бекітіңіз: қазір не аламыз және платформа алмастырмай кейін не қосуға болатынын анықтаңыз.

Көп жағдайда жұмыс істейтін 5 қадам

1. Базалық конфигурацияны сипаттаңыз: ағымдағы тапсырмаларға жеткілікті минималды конфигурация, аздап резервпен, бірақ барлығы бойынша бірден «өсімге» емес.

2. 12–18 айға арналған мақсатты конфигурацияны бекітіңіз: платформаның қанша CPU, ОЗУ, дискі, желілік порт және қандай ускорительдерді қолдауы керек.

3. Талаптарды міндетті және опционалды түрде бөліңіз. Міндеттілер — болмаған жағдайда сервер қабылданбайды. Опционалды — кейін қосуға болатын нәрселер (мысалы, қосымша NIC немесе HBA) және олар жеткізілімнің автоматты түрде қымбаттауына әкелмеуі тиіс.

4. Кеңейтулердің үйлесімділігін бренд емес класс бойынша тексеріңіз: слоттардың түрі, диск форм‑факторлары, картаның биіктігі (full‑height/low‑profile), GPU‑ның ұзындығы, hot‑swap қолдауы, қуат пен салқындатуға резерв.

5. Жабдықталған жердің шектеулерін жазыңыз: стойка, PDU‑ға бөлінген қуат, талап етілетін төзімділік (мыс., 2 БП), және компоненттерді ауыстыруды кім орындайтынын анықтаңыз.

Одан кейін қабылдау критерийлерін бекітіңіз, сонда «кеңейтуге болады» сөзі уәде емес, тексерілетін факт болады.

Қабылдау критерийлері (жеткізу кезінде не тексереміз)

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

Мысал формулировка: "Сервер базалық конфигурацияда жеткізіледі, бірақ X дискіге дейін және Y карталарды орнатуға шасси мен аналық платаны ауыстырмай қолдау көрсетуі тиіс." Мұндай формат жеткізушіге немесе интеграторға (оның ішінде GSE.kz) ұтымды: ол өсу коридорын анықтайды және бюджеттік комплектацияларды келісуді жеңілдетеді.

PCIe слоттары: карталар мен ускорительдер үшін резервті қалай көрсету

PCIe — сервердегі кеңейту ұялары. Оларға желі карталары, HBA/RAID‑контроллерлер, ИИ‑ускорительдер және басқа карталар қосылады. Егер ТЗ‑де резерв жоқ болса, бір жылдан кейін апгрейд бюджет емес, жай ғана салмаққа тірелеуі мүмкін.

Маңыздысы — тек слот саны ғана емес, олар қандай және қаншалықты қолжетімді екені. x16 немесе x8 өлшемі үйлесімділік пен жылдамдыққа әсер етеді. Сондай‑ақ картаның физикалық ені (1‑slot, 2‑slot, 3‑slot) көрші слоттарды жаба ма, соны анықтайды.

Практикалық талаптар формулировкасы:

• Базалық конфигурация орнатылғаннан кейін минимум N бос PCIe слот болуы тиіс.
• Минимум 1 бос x16 (ускоритель үшін) және 1–2 бос x8 (желі немесе SAS/NVMe адаптер үшін).
• Қажетті биіктік/ұзындық карталарды қолдау және 2‑slot үшін орын жеткілікті болу (GPU қарастырсаңыз — 3‑slot талаптарын да көрсетіңіз).
• Слоттардың орналасуы мен райзер схемасын жеткізіңіз: қай слоттар жолдарды бөліседі және қандай конфигурацияда не ажыратылады.

Мысал: қазір 10GbE және бір контроллер жеткілікті, ал бір жылдан кейін 25GbE арқылы сақтау қосып, аналитика үшін GPU қою керек болуы мүмкін. Алдын ала 1 бос x16 және 1 бос x8 талап етілсе, апгрейд карталарды ауыстырумен шектеледі, платформа алмастырылмайды.

Дискілер: қорапшалар, hot‑swap және сақтау кеңею жолы

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

Егер сыйымдылық тез өсетін болса (архивтер, бейнебақылау, бэкап), әдетте 3.5 HDD және көпше қорапшаларды жоспарлау тиімді. Егер өнімділікке өсу басым болса (виртуализация, дерекқор, аналитика), SSD‑ке жол ашыңыз (көбіне 2.5: IOPS жоғары, бірақ ГБ‑ға қымбат). Көбінесе аралас нұсқа керек: ыстық деректерге SSD, суыққа HDD.

ТЗ‑де тек "қазір қанша диск" емес, "стартта қанша бос орын қалатындығын" да бекітіңіз. Мысалы: старт 4 диск, жүйені тоқтатпай кеңейту үшін минимум 4 бос орын қалуы керек сияқты.

Ашық түрде жазу керек нәрселер: жалпы қорапшалар саны және стартта қаншасы толы, hot‑swap талабы (тұрақтылық үшін), форм‑факторлар 2.5/3.5 және интерфейстер (SAS/SATA, NVMe қажет болса), таңдалған типке бэкплейн бар-жоғы, RAID‑контроллер немесе HBA үшін резерв пен орны.

Практикалық мысал: қазір 4 x 3.5 HDD файл сақтау үшін орнатылған, ал ТЗ‑де 8–12 қорапшыға арналған шасси және hot‑swap талап етіледі, сонда бір жылдан кейін жай дискілер қосып RAID немесе пулды кеңейтуге болады.

Жад: ОЗУ‑ны ұлғайту үшін модульдерді алмастырмай қалай сақтау

ОЗУ апгрейдінде жиі артық төлем модульдерді қайта құрастыру қажеттігінен емес, дұрыс слоты қалмағаннан болады. Сондықтан ТЗ‑де қанша ГБ қазір және қалай өсетіні ғана емес, өсу тәсілі де көрсетілуі тиіс.

Алдымен слоттарды көрсетіңіз. Жалпы DIMM‑слоттар санын және жеткізу кезінде минималды бос слоттар санын бекітіңіз. Бұл кейін тек модульдерді ауыстыру арқылы ғана өсуге мүмкіндік беретін конфигурацияларды алып тастайды.

Одан кейін ереже қойыңыз: ОЗУ ұлғаюы орнатылғандарды ауыстыруды талап етпей, қосымша модульдер арқылы жүзеге асуы керек. Бұл жеткізушінің кішірек планкалармен толық көлемді жасап, кейін оларды орнату мүмкін болмай қалатын жағдайдан қорғайды.

Жылдық мақсат пен нарастану қадамын көрсету пайдалы. Мысалы: қазір 256 ГБ, 12 айдан кейін 512 ГБ керек, қосымша қадамдар +128 ГБ болуы мүмкін. Осылай платформа арналардың теңгерімін сақтай отырып таңдалады.

Жеткізушіден платформа шекарасын сұраңыз: максималды ОЗУ көлемі және оған қалай жету (память типі, ранги, каналға модуль саны, жиілік шектеулері). Бұл «жұмыстайтын X ТБ дейін қолдау» деген жалпылама фразадан ұтымдырақ.

Егер сенімділік маңызды болса, ECC міндетті деп көрсетіңіз, ал memory mirroring немесе sparing тәрізді режимдер қажет болса — олар пайдалы, бірақ пайдалы көлемнің бір бөлігін алып қоятынын есептеңіз.

Мини‑шаблон талаптар:

• Базадан кейін кемінде N DIMM‑слот; жеткізу кезінде кемінде M слот бос болуы тиіс.
• Бастапқы конфигурация: X ГБ; 12 айдан кейінгі мақсат: Y ГБ.
• Y ГБ‑ға апгрейд қосымша модульдермен орындалуы тиіс, орнатылғандарды ауыстырусыз.
• Платформаның максимумы және оны алу шарттары көрсетілуі тиіс.
• ECC міндетті; жадының төзімділік режимдері қажет болса көрсетіңіз.

Мысал: виртуализацияға арналған сервер үшін 256 ГБ (8x32) алып, жеткізуде минимум 8 бос слот қалдырып, бір жыл ішінде тағы 8x32 қосып 512 ГБ‑қа жетуге болады, орнатылған модульдерді ауыстыру қажет емес.

Қуат: резерв, ватт бойынша қор және БП‑қа талаптар

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

Алдымен резервтеуді таңдаңыз. Критикалық сервистер үшін көбіне 1+1 (әр БП барлық жүктемені көтере алады). Аз критикалық жүйелер үшін N+1 қолайлы, мұнда бір БП топқа резерв ретінде беріледі. БП‑ның біреуінің істен шығуы серверді тоқтатпауы тиіс.

Содан кейін санмен ватттық қор қойыңыз. Қазір есептелген жүктемені және апгрейдтен кейінгі мақсатты көрсетіңіз. Көбінесе болашақ PCIe‑карталарға, қосымша дискілерге және CPU тұтынуына 20–30% үстеме қалдыру ақылға қонымды. Мысал: қазір пикте ~450 Вт болса, бір жылда 2 NVMe және желі картасын қосу жоспарланса, 650–750 Вт пикке есептелген қуат талап ету орынды.

Стойкаға үйлесімділікті де ұмытпаңыз: питания кіріс түрлері (AC, 220В), кабель саны, штепсель типтері және PDU‑ға қойылатын талаптар. Қағазда бұл кішігірім нәрсе көрінсе де, енгізуде жиі кідірістердің себебі.

ТЗ‑ге қысқа блок талаптар:

• БП резерві: 1+1 немесе N+1, бір БП істен шыққанда жұмыс істеуі сақталуы тиіс.
• БП горячая замена (hot‑swap) және ақауды көрсету (LED/басқаруда оқиға).
• Жалпы қуат пен рұқсат етілген пик (Вт) болашақ кеңеюді есепке ала отырып.
• Егер стойка лимитіне сай келу керек болса, power cap (Вт) шектеуі.
• КПД класы: мысалы, 80 PLUS Platinum сияқты нақты талап.

Желі: порттарға резерв пен жоғары жылдамдыққа өту жолы

Желі ТЗ‑де көбіне «қалай бар» деп көрсетіледі (мыс., 2x1G), ал бір жылдан кейін резервтік көшіру, репликация немесе сақтау үшін жеке арналар қажет болуы мүмкін. Қазіргі схеманы және бір қадам кейінгі өсу: қандай жылдамдықтар мен порттар қажет болатынын сипаттаңыз.

Жақсы формулировка «қазіргі желі» және «өсу үшін желі» ретінде басталады. Мысалы: қазір 2x10G жеткілікті, бірақ бір жылдан кейін 25G‑ге өту және репликация үшін бөлек желі керек болады. ТЗ‑де базалық порттар 10G болуы мүмкін, бірақ сервер платформа алмастырмай 25/40/100G адаптерлерді қосуға мүмкіндік беруі тиіс.

Тек «қанша порт керек» емес, жеткізілгеннен кейін қанша бос порт қалуы керек екенін де көрсетіңіз. Әйтпесе кез келген өсу қайта жобалауға айналады.

ТЗ‑де нақты не жазуға болады

Бірнеше нақты пункт жеткілікті:

• Минимум порттар және резерв: стартта қанша порт бос және қанша орын алынды.
• Апгрейд сценарийі: қазір 10G, кейін 25G‑ке өту мүмкіндігі (қосымша NIC орнату арқылы).
• NIC үшін PCIe талаптары: қажетті форматтағы бос слот және сигнал/орын конфликтілері жоқтығы.
• Басқару порты (out‑of‑band), қажет болса.
• Желілерді бөлу: минимум екі желі (пайдаланушы және резерв/репликация) бөлек порттармен.

Мысал: медорталықта күндіз пациент базасымен жұмыс, түнде сақтық көшірме орын алады. Егер бәрі бір 10G‑ке түссе, түнгі терезелер ұзартылады, күндіз кешігулер пайда болады. Қосымша порттар және 25G‑ке резерв серверді ауыстырмай шешеді.

ТЗ‑де серверді резервпен алуға қатысты жиі қателер

Негізгі қате — «барлығын максимумға алу» орнына 12–18 айдан кейін нақты не қосылатынын сипаттамау. Нәтижесінде платформа қымбатқа түседі, ал апгрейд үшін қажетті нәрселер (бос слоттар, отсеңдер, қуат қоры) бекітілмей қалады.

Не себепті қосымша төлем немесе тартымды шешімге ұшырайды:

• "Қандай да бір жағдайға" максималды сипаттамаларды сұрайды, бірақ өсу сценарийін жазбайды (мысалы: 2 NVMe, екінші желі карта, GPU, +256 ГБ ОЗУ қосамыз).
• Физиканы елемейді: сервер биіктігі (1U/2U), тереңдігі, кабельдерге орын, PCIe карттарының ұзындығы және салқындату.
• Қуат пен салқындатудың қорын есептемейді: қазір жұмыс істейді, бірақ диск немесе GPU қосқанда шектеуге ұшырайды.
• Бүкіл опцияларды бірден сатып алады, кейде дұрыс шасси (қорапшалар, слоттар, екінші БП) алып, дискілер мен карталарды кейін сатып алған тиімдірек.
• Қабылдауды бекітпейді: базалық қойылымнан кейін қанша бос PCIe, бос қорапшалар, қандай порттар бар, БП схемасы және ватттық резерв қанша — бұлар жазылмайды.

Қарапайым мысал: виртуализацияға арналған сервер үшін "қазір" деп жазсаңыз, ТЗ‑де бір жылдан кейін 2–4 SSD және екінші 25G желі картасын қосу жоспарланатынын ашық жазған жөн. Сол кезде жеткізу кезінде (мыс., GSE‑ның S200 Series) физикалық түрде бос отсеңдер, сәйкес райзер/слоттар және жеткілікті БП резерві бар‑жоғын тексеруге болады.

Қысқа чек‑лист (Көшіріп алып бейімдеңіз)

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

• PCIe (карталар мен ускорительдер): базалық карталар орнатылғаннан кейін кемінде X бос PCIe слот; версия/жылдамдықты (мыс., Gen4/Gen5), форм‑факторды (Full‑height/Low‑profile) және слот физикалық қолжетімді болуын талап ету.
• Дискілік жүйе (отсектар және корзиналар): жалпы X отсең, соның ішінде стартта кемінде Y бос; дискі түрлері (2.5"/3.5", SAS/SATA/NVMe), hot‑swap (иә/жоқ), сәйкес корзиналар/бэкплейн болуы.
• ОЗУ (модульдерді ауыстырмай өсу): жалпы X слот, стартта кемінде Y бос; старттық көлем A ГБ, 12 айда мақсат B ГБ; B ГБ‑қа өсу орнатылған модульдерді ауыстырмай жүзеге асуы тиіс.
• Қуат (ватт бойынша қор және төзімділік): резервтеу (мыс., 1+1), hot‑swap (иә/жоқ); ағымдағы есептелген тұтыну P Вт және болашақ өсу үшін талап етілетін кем дегенде Z% запас.
• Желі (старттағы порттар және апгрейд): стартта порттар: N x 1GbE/10GbE/25GbE; кеңейтуге дейінгі мақсат S GbE (бос PCIe немесе модуль арқылы) және апгрейдтен кейінгі порт саны талап етіледі.

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

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

Ұйым ішкі жүйені іске қосады: бастапта 120 қолданушы, бір жылдан кейін 250–300 күтіледі, сонымен бірге аналитика модулі пайда болады. Бюджет шектеулі, бірақ бір жылдан кейін платформаны ауыстыруға болмайды.

Бастапқыда бір процессор (немесе минималды қажет серия), ағымдағы жүктемеге арналған ОЗУ сәл резервпен, дискілер жұмыс көлеміне ғана, желі 10G (бір порт) және GPU қажет емес. Мақсат — қазір темір үшін артық төлем жасамау.

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

ТЗ‑де кеңейтілімділікті түсінікті әрі тексерілетін ету үшін талаптарды екіге бөліңіз:

• Қазір жеткізіледі: ағымдағы CPU/ОЗУ, нақты дискілер саны, орнатылған желі адаптері, блоктар.
• Платформаның дайын болуы: қажетті форм‑фактортағы бос PCIe слоттар, бос дискі отсеңдері және сәйкес корзиналар, БП‑дағы ватттық резерв, екінші CPU қою мүмкіндігі (егер жоспар болса), жоғары жылдамдықты желі карталарын қолдау.

Қабылдауда сөзбен емес нақты фактілерді сұраңыз: қанша PCIe слот шынайы бос және жабық емес, қанша дисктік отсең қолжетімді және hot‑swap бар ма, БП‑ның қандай қуаты және резерві бар, қандай желілік порттар шыққан және қандай карталарды орнатуға болады шасси алмастырмай.

Келесі қадамдар: ТЗ‑ні тез келісіп, платформаны таңдау

Келісуді апталарға созбау үшін шешімдерді "қазір + бір жылдан кейін" форматында қысқа құжатқа жинаңыз. Ол қайда резерв керек екенін бірден көрсетеді.

1 бетке негізгі сандарды салыңыз: старттық және мақсат конфигурациялар (CPU, ОЗУ, дискі, желі), орын шектеулері (U, қуат, тип питания, шудың/температура талаптары), іске қосу мерзімі және жоспарлы апгрейд, төзімділік талаптары және не қазір, не опция ретінде алынады.

Содан кейін талаптардың өлшенетінін тексеріңіз. "Резервпен" дегеннің орнына "кемінде" деп жазыңыз: қажет PCIe слоттары саны, отсеңдер саны және корзиналар типі, ватт бойынша минималды запас және БП схемасы, порттар саны және қолдау көрсетілетін жылдамдықтар.

Сатып алудан бұрын эксплуатациямен чек‑листті келісіңіз: PDU және питания енгізулері жеткілікті ме, стойкада орын бар ма, компоненттерді кім ауыстырады, қажет пе сырғылық бекіту, кепілдік қызметі қалай ұйымдастырылады.

Интегратордан немесе өндірушіден жазбаша растау сұраңыз: жоспарланған апгрейдтер платформамен үйлесімді ме (нақты диск модельдері, HBA/RAID, желі карталары, GPU, екінші процессор). Егер Қазақстанда жеткізу және қолдау маңызды болса, бұл GSE.kz-пен талқыланып, спецификациямен расталуы мүмкін.