VDI/RDS үшін ресурстарды есептеу: пайдаланушыға CPU, RAM және IOPS

Қай мәселе шешіледі және VDI/RDS көбінесе қайда «тапталады»

VDI/RDS жиі «жалпы күш жеткіліксіз» болғандықтан баяуламайды — көбіне дәл сол уақытта бір нақты ресурс жетіспейді. Сондықтан бір пайдаланушының тұтынуын және оның профилін есептеп, содан кейін одновременностьке көбейту және запас қосу тиімдірек. Бұл CPU 40% жүктелгенмен, пайдаланушылар диск немесе желі салдарынан лагқа шағымданатын жағдайлардан сақтайды.

Бірдей пайдаланушылар саны әртүрлі жүктеме береді. 50 офис пайдаланушысы мен 50 адам, күн бойы ондаған қойындыларды, ауыр порталдарды және видеошақыруларды ұстайтын пайдаланушылар — CPU, RAM және диск әрекеттері бойынша мүлдем басқа талаптар қояды. RDS (терминалдық сервер) — бір ОС-пен бөліседі, сондықтан шоқтар жиі «қосылады». VDI-де әркімнің жеке виртуалды машинасы болғандықтан, жады мен дискке бастапқы талаптар әдетте жоғарырақ.

Практикада тар шектеу көбіне төрт қабаттың бірінде орналасады: CPU (пиковые секундтарда есептеу жетіспейді), RAM (подкачка басталады және бәрі «ұзады»), диск (латенттілік өседі, логиндер мен профильдер баяу ашылады) немесе желі (орташа бойынша «жетеді» сияқты, бірақ сапа латенттілік, жоғалтулар немесе Wi‑Fi арқылы нашар болады).

Орташа көрсеткішке қарамаңыз — пиковые мәндер мен "хвосттар" маңызды. Мысалы, орташа диск латенттілігі 3 мс қалыпты көрінуі мүмкін, бірақ егер 95-перцентильде таңертеңгі кіргенде ол 25–40 мс болса, пайдаланушылар «қара экран» пен ұзақ жүктелуді көреді. Желідегі жағдай да солай: орташа трафик аз, бірақ қысқа жарылыстар мен пакет жоғалтулар интерфейсті тұрады.

Типтік сценарий — оқу сыныбы немесе мемлекеттік мекеме, мұнда 60 адам шамамен бір уақытта кіреді. Егер хосттар мен сақтау осы шыңды көтермесе, шағымдар «жақсы жалпы көрсеткіштер» болса да болады. Логика қарапайым: профильдер мен жүйенің қай жерде таяп қалғанын көрсететін метрикаларға сүйеніңіз.

Негізгі қабылдаулар: VDI vs RDS және кімді "пайдаланушы" деп санау

VDI мен RDS жиі бірдей есептелуге тырысады, бірақ бұл әртүрлі модельдер.

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

Алдын ала шешіңіз: жұмыс орындары persistent (тұрақты) немесе non-persistent (тұрақсыз) болады ма. Persistent — кәдімгі ПК сияқты: профильдер мен бағдарламалар жиналады, диск фоне өседі және сақтау көлемі ұлғаяды. Non-persistent оңай басқарылып, жаңартуға ыңғайлы, бірақ таңертеңгі массовый кірістер сияқты шыңдар сезгіш келеді және профильдермен мұқият жұмыс талап етеді.

Қауіпсіздік пен басқару агенттерінің накладные шығындарын бөлек ескеріңіз: антивирус, шифрлау, DLP, EDR, инвентаризация, сондай‑ақ жоспарлы жаңартулар. Олар CPU, RAM және әсіресе дисктік операцияларды қосады. Егер бұл компоненттер міндетті болса, оларды тұрақты қосымша ретінде қарастырыңыз, ал жаңартулар мен жоспарлы сканерлеулерді бөлек шыңдар ретінде есептеңіз.

