SAP HANA сервері: жад, желі және сертификациялар бойынша чек-лист

Енгізуді бастамас бұрын чек-лист қандай мәселелерді шешеді

SAP HANA үшін серверді көбіне таныс метрикалар бойынша таңдайды: көбірек CPU, «жылдам дискілер» және қуат блоктарына резерв. Бірақ шектеулер әдетте кейінірек шығады, аппараттық құрал сатып алынғаннан кейін оны өзгерту қиын болады. Енгізуді бастамас бұрын жасалған чек-лист тар шектерді алдын ала көруге және «бәрін сатып алғанбыз, бірақ ол дұрыс іске қосылмайды» жағдайына түспеуге көмектеседі.

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

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

Қарапайым мысал: компания «CPU-ға резерві бар» сервер сатып алды, бірақ минималды RAM және бір резервсіз желі картасын орнатты. Жүктеме тесттерінде төмендеулер байқалды, ал порт істен шыққанда қызмет тоқтап қалды. Оны түзету үшін жады сатып алып, желі схемасын өзгертіп, дизайнды қайта келісу қажет болды.

Бастапқы талаптарды жинау — конфигурацияны сонда ғана қарау керек

Бірінші қадам — аппараттық құрал емес, нақты талаптар тізімі. SAP HANA талаптарды және сценарийді алдын ала айқындамаса, әлдеқайда жақсы серверді де қате таңдауға болады.

Алдымен жүктеме түрін анықтаңыз. ERP мен S/4HANA әдетте көп транзакциялар береді және кешігулерге сезімтал. BW мен аналитика көбіне жад көлемінде және параллель сұрауларда шектеледі. Аралас жүктемелер әдетте ресурстарды резервтеуді талап етеді — бір бөліктің шыңы екіншісінің өнімділігін «жеп» кетпеуі үшін.

Содан кейін жадтағы деректер мен өсу болжамын бағалаңыз. Қазіргі көлем ғана емес, 1–3 жылға арналған болжам: жаңа модульдер, пайдаланушылар санының өсуі, тарихтың ұлғаюы маңызды. Бизнес үшін қабылдаылатын шекті жағдайды (мысалы, жады 12 айда толса не істейміз) алдын ала бекіту пайдалы — кеңейтеміз бе, деректердің бөлігін жылжытамыз ба, әлде сервер классін өзгертеміз бе.

Қолжетімділік талаптарын бөлек келісіңіз. Жоспарлы жұмыстарға рұқсат етілген тоқтау терезесін және RPO/RTO мақсаттарын жазыңыз. Бұл схема таңдауына (жалғыз сервер, кластер, репликация) тікелей әсер етеді, демек желі, сақтау және бюджетке.

Контурлар санын ұмытпаңыз: қанша жүйе болады (prod, QA, dev, sandbox, оқыту). Жиі қате — тек продқа арналған аппарат сатып алу, ал қалған жүйелерді басқа ресурстарға «шеттеу», нәтижесінде тест пен релиз барысында проблемалар туындайды.

Соңында сақтық көшірлеу мен DR-ды алдын ала айқындаңыз: бэкаптар қай жерде сақталады, қаншалықты жиі жасалады, қалпына келтіру қалай тексеріледі, екінші сайт керек пе.

Қысқа бастапқы мәліметтер тізімі, осысыз конфигурацияны қараған дұрыс емес:

• жүктеме профилі (ERP/BW/S/4HANA/аралас)
• жадтағы деректер көлемі қазір және 1–3 жылға болжам
• тоқтауларға қойылатын талаптар, RPO және RTO
• жүйелер тізімі және олардың шамамен өлшемдері (prod/QA/dev және т.б.)
• бэкап пен DR тәсілі (жиілік, орын, қалпына келтіру тесті)

Осы тармақтар бекітілгеннен кейін жады, желі және сәйкестік бойынша есептер нақты болады, кездейсоқ ұқсастық емес.

Жад: көлемді, компоновканы және өсім мүмкіндігін тексеру

SAP HANA үшін жад — басты ресурс. RAM жетіспесе, жүйе суапқа немесе жиі шығарып тастауға көшіп, жобада тез жыртылулар пайда болады. «Нақты қажет» көлемді дәл сол күйінде алу жиі қауіпті, сондықтан ақылға қонымды резерв қалдыруға кеңес беріледі.

