Обследование инфраструктуры мы пережили в первой части — и те, кто знаком с предысторией, понимают, что слово «пережили» здесь выбрано совсем не случайно. Теперь настало время двигаться дальше — к этапу, где уже не просто ищут проблемы, а проектируют мир, в котором эти проблемы не должны появляться вовсе: к целевой архитектуре.

Именно на этом шаге закладывается каркас будущей ИТ-среды: определяются требования к производительности, формируются принципы отказоустойчивости, продумывается структура сетевого взаимодействия и планируется размещение оборудования. Промахнуться здесь — значит допустить трещину в фундаменте: сначала её может быть и не видно, но позже она обязательно даст о себе знать — либо на миграции, либо в самый неподходящий момент эксплуатации. И, как не сложно догадаться, оба варианта одинаково неприятны.

Ключевые задачи этапа

1. Определение требований к производительности

Необходимо зафиксировать, какие ресурсы (CPU, RAM, диски, сеть) потребуются для работы приложений и сервисов в новом ЦОД. Тут важно смотреть не только на текущую нагрузку, но и на то, как система будет расти в ближайшие 3–5 лет. Миграция нередко превращается в отличный повод навести порядок и провести модернизацию: заменить серверы, перейти на NVMe, ускорить СХД, увеличить объёмы памяти и нарастить вычислительные мощности.

Главная ошибка на этом шаге — проектирование «впритык». Когда ресурсы рассчитаны только под сегодняшний день, а завтра инфраструктура внезапно начинает упираться в потолок, который сами же и построили.

2. Формирование схемы сетевой инфраструктуры

На основе данных обследования проектируется новая схема LAN, SAN и MGMT-сегментов. Следует предусмотреть топологию (двух- или трёхуровневую), резервные каналы, балансировку нагрузки и разделение сетей по зонам безопасности (prod, test, DMZ, backup). Здесь важно выработать единые стандарты коммутации, отказаться от хаотичных решений, накопившихся за прошлые годы, и сделать сеть предсказуемой и управляемой.

Ошибка №2: копирование старой сетевой архитектуры без модернизации — это просто переписывание старых ошибок тем же почерком.

3. Проектирование размещения оборудования в стойках

При проектировании размещения важно учитывать энергопотребление, тепловыделение и взаимные зависимости оборудования. Я обычно формирую таблицу распределения по стойкам с учётом баланса нагрузки на блоки питания, корректного расположения компонентов и удобства их дальнейшего обслуживания.

Хорошей практикой остаётся умеренное заполнение стоек и обязательный резерв по юнитам. Ошибка №3: плотное уплотнение без учёта энергопотребления и охлаждения.

Например, недавно при миграции сложилась ситуация, когда на старой площадке было 8 стоек и две из них регулярно попадали в «красную зону» по температуре. Причиной было неравномерное распределение шасси, СХД и высокоплотных серверов. Поэтому при проектировании целевой архитектуры мы собрали таблицу размещения с учётом энергопотребления и тепловыделения каждого устройства, ограничили плановое заполнение стойки 70–75% по юнитам и по мощности, разнесли «горячие» узлы по разным стойкам и разным фазам питания и заложили обязательный резерв по юнитам под рост.

 В итоге, у нас не только сократилось количество стоек с 8 до 6 за счёт того, что получилось избавиться от «зоопарка» и консолидации, но и во всех стойках температура перестала выходить за допустимые значения даже при пиковых нагрузках. Таким образом, обслуживание упростилось — появилось понятное правило, куда и что можно добавлять без пересчёта всей площадки.

4. Выбор систем резервирования и отказоустойчивости

Целевая архитектура должна учитывать, что разные сервисы требуют разного уровня доступности, и именно от правильной градации зависит баланс между надёжностью и стоимостью решения. Критичные системы — проектируются с использованием кластеров, активных и пассивных узлов, синхронной или асинхронной репликации данных между площадками, чтобы даже при выходе из строя узла или целого сегмента площадки сервис продолжал работать. Менее критичные компоненты, наоборот, не нуждаются в столь дорогих и сложных схемах: достаточно упрощённого резервирования и регулярных бэкапов. Такой подход позволяет направить ресурсы туда, где они действительно нужны, а не раздувать инфраструктуру ради формального единообразия.

Очередная возможная ошибка — одинаковое отношение ко всем сервисам.