Кейіннен анықтаңыз, кімді "пайдаланушы" дейсіз. Жоспарлау үшін белсенді сессия (адам дәл қазір жұмыс істеп отыр) мен пассивті сессияны (сессия тұр, бірақ іс‑әрекеттер аз) ажырату пайдалы. Тағы бар — пик сценарийі: максималды жүктеме кезеңі (таңғы кіру, ай соңында, веб‑қосымшаны жаппай іске қосу).

Кілт параметр — одновременность коэффициенті: барлығының қанша бөлігі бір уақытта белсенді. Мысалы, ұйымда 300 қызметкер болса да, пикте 180 белсенді болуы мүмкін — коэффициент 0,6. Әдетте дәл осы саннан CPU, RAM және IOPS есептеледі, барлық штаттық саннан емес.

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

Типтік профильдер: офис пен ауыр веб‑қосымшалар

Есепті бастапқыда темірден емес, адамдардың нақты қалай жұмыс істейтінін анықтаудан бастаңыз. Бірден vCPU мен IOPS‑ты шамаламаңыз. Алдымен 2–3 профильді анықтап, оларды өлшенетін әдеттерге байлаңыз.

Офис профилі әдетте болжамды: пошта, құжаттар, 5–15 қойынды, мессенджер, кейде басып шығару. Жүктеме біркелкі, ауыр файлдарды ашқанда немесе массовый кірістерде қысқа шоқтар бар.

"Ауыр веб" профилі сырттай ұқсас, бірақ басқаша жұмыс істейді: 20–60 қойынды, CRM/ERP, BI‑дашбордтар, беттердің тұрақты жаңартылуы, шолғыш кеңейтімдері, сонымен бірге видеошақырулар. Мұнда шоқтар жиі болады (рендеринг, кодектер, графикалар) және дисктік латенттілік белсенді профильдерде әсер етеді.

Дизайн және инженерлік қосымшаларды (CAD/3D, визуализация) ортақ "офис" профилімен араластырмаңыз. Бұндайдар үшін жиі GPU, көбірек видеожад пен желіге басқа талаптар керек. Мұндай профильді бөлек есептеп, пилотпен тексерген дұрыс.

Профильді сипаттау үшін әдетте бірнеше параметр жеткілікті: қанша қойынды және беттер қаншалықты ауыр (CRM, BI, карталар), файлдармен қаншалықты жиі жұмыс (ашу, сақтау, автосейв), басып шығару немесе сканерлер бар ма, видеошақырулар қаншалықты жиі және шоқтар қай сағаттарда болады.

Деректерді «көру арқылы» жинамаңыз. Қысқа сауалнама мен бірнеше жұмыс орнына жылдам өлшеулерді біріктіріп, содан кейін нақты қосымшалар мен профиль саясаттары бар шағын топтағы пилотпен растап алыңыз. "Жаман күндерді" (ай жабу, массовый жиналыстар) бөлек сценарий ретінде бекітіңіз.

Мысалы: бухгалтерия айдың үш аптасында «офис», ал ай соңында есеп провайдерлері және BI себепті «ауыр вебке» айналады. Мұны есептемесеңіз, жүйе ең маңызды сәтте күрт баяулайды.

CPU: пайдаланушыға қанша vCPU есептеу — болжамсыз тәсіл

VDI/RDS‑те vCPU пен хосттағы нақты жүктемені ойлаған ыңғайлы. Бір vCPU — бұл физикалық ядролардың есептеу уақытының бөлшегі. Мақсат — қанша бір уақытта белсенді пайдаланушыларға қажеттілікті түсініп, шыңдарға запас ұстау.

Орташа CPU пайыздары алдауы мүмкін. Сессия орташа 10% тұтынған болса да, ауыр қойынды немесе Teams іске қосылғанда 5–10 секундқа 80–100%‑ға секіріп кетуі мүмкін. Осындай жарылыстар жауап беру уақытын бұзады: курсор тартылғыш, дыбыс тұрып қалады, интерфейс "жабысады". Сондықтан 95-перцентиль жүктемеге және сезімтал жауапқа назар аударыңыз, әдемі орташаға емес.

Бастапқыда мына бағыттамаға сүйеніңіз, кейін өлшеулермен растап алыңыз:

• Офис (почта, құжаттар, 5–10 қойынды, мессенджер): пайдаланушыға 1–2 vCPU.
• Ауыр веб (CRM/BI, көп қойынды, видеоқоңыраулар): 2–4 vCPU пайдаланушыға.

Одан әрі фонға арналған запас қосыңыз: жаңартулар, индексация, антивирус, телеметрия. Хостта жұмыс уақытында 15–25% бос CPU сақтау практикалық.

Егер vCPU‑ны көбейтсеңіз де тормоздар қалса, жиі себеп диск күтуі немесе RAM жетіспеушілігі болады. Қарапайым белгі: CPU төмен, бірақ қолданбалар баяу ашылады, логон минуттар алады, метрикаларда диск кезегі немесе своп өседі.

Мини‑мысал: RDS‑те 60 офис пайдаланушысы. Бастапқы баға — пайдаланушыға 1.5 vCPU, яғни жалпы 90 vCPU. Егер 2 хостқа жоспарласаңыз, әрқайсында шыңға және фонға шамамен 20% запас қалатын етіп таратыңыз, әйтпесе таңертеңгі толқын жауап уақытын бұзады, орташа жүктеме қалыпты болып көрінуі мүмкін.

RAM: қанша жады және свопқа жол бермеу

Жады жиі хосттағы пайдаланушылар тығыздығының басты шектеуі болады. CPU қысқа шыңдарды «сақтай» алады, бірақ RAM жетіспесе, подкачка басталып, латенттілік өсіп, пайдаланушылар CPU қалыпты болғанда да тормоз сезінеді.

Офис профилі көбіне шолғыш пен фондық агенттерге тәуелді: қойындылар, мессенджер, пошта, антивирус, DLP/EDR, басып шығару клиенті, синхрондау. "Ауыр" веб қосымшалар үлкен JS‑пен жағармай қойындылар қосады, кэш, рендеринг және кейде кіріктірілген видеоконференция. RDS‑те жады қолданушылардың бірдей қосымшаларына байланыстырақ (ортақ кітапханалар көмектеседі), ал VDI‑де әр VM өз ОС пен қызметтерін «тасиды».

Хост немесе VM pagefile/swap‑ты белсенді қолдана бастаса, жүктеме сақтау қабатқа көшеді. Бұл әдетте IOPS пен диск латенттілігінің өсуіне әкеледі, нәтижесінде логиндер, профильдер мен қолданбалар қатты баяулайды. Ара‑қатар бұл «дисктік мәселе» сияқты көрінуі мүмкін, бірақ тамыры — RAM төмен бағалау.

Практикалық тәсіл — жадыны қабаттап есептеу және бірден запас қосу: ОС пен қызметтер базасы, профильге қосымша (қолданбалар мен шолғыш сценарийі), қауіпсіздік агенттеріне қосымша, және тағы 15–25% өсімге запас.

Профильдерге арналған нұсқаулар: офис пайдаланушысы 8–12 қойынды, пошта мен мессенджер болғанда көбіне 2–3 ГБ тұрақты алады; "ауыр веб" сценариі видеошақырулармен бірге 4–6 ГБ алады. Бұл мәндерді пилотпен тексеріп, 95-перцентиль бойынша есептеңіз, күнделікті свопқа жол бермеу үшін.

Диск: IOPS есептеу және логон‑штормнан қорғау

IOPS — секундқа операциялар саны, бірақ VDI/RDS үшін көбіне маңыздысы — латенттілік (latency). Латенттілік көтерілсе, сессиялар «тұрып қалады», ал IOPS есептерде «қалыпты» көрінуі мүмкін.

Дисктік жүктеме сирек бірқалыпты болады. Бар steady‑state (күндізгі әдетті жұмыс) және қысқа бөркі: таңертеңгі массовый кіріс, жаңартулар, антивирустық сканер, кэшттердің қайта жасалуы. Егер сақтау тек орташа көрсеткіштерге есептелсе, логон‑шторм диск кезегіне тез тап болады.