RAM көлемі: есептеп, резерв қою

Негізгі көрсеткішті көбіне SAP sizing есебі немесе пилот нәтижелері береді. Өмірде оған деректер өсімі, жаңа есептер, функционал кеңеюі және уақытша шыңдар қосылады. Алдын ала «қазір қанша қажет» ғана емес, «12–24 айдан кейін қанша болады» дегенді келісіп, сол мөлшерге платформаны алмастырып тоқтатпайтыныңызға жеткілікті резерв қалдырыңыз.

Практикалық сценарий: басында 1,5 ТБ жеткілікті деп санап, дәл 1,5 ТБ сатып алады. Жарты жылдан кейін жаңа аналитикалық контур қосылып, 2 ТБ қажет болады. Бос слоттар жоқ болса, апгрейд қымбат әрі ұзақ процесске айналады.

Компоновка: слоттар, арналар және NUMA қарапайым тілде

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

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

Сенімділік пен өсім: ECC және кеңею жоспары

HANA үшін ECC модульдері міндетті. Қосымша сенімділік опцияларын (sparring, айна арқылы сақтау) бөлек талқылау керек: олар сенімділікті арттыра алады, бірақ қолжетімді RAM көлемін азайтады.

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

CPU және платформа: өнімділік «жүзуінен» сақтандыру

SAP HANA үшін маңыздысы — болжамдылық. Пайдаланушылар орташа жылдамдықты емес, кенет нашарлауларды байқайды: есептер баяулайды, жүктеме өседі, қызмет көрсету терезелері орындалмайды.

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

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

Келісуге тұратын нәрселер:

• процессор моделі және қуатты үнемдеуге агрессивті режимсіз өнімділік профилі
• NUMA режимі және жад параметрлері, RAM-ға қолжетімділікті болжамды ету
• Turbo параметрлері мен қуат шектеулері — тұрақты негіз үшін
• таңдалған ОС және оның нұсқасы, чипсет пен желі карталары драйверлерінің қолдауы
• гипервизор қажет болса — оның үйлесімділігі мен ресурс шектеулері

Тағы бір таңдау — bare metal немесе виртуализация. Bare metal максимум және тегіс өнімділік үшін ыңғайлы. Виртуализация басқаруды жеңілдетеді, бірақ тәртіп пен ресурстарды бекіту талап етеді: CPU-ны қайта жазуға жол бермеу, дұрыс шектеулер орнату. Әйтпесе тестер жақсы өтеді, ал өндірісте «жүзу» басталуы мүмкін.

Сақтау: диск пен контроллерден шектеліп қалмау

SAP HANA-да диск жүйесі жиі жасырын шектеу болады. Жад пен CPU-да резерв болғанымен, журналдар жазуда кешігулер болса немесе бэкап терезесіне сыймаса, енгізу тез «дағдарысқа» айналуы мүмкін.

Бірінші жасау қажет нәрсе — сақтау рөлдерін бөлу. "Барлығын бір пулге жинау" көбіне болжамдылықты нашарлатады. DATA (деректер) мен LOG (журналдар) бөлек болуын, жүйелік бөлімдер мен /usr/sap өз көлемінде болуын және бэкаптардың жұмыс деректермен бір томда болмауын (егер IOPS пен орын есептелмеген болса) ұсыныңыз. Экспорт каталогтары мен уақытша файлдар алдын ала жоспарлансын — олар байқалмай кеңейіп кетуі мүмкін.

Келесі қадам — қай жерде кешігулер минималды болуы қажет екенін шешу. LOG үшін latency және тұрақты жазу маңызды, сондықтан NVMe немесе жылдам enterprise SSD нақты әсер береді. DATA үшін сыйымдылық, оқу өнімділігі және жазбаларда шыдамдылық (endurance) маңызды, әсіресе жүктеме белсенді болғанда.

Көп жағдайда тар орындаушы диск емес, контроллер болады. Қуатты CPU-сы төмен RAID, кэшінің аздығы немесе жазу режимінің дұрыс болмауы тіпті жылдам SSD-де де жылдамдықты шектейді. Алдын ала тексеріңіз:

• қажетті RAID деңгейі қолдаулы ма және write-back үшін батарея/суперконденсатор бар ма
• NVMe үшін нақты қанша PCIe жолы бар, желімен бәсекелестік пайда болмайтындай
• SSD тозуын бақылау және тоқтатпай ауыстыру тәртібі бар ма
• шифрлауды қай жерде іске қосатынын: диск, контроллер немесе CPU

Шифрлау қауіпсіздік талаптары үшін маңызды, бірақ кешігулер қосуы мүмкін. Сондықтан рұқсат етілген әдісті алдын ала анықтап, резерв қалдырыңыз.

Бекітілген бөлек тақырып — бэкаптар. Тек көшіруге арналған орын ғана емес, шығарылу жылдамдығын да есептеңіз. Мысалы, түнгі терезе 2 сағат болса және көлем өссе, бөлек сақтау немесе жылдамырақ канал қажет болуы мүмкін, әйтпесе регламент орындалмай қалады.

Желі: өткізу қабілеті, кешігулер және резервтеу

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

Порт жылдамдығына жүктеме профиліне қарай қараңыз. Кіші инсталляциялар үшін әдетте 10/25GbE жеткілікті, бірақ белсенді репликация, үлкен желілік бэкаптар немесе бірнеше түйін болса 40/100GbE керек болуы мүмкін. Маңыздысы тек «қанша гбит» емес, олар қай жерде қажет екені: кейде бір жылдам uplink коммутаторға көбірек пайда әкеледі, бірнеше баяу порттан гөрі.

Алдын ала не тексеру керек

Трафик ағындарын бөліңіз, бір типті трафик екіншісіне кедергі жасамауы тиіс. Көбіне клиенттік қолданба трафигі, репликация, бэкап/деректер тасымалы және басқару (out-of-band, мониторинг, әкімшілік) бөлек болады. Бұл кешігулерді тұрақты ұстауға және мәселенің себебін жылдам табуға көмектеседі.

Репликация үшін кешігулер мен пакет жоғалту өте маңызды. Тіпті орташа жылдамдық жоғары болса да, желідегі «шу» үзілістерге, қайта жіберулерге және RPO өсіміне әкеледі. Жобаға latency, jitter және packet loss бойынша өлшемдер қою жақсы — жай ғана «канал 10 Гбит» деп қана қалмаңыз.

Резервтеуді бастапқыдан қойыңыз: екі желілік жол, екі коммутатор, дұрыс бапталған LACP немесе басқа отказоустойчивость әдісі. Сондай-ақ NIC, драйверлер және offload параметрлерінің үйлесімділігін тексеріңіз: жиі дәл осы нәрселер іске қосу кезінде тұрақсыздық тудырады.

Сертификациялар мен үйлесімділік: не алдын ала растау керек

Техникалық сипаттамасы «жақсы сияқты» сервер де енгізу формалдық шектеулерге тап болуы мүмкін: платформа қолдау тізімінде жоқ, ОС нұсқасы талаппен сәйкес келмейді немесе желі картасының драйвері басқа firmware-ға арналған.

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

Сатып алудан бұрын келісу керек

ТЗ немесе хат алмасуда белгіленсін:

• платформа мен конфигурация сіздің HANA сценариіңізге сертификатталған (appliance немесе TDI)
• операциялық жүйе және релиз сіздің SAP HANA нұсқаңызға (және жоспарлы жаңартуларға) қолдау көрсетеді
• RAID/HBA, NIC, SSD және жад модульдерінің нақты модельдері қолдау тізімінде бар, жай интерфейске сай келетінімен шектелмей
• іске қосуға қажетті firmware пен драйверлер тізімі: оларды кім береді және қалай жаңартылады
• инциденттер кезінде жауапкершілік шекарасы: аппараттық, ОС, SAP, және «стык» бойынша эскалация тәртібі

Типтік тұзақ мысалы: HANA орнатылды, жүктеме астында желі қателері пайда болды. Ұялы NIC үшін ұсынылған драйвер BIOS/UEFI басқа нұсқаға арналған болып шықты, ал жаңарту тоқтау терезесін талап етті. Егер бастапқыда стек нұсқаларын және интегратор мен вендордың қолдауын келіссе, осындай үзілістер әдетте болдырылуы мүмкін.