Например, на одном из проектов у заказчика сложилось представление, что нужно  «кластеризовать всё»: от биллинга и CRM до внутреннего wiki и второстепенных интеграционных сервисов. Но в итоге мы предложили начать не с железа, а с классификации и разложили все сервисы по уровням критичности:

• критичные (биллинг, платёжный шлюз, часть фронтовых сервисов);

• важные, но допускающие непродолжительный простой (CRM, часть интеграций);

• вспомогательные – порталы, wiki, dev/test-среды, которые можно восстановить из бэкапа.

Под каждый уровень мы подобрали свою схему резервирования. Для критичных сервисов спроектировали кластера с двумя активными узлами на основной площадке и асинхронной репликацией на DR-сайт с RPO в пределах 5 минут и RTO до 30 минут. Для важных сервисов сделали уже упрощённый вариант: один основной узел, один «холодный» резерв с регулярными бэкапами и регламентным восстановлением в случае аварии. Для вспомогательных сервисов ограничились ежедневными бэкапами и чётко прописанными процедурами восстановления.

Реализовать «кластер для всего», конечно, тоже можно (и формально это даже проще), но тогда бюджет проекта увеличивается почти в полтора раза. После того как мы обсудили критичность работы сервисов, ожидаемые RPO/RTO и стоимость каждого варианта, было принято решение: кластера и репликация остались только там, где простой действительно может ударить  по критически важным сервисам, а остальное перевели на более простые схемы.

В итоге мы получили архитектуру, где платёжные и клиентские сервисы переживают отказ узла или даже целой площадки практически незаметно для пользователей, а менее критичные компоненты не тянут на себя избыточный объём железа и лицензий. И самое главное —если через полгода бизнес запустит новый продукт, заказчику не придётся «резать по живому» и выдумывать ещё один супер-кластер: можно просто вписать новые сервисы в уже понятную модель уровней доступности.

5. Обеспечение масштабируемости и гибкости

Если этап проектирования не предусматривает рост, то миграция перестаёт быть инвестициями в будущее и просто превращается в замену одного «тесного» ЦОДа на другой. Масштабируемость всегда должна закладывается заранее: я оставляю свободные юниты в стойках, резерв по портам на коммутаторах и функциональные заделы для подключения новых сервисов. Такой запас выглядит избыточным только в момент проектирования, но именно он позволяет безболезненно добавлять вычислительные узлы, расширять СХД, усиливать сетевую связность или вводить новые контуры, не трогая основную архитектуру и не останавливая сервисы. 

Как показывает практика, развитие бизнеса никогда не бывает линейным. Сегодня инфраструктура лишь покрывает потребности текущих приложений, а завтра может потребоваться среда для машинного обучения, расширенная аналитическая платформа или отдельный контур под новый продукт. Если архитектура изначально не рассчитана на такие скачки, каждый из них превращается в мини-проект со своей головной болью: перестройкой сети, нехваткой портов и внеплановыми закупками.

Именно поэтому грамотное проектирование опирается не только на расчёты «под сегодня», но и на создание возможности для масштабирования инфраструктуры в ближайшие годы. Это обеспечивает готовность к росту, даже если его конкретные формы заранее неизвестны.

Хороший контрольный вопрос на стадии проектирования: «Если через два года объём данных увеличится вдвое, что будем делать?»

6. Документы и артефакты этапа

По итогам проектирования целевой архитектуры должны быть подготовлены следующие документы:

• Схема целевой архитектуры ЦОД (логическая и физическая);

• Таблицы распределения оборудования по стойкам;

• Проект сетевой схемы с описанием портов, VLAN и зон безопасности;

• Документ с описанием SLA и зон ответственности;

• План по резервированию и обеспечению отказоустойчивости.

Проектирование целевой архитектуры — это фундамент всей миграции. Именно на этом этапе мы определяем, каким будет новый ЦОД: удобным, безопасным и готовым к росту бизнеса, или же перегруженным и проблемным с первых месяцев эксплуатации. Чем тщательнее продуман этот этап, тем проще и быстрее пройдёт сама миграция, а бизнес получит надёжную и предсказуемую ИТ-среду. 

Но это ещё не финал: впереди — момент истины, когда теория должна выдержать встречу с реальностью, а архитектура — подтвердить свою жизнеспособность. Собственно переезд — это это не просто техническая процедура, а искусство аккуратного переноса сложных систем. В следующей статье разберём, как сделать этот требовательный этап предсказуемым и спокойным — без драматических эпизодов и аварий.