Негізгі жазбалар көзі — пайдаланушы профильдері, TEMP, шолғыш кэші, пошта клиенттері, журналдар, сондай‑ақ фондық процестер (антивирус, индексатор). "Ауыр вебте" үлкен кэштер мен жиі ұсақ жазбалар қосылады.

Жалпылама есеп үшін шамалар:

• Офис: steady‑state‑та пайдаланушыға 5–15 IOPS, логин шоғында 30–60 IOPS.
• Ауыр веб: steady‑state 10–25 IOPS, логин кезінде 50–100 IOPS.

Содан кейін одновременностьке көбейтіңіз. Мысалы, 200 офис пайдаланушысы күні бойы 10 IOPS‑тан болса, шамамен 2000 IOPS керек болады, бірақ 60 адам 5–10 минут ішінде кірсе, шыңға запас қажет және, ең бастысы, төмен латенттілік.

Логон‑штормға қарсы әдетте көмектесетін шаралар: VM‑ның жүйелік дискісі мен пайдаланушы профильдерін бөлу (FSLogix қоса), кэш пен TEMP шектеу және жаңартуларды, сканерлерді пиктен тыс уақытқа ауыстыру. Бұл бір диск ресурсына бәсекелестікті азайтады.

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

Желі: қанша Мбит/с керек және қалай "тормоздар" болдырмау

VDI/RDS‑те желі орташа өткізу жолағын «аяқтайды» деу сирек. Әдетте мәселе — шыңдар, латенттілік немесе жоғалтулар. Сондықтан есепте тек Мбит/с емес, арнаның сапасын да ескеріңіз.

Дисплей протоколының трафигі (көп жағдайда RDP) экрандағы өзгерістерге және қай құрылғылар өтуіне байланысты. Бір офис пайдаланушы тыныш жұмыс кезінде шамамен 0.3 Мбит/с тұтынуы мүмкін, ал видеошақыру кезінде 3–6 Мбит/с дейін өседі.

Өткізу қабаты жоғары пиктерде өседі: көп пиксель өзгерісі, медиа (видео, аудио), басып шығару/сканерлеу, USB‑редирект, екі монитор мен жоғары резолюция.

Шамалап келесі диапазондар:

• Офис: пайдаланушыға 0.5–1.5 Мбит/с.
• Ауыр веб: 1.5–4 Мбит/с.
• Құралды видеоқоңыраулар жиі болса: 3–6 Мбит/с.

Арнаны орташа емес, пик бойынша есептеңіз: белсенді түрде бір уақытта қанша пайдаланушы болатынын (мысалы, 60–70%) алып, 20–30% запас қосыңыз. Сонымен қатар латенттілік пен жоғалтуларды тексеріңіз. Көбіне RTT 30–50 мс және жоғалтулар 0.5%‑тан төмен болғаны қолайлы.

Егер «тормоздар» филиалдан ғана келсе, сегментация мен приоритизация көмектеседі: пайдаланушы сессиясы бөлек, басқару мен мониторинг бөлек, сақтау трафигі бөлек (RDP‑мен бәсекелеспесін), резервтік көшірме жоспарлы түрде және шектеулерімен жүргізілуі тиіс.

Қадамдап есептеу: пайдаланушы профилінен хост конфигурациясына дейін

Жұмыс схемасы келесідей:

1. 2–4 профиль сипаттаңыз (мысалы: офис, ауыр веб‑қосымшалар, 1С/ERP, дизайн) және одновременность коэффициентін беріңіз. Көбінесе бұл барлық есептерден 50–80% шамасында болады.

2. "Қалыпты жұмыс істейді" дегеннің не екенін алдын ала анықтаңыз: логин уақыты, қолданба жауап беруі, диск пен желінің рұқсат етілген латенттілігі. Бұл сіздің ішкі SLA‑ңыз болады.

3. Әр профиль үшін пайдаланушыға қажеттілікті бағалаңыз: vCPU, RAM, IOPS (және логин кезіндегі шыңдар), сондай‑ақ орташа және шыңдық трафик.

4. "Пайдаланушыдан" "хост/кластерге" аударыңыз: одновременностьке көбейтіп, платформа накладные шығындарын (гипервизор, брокер, антивирус, мониторинг) қосыңыз, кейін тар шектеулердің қайда екеніне қарап тексеріңіз.

5. Запас қосыңыз: жүктеменің өсуі (+20–30%), түйіннің істен шығуы (N+1), қызмет көрсету (патчтер, қайта жүктеу) және таңертеңгі логон‑штормға арналған қосымша қор.

Қысқа мысал: 120 офис пайдаланушысы және 30 «ауыр веб» пайдаланушысы болса, одновременность 70%: ресурстарды 150 емес 105 белсенді сессияға есептейсіз. CPU мен RAM шамамен сызықты өседі, ал диск пен желі көбіне белгілі бір сағаттарда қатты шыңдар береді.

Соңғы әрі міндетті қадам — пилот. 10–20% мақсатты жүктемемен іске қосып, CPU, RAM, IOPS, диск пен желінің латенттігін жинаңыз, қай жерде «қызылға» өтетінін қараңыз. Пилоттан кейін цифрлар көбіне өзгереді, әсіресе диск пен логин уақыты бойынша.

Нақты сандармен мысал: аралас офис + ауыр веб

Сценарий: 120 пайдаланушы, оның 80‑і офис (почта, құжаттар, 10–20 қойынды) және 40‑ы ауыр веб (көп қойынды, видеоқоңыраулар, BI).

CPU және RAM: шыңдар мен запас ескеріліп есептеу

Бастапқы нормалар (старт үшін, кейін пилотпен растаңыз):

• Офис: орташа 0.3 vCPU және пикте 0.6 vCPU; RAM 1.8 ГБ.
• Ауыр веб: орташа 0.6 vCPU және пикте 1.2 vCPU; RAM 3.5 ГБ.

Пиктегі CPU: 80 x 0.6 + 40 x 1.2 = 48 + 48 = 96 vCPU. 20% запас қосамыз: 96 x 1.2 = 115 vCPU.

RAM: 80 x 1.8 + 40 x 3.5 = 144 + 140 = 284 ГБ. ОС/қызметтер/кэш үшін 15% қоссақ — шамамен 327 ГБ. Практикада кластерді жобалау кезінде бір түйіннің істен шығуын ескеріп, жады бойынша да запас қалдыру керек.

IOPS пен желі: күндізгі және массовый кіру

Күндізгі диск жүктемесін шартты түрде алайық: офис 5 IOPS, ауыр веб 10 IOPS. Жиынтық: 80 x 5 + 40 x 10 = 800 IOPS.

Логон‑шторм (алғашқы 5–15 минут) жиі 5–10 есе қаттырақ болады. Егер офиске 50 IOPS және ауыр вебке 80 IOPS қабылдасақ: 80 x 50 + 40 x 80 = 7200 IOPS. Мұнда маңыздысы тек IOPS емес, латенттіліктің төмен болуы: егер latency өссе, пайдаланушылар CPU қалыпты болғанда да тормозды көреді.

Желі: қашықтан қолжетімділік үшін орташа тұтынуды офиске 0.2 Мбит/с, ауыр вебке 0.4 Мбит/с деп алайық: 80 x 0.2 + 40 x 0.4 = 32 Мбит/с. Пик үшін 3 есеге көбейтіп, 30% накладное қоссаңыз — шамамен 125–130 Мбит/с. Филиал үшін бұл жиі 150–200 Мбит/с арнасы мен VDI/RDS‑трафикке приоритет қажет екенін білдіреді.

Не масштабтау керектігін симптомдардан анықтаңыз:

• CPU пикте 80–90% және диск латенттілігі қалыпты болса — есептеулерді көбейтіңіз немесе ауыр рөлдерді бөлек пулға шығарыңыз.
• RAM шегіне жақын және своп пайда болса — жады қосыңыз, автозапуск пен фондық агенттерді тазалаңыз.
• Логинде диск латенттілігі жоғары болса — SSD-қабатты күшейтіңіз, профильдерді қайта қарастырыңыз және I/O‑ны пулдарға бөліңіз.
• Филиалдардан ғана шағымдар болса — желіні, QoS пен арнаның тұрақтылығын тексеріңіз.