Сенімділік пен эксплуатация: тамақтандыру, салқындату, сервис

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

Тамақтандыруға тек блок санына қарамаңыз, схемаға мән беріңіз. HANA үшін әдетте азы N+1 қуат блоктары керек, бірақ олар әртүрлі желілер мен PDU арқылы жайылған жағдайда ғана тиімді. Ракта жеткілікті розеткалар бар ма, желілер шын мәнінде тәуелсіз бе, UPS қажетті қуатты және уақытты ұстай ала ма — тексеріңіз.

Салқындату кейде күткендей шектеулі болуы мүмкін. Сервердің жылу шығаруын залыңыздың мүмкіндігімен салыстырыңыз (кВт/рак), ауа ағынын, ауыртпалықтарды және ыстық/суық дәліздерді тексеріңіз.

Мониторингті алдын ала анықтаңыз: қандай температуралар мен оқиғалар қалыпты, қайсысы қызмет заявкасын қажет етеді. Әдетте CPU/жад температурасы, кіріс ауа температурасы, диск пен контроллер күйі, ECC қателері, желілік қателер және қуат оқиғалары бақыланады.

Қолдау мен сервис нақты белгіленсін: реакция және қалпына келтіру уақыты бойынша приоритеттер, ЗИП-тің қолжетімдігі (рақта немесе қалада), BIOS/firmware жаңартулардың тәртібі және үйлесімділігі, қызмет көрсету терезелері және жұмыстардан кейінгі тесттер, 24/7 біріккен байланыс нүктесі.

Мысал сценарий: чек-лист архитектураны қайта жасаудан қалай сақтайды

Компания 500–800 пайдаланушыға арналған S/4HANA енгізуді жоспарлайды. Жоғары қолжетімділік пен екі алаң арасында репликация қарастырылған. Алдымен бәрі оңай сияқты: SAP HANA серверін сатып алып, орнатып, енгізуді бастау.

Бірақ шектеулер тез шығады: сервер бөлмесінде тек бір рак бар, бэкап терезесі түнге қатты бекітілген. Егер бұларды сатып алу алдында текермесеңіз, жоба тест кезеңінде-ақ аппаратқа тап болады.

Чек-лист бойынша команда шектеулерді сатып алудан бұрын анықтайды. Жад бойынша бастапқы есеп қанағаттандырады, бірақ компоновка өсуге орын қалдырмайды. Желі 10GbE репликацияға жеткіліксіз болып шығады және резервтің болмауы HA-ны номиналды қана етеді. Дискілер LOG пен уақытша деректердің шыңдарын көтере алмайды, ал толық көшірме бэкап терезесіне сыймайды.

Шешімдер алдын ала қабылданады: RAM-ға резерв пен кеңейту жоспары, 25/40GbE және трафикті бөлу мен резервтеу, маңызды томдарға жылдам NVMe, және бэкаптарға орын мен өткізу қабілетін алдын ала есептеу.

Қадамдап: конфигурацияны қалай таңдап, келісімге жеткізу

Жүйе іске қосылғаннан кейін қалай жұмыс істеу керек екенін бекітуден бастаңыз. SLA бойынша тоқтаулар мен қалпына келтіру (RPO/RTO), қызмет көрсету терезелері, 12–36 айға деректер өсімі жоспары және бэкап, жаңарту мен мониторинг жауапкершілігін анықтаңыз.

Әрі қарай есептеуден бастап растауға және тек содан кейін сатып алуға өтіңіз:

1. Вводты жинаңыз: ағымдағы жүктеме, деректер көлемі, өсім, критикалық есептер, интеграциялар, қауіпсіздік пен реттеуші талаптар. Бір уақытта RPO/RTO және алаң шектеулерін (рак, қуат, салқындату) келісіңіз.

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

3. Сәйкестікті және растамаларды тексеріңіз: нақты сервер моделдері, накопительдер, желі карталары, драйверлер және гипервизор (егер қолдансаңыз).

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

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

Өндірістік іске қосуға дейін қабылдау тексерістерін өткізіңіз (жад, NUMA, желі, отказоустойчивость), параметрлер мен firmware нұсқаларын бекітіңіз, протоколдар жасаңыз. RPO/RTO фактілі тесті жиі тар жерді өзгеше етеді — мәселе көбіне CPU-да емес, бэкап каналының өткізу қабілетінде шығады.

