Серверна інфраструктура

Архітектура

Сервер підбирається за профілем навантаження: CPU, пам’ять, дискові операції, мережа та вимоги до затримки. Розмір ресурсу слід пов’язувати з вимірюваннями, а не лише з кількістю користувачів.

Експлуатація та межі

Відокремлення середовищ, оновлення, контроль доступу та журналювання входять до експлуатації. Реплікація підвищує доступність, але не замінює незалежну резервну копію.

Пов’язані матеріали

Технологічний напрям → · Інженерні огляди · Професійний запит

Сервери AVGZ та обробка даних клієнтів

AVGZ має власні сервери, зокрема для штучного інтелекту та нейромережевої обробки даних клієнтів. Серверне рішення розглядається разом із мережею, сховищем та програмним середовищем. Важливо не лише запустити застосунок, а й визначити, як він отримує дані, де зберігає результат і що потрібно для повернення до роботи після відмови.

Підбір починається з профілю навантаження. Для бази даних перевіряють затримку запису й робочий набір у пам’яті; для файлового сервісу — обсяг, кількість операцій і відновлення; для моделей — пам’ять, чергу та час обробки. Конфігурацію погоджують за вимірюваннями задачі, а не за загальним означенням «потужний сервер».

Фізичний вузол, віртуальна машина чи контейнер

Фізичний сервер дає контроль над ресурсами й конфігурацією обладнання. Віртуальні машини дозволяють розділити програмні середовища та керувати їх життєвим циклом. Контейнери допомагають узгодити пакування застосунку, але самі по собі не визначають політику ізоляції даних. Вибір залежить від сумісності, характеру навантаження та способу супроводу.

У плані ресурсів враховують одночасну роботу, оновлення та відновлення. Якщо всі ресурси зайняті звичайною обробкою, відновлення резервної копії може конкурувати з робочими сервісами. Для AI окремо оцінюють підготовку файлів, виконання моделі та збереження результатів: найповільнішим компонентом може виявитися сховище, а не обчислення.

Приймання й подальша експлуатація

Перед запуском потрібні перевірки навантаження, доступів, резервного копіювання та повернення сервісу після перезапуску. Результат фіксують із версією програм, конфігурацією тесту й обсягом даних. Порівняння з іншим вузлом має сенс лише за однакових умов.

Під час експлуатації спостерігають не тільки за завантаженням процесора, а й за чергами, затримками сховища та помилками прикладного сервісу. Для оновлення задають контрольний сценарій і спосіб відкату. Доступ до робочих даних і до адміністрування розділяють; тимчасові доступи мають бути обмежені задачею й строком.

Передавання даних клієнта потребує погодженого способу приймання, переліку уповноважених користувачів і порядку очищення результатів та тимчасових копій. Для довгих обчислень корисно зберігати контрольні стани, якщо це підтримує робочий процес. Перезапуск задачі тоді оцінюється як окремий сценарій, а не вважається автоматично безпечним.

Контрольний сценарій перед запуском

Для приймання обирають конкретну робочу операцію й фіксують її початкові умови. Після звичайного проходження перевіряють погоджений збій: перерву зв’язку, перезапуск компонента або повторне надходження даних. Результат має пояснювати, що збереглося, що відновилося автоматично та де потрібна дія оператора. Ці відомості передають разом із правилами супроводу.

Які дані потрібні для підбору сервера?

Опишіть застосунок, поточний обсяг даних, кількість одночасних задач і час, за який має завершуватися обробка. Корисні вимірювання завантаження пам’яті, дисків і мережі за типовий та піковий період. Для нейромереж додайте формат моделі, розмір вхідного набору та вимоги до результату. Якщо таких вимірювань ще немає, почніть із контрольного запуску на обмежених даних. Окремо вкажіть, хто супроводжуватиме програму й як планується передавати дані. Це дозволить узгодити межі робіт і спосіб приймання до перенесення навантаження.