VDI/RDS жоспарлауда жиі болатын қателіктер

Ең қымбат қателік — барлығына бір «максималды» ресурсты тағайындау. Нәтижесінде CPU мен RAM‑қа артық ақша жұмсайсыз, ал нақты тар шектеу диск немесе желі болып қалады.

Екінші қателік — орташа жүктемеге сүйену. Орташа бойынша бәрі жақсы көрінгенімен, таңертеңгі және есептік шоқтарда жүйе баяулайды. VDI/RDS үшін маңыздысы — 95‑ші перцентиль және шыңдар.

Көбіне жаппай кіру мінезін аз бағалаған болады. Логон‑шторм — бұл тек сессияларды іске қосу емес, сонымен бірге профильдерді оқу, саясаттарды қолдану, фондық агенттерді бастау, жаңартуларды тексеру және сканерлеу. Диск қатты қысқа, бірақ қатал IOPS‑қа ұшырайды.

Соңы: барлығына бірдей ресурсты беру, орташа бойынша жоспарлау, шыңдарды ескермеу, профильдерді үлкейтіп жіберу, сессияларды дұрыс бөлмеу, диск латенттігін және желі сапасын бақыламау. Мысал: 09:00‑де 80 қызметкер бірден кірсе, антивирустық жаңартулар басталса және профильдер бірнеше ГБ‑ға ұлғайса, тіпті CPU жақсы хосттар да диск салдарынан «тоқтап» қалады — пайдаланушы бұлты логиннің баяулауы, браузердің ұстап қалуы және қолданба кешігуі ретінде көреді.

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

Жабдық сатып алмас бұрын немесе кластерді кеңейтер алдында жылдам тексеріс жасаңыз:

• CPU: шыңдар мен фондық тапсырмаларға запас бар ма (антивирус, индексация, жаңартулар).
• RAM: ең жүктелген сағатта свопсыз жеткілікті жады бар ма.
• Диск: IOPS‑ты ғана емес, нақты жүктемедегі латенттілікті өлшейсіз бе.
• Желі: филиалдар мен VPN арқылы пайдаланушыларға арналған өткізу қабілеті мен RTT‑ні тексересіз бе.
• Шыңдар: таңертеңгі массовый кіру, жаңартулар мен есептік кезеңдерді бөлек есептейсіз бе.

Егер бір нәрсе шегінде тұрса, «әрине өтіп кетеді» деп үміттенбеңіз. VDI/RDS‑те деградация көбінесе тізбекті түрде жүреді: диск баяулайды, кезек өседі, сессиялар ауырлайды және жүйе CPU жетіспейтіндей көрінеді.

Келесі — төзімділікті тексеріңіз. Көп жобада құтқаратын минимум — N+1: бір түйін істен шықса да, пайдаланушылар жұмысты қолайлы жылдамдықпен жалғастыра алады. Қызмет көрсетусіз жаңартуларды, гипервизор патчтарын, диск ауыстыру мен бэкаптарды жоспарлап, сынап отырыңыз.

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

Практикалық келесі қадам — өндірістік саясаттар, профильдер мен қосымшалар бірдей 10–20 пайдаланушыға пилот. 1–2 апта ішінде логон‑шторм, IOPS‑тың шыңдары, диск латенттігі мен желі мінезін көресіз және сенімді метрикалар бойынша масштабтайсыз.

Егер есептерді тез нақты конфигурацияға аудару керек болса, сервер платформасын жеткізетін және инфрақұрылымды жобалайтын мамандармен бірге жұмыс істеу ыңғайлы. Мысалы, GSE.kz сервер өндірушісі және жүйелік интегратор ретінде Қазақстанда VDI/RDS үшін серверлерді және түйіннің істен шығуына және шыңдық жүктемелерге арналған запас жоспарлауға көмектесе алады — "ядроларды әрең сатып алу" қажеттілігінсіз.