HANA серверін сатып алу кезіндегі жиі қателіктер

Ең жиі қате — серверді ядро санына қарап таңдау, ал жадты ескермеу. SAP HANA үшін көп нәрсе RAM-да шешіледі: егер көлем жетпесе, жүйе дискіге көшіп, қуатты CPU да көмектеспейді. Алдымен жадты резервпен бекітіңіз, содан кейін процессор мен платформаны таңдаңыз.

Екінші қате — «бар нәрседен» жад орнату. Бір серверде әртүрлі көлемдегі, рангы немесе жиіліктегі модульдерді араластыру жад контроллерінің әлсіз режимге өтуіне алып келуі мүмкін, кейде жүктеме астында күтпеген төмендеулер байқалады. Сол себепті біркелкі компоновканы алдын ала қарастырыңыз және RAM қосқанда сервер қалай масштабталатынын тексеріңіз.

Желіні де кеш еске түсіреді. Репликация, бэкап және қолданушы трафигі бір порт арқылы және резервсіз жүрсе, тар жер — кешігулер мен жүктемелер. Трафикті бөлу немесе VLAN арқылы бөліп, коммутатор немесе сілтеме істен шыққанда не болады дегенді ойлап қою көмектеседі.

Дискілер бойынша қағазда қателесу оңай: жылдам SSD сатып алып, бірақ контроллер, кэш немесе RAID профилі салдарынан шектеулігін көру. Контроллер қажетті IOPS пен өткізу қабілетін көтере ме — тексеріңіз және том рөлдеріне сәйкес RAID таңдаңыз.

Тағы бір мәселе — firmware пен драйвер нұсқаларын бекітпеу. Кейін үйлесімділік жоғалуы немесе құрамдас бөліктер арасында қақтығыс пайда болуы мүмкін. Сондай-ақ көбінесе кеңейту жоспарын бекітпей қояды: деректер болжамнан тез өсіп, бір жылдан кейін архитектураны ауыстыруға тура келеді.

Сатып алудан бұрын жылдам чек-лист және әрі қарай не істеу керек

Спецификацияны бекітпес бұрын қысқа чек-лист арқылы өтіңіз. Бұл шектеулерді алдын ала ұстап, енгізудің қайта жобаланудан құтқарады.

Тексеріңіз:

• RAM: өсімге резерв жеткілікті ме, арналар бойынша дұрыс компоновка бар ма, платформа алмастырмай кеңейту жоспары бар ма.
• CPU және платформа: қолдаулы процессор класы таңдалды ма, тұрақты параметрлер (жиілік, қуат режимдері) келісілді ме, виртуализация талаптары анық па.
• Дискілер және бэкап: DATA мен LOG бөлінген бе, RAID түсінікті ме (қалай және неге), контроллер өнімділігі жеткілікті ме, бэкап пен қайта қалпына келтіру терезелеріне сыйып тұр ма.
• Желі: сценарийге сай жылдамдықтар айтылған ба, резервтеу бар ма (жолдар мен коммутаторлар), трафик бөлініп пе (қолданушы, репликация, бэкап, әкімшілік).
• Сертификация және үйлесімділік: платформа, ОС және негізгі компоненттер (NIC, RAID/HBA, NVMe) қолдауымен расталған ба.

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

Чек-листтен кейін не істеу керек:

1. Қысқа ТЗ дайындау: жүктеме, көлемдер, SLA, 2–3 жылға өсім, рак және қуат шектеулері.
2. ТЗ-ны интегратор және жеткізушімен сәйкестеңіз, компоненттердің үйлесімділігі мен масштабталу жоспарын қамтыңыз.
3. RAM слоттар бойынша, NIC және HBA модельдері, RAID түрі, порттар мен кабельдер сияқты нақты параметрлері бар соңғы спецификация сұраңыз.
4. Өңдеу тобымен желі мен резервтеу схемасын келісіңіз.
5. Қолдау және сервис шарттарын бекітіңіз: кім қалай жауап береді, 24/7 бар ма және запас бөлімшелердің орналасуы.

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