Блог компании dataline

Привет! Я работаю старшим сетевым инженером в компании DataLine, занимаюсь сетями с 2009 года и успел со стороны понаблюдать, как компании подвергались атакам из-за уязвимости протокола маршрутизации BGP. Один BGP Hijacking чего стоит: пару лет назад хакеры с помощью перехвата BGP-маршрутов украли 137 тыс. долларов.

С переходом на удаленку компании организуют доступ из дома через защищенные соединения с помощью NGFW, IPS/IDS, WAF и прочих решений. Но про безопасность BGP порой забывают. Я расскажу в цикле статей, как каждый клиент сервис-провайдера может обезопасить себя с помощью RPKI средства защиты глобальной маршрутизации в сети Интернет. В первой статье на примере объясню, как это работает и как настроить защиту на стороне клиента в пару кликов. Во второй поделюсь опытом внедрения RPKI в BGP на примере маршрутизаторов Cisco.

Что важно знать про RPKI, и при чем тут холодильник

RPKI (Resource Public Key Infrastructure) это специализированная инфраструктура открытых ключей. Она помогает доказать подлинность ресурса в интернете, а также право ресурсодержателя использовать ресурсы и передавать информацию о ресурсах операторам связи.

Можно сравнить эту инфраструктуру с холодильником в общежитии или офисе. Вы получаете право пользоваться общим холодильником (интернетом), складываете еду на определенную полку (публикуете ресурсы), но обязаны определенным образом подписывать еду, чтобы ее не забрал кто-то еще.

Так и тут. RPKI использует для подписей профиль сертификата X.509 PKI, который описан в RFC3779. Операторы связи с его помощью принимают безопасные решения о маршрутизации ресурсов в сети Интернет. Чтобы увидеть, как они это делают, напомню про иерархию выделения ресурсов в интернете:

Ресурсы последовательно выделяют несколько организаций:

IANA (Internet Address Number Authority) администрация адресного пространства интернета. Интернет-ресурсы изначально принадлежат IANA, она управляет пространствами IP-адресов для доменов верхнего уровня. Она же присваивает номера для автономных систем (AS) систем IP-сетей и маршрутизаторов, которыми управляют операторы связи. Эти номера AS необходимы для маршрутизации.

RIR (Regional Internet Registry) региональные интернет-регистраторы, IANA распространяет ресурсы через них. Всего их 5 для разных регионов RIPE NCC, ARIN, APNIC, AfriNIC, LACNIC.

LIR (Local Internet Registry) локальные интернет-регистраторы, как правило, крупные сервис-провайдеры. RIR распространяет ресурсы на LIRы, которые уже распределяют их между своими клиентами.

Такая же архитектура у RPKI. После каждого распределения ресурсов создается сертификат, подписанный ключом вышестоящей организации. IANA выпускает сертификаты для доверенных RIR, а они для доверенных LIR.

Сертификаты хранятся в базе данных, по которой можно проверять достоверность информации. Базы данных расположены на публичных репозиториях RPKI у всех RIR на так называемых "точках доверия", или Trust Anchors.

Тут в игру вступают владельцы ресурсов в интернете. Чтобы подтвердить безопасность ресурсов, они создают с помощью сертификатов криптографически заверенные объекты, или ROA.

ROA (Route Origin Authorisation) это объект c цифровой подписью, который подтверждает, что конкретная AS имеет право быть источником какого-то маршрута и анонсировать его в интернете. Запись ROA имеет 3 параметра:

• номер AS, которая является источником маршрута;

• префикс и его длина (это IP-адрес с маской: xxx.xxx.xxx.xxx/yy);

• максимальная длина префикса.

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

Следовательно, при проверке подлинности любой префикс можно сравнить с ROA и задать ему три состояния:

• VALID для префикса есть ROA, и анонс маршрута совпадает по всем параметрам с референсными значениями в ROA. AS в AS_PATH совпадает с AS в записи ROA, префикс тоже как в ROA, а его максимальная длина больше или равна длине маски в анонсе.

• INVALID для префикса есть ROA, но анонс маршрута не совпадает по одному из параметров в ROA.

• UNKNOWN значит, что запись ROA для префикса отсутствует в Trust Anchor вашего RIR. Это возможно, если префиксы еще не завалидированы. Пока все только переходят на RPKI, многие операторы связи применяют мягкие политики и доверяют таким префиксам. При жесткой политике безопасности префикс UNKNOWN будет отклонен маршрутизатором.

Разберем проверку префикса на примере. Допустим, у меня есть префикс х.х.х.х/22, который маршрутизируется в сети Интернет и анонсируется из моей AS N. Изначально я не создал для него записи ROA. Раз запись о префиксе отсутствует в Trust Anchor, анонс префикса будет иметь статус UNKNOWN.

Далее я создал для него запись ROA c параметрами: AS N, префикс х.х.х.х/22, максимальная длина префикса /23. Теперь от имени своей AS N я могу проанонсировать апстрим-провайдерам этот префикс /22 или же две /23 подсети, которые входят в /22 подсеть. Такой анонс будет иметь статус VALID.

Если же я проанонсирую /24 от имени AS N или префикс /22 (/23+/23) от имени AS P, то такой анонс будет иметь статус INVALID. Допустим, нам необходимо проанонсировать подсеть /24 из более крупного блока адресов, который уже анонсируется в глобальную сеть. Значит, в записи ROA для более крупной подсети нужно изменить параметр максимальной длины префикса или создать для нее свой ROA.

Проверка подлинности маршрутов на маршрутизаторах происходит одним из способов:

1. Проверка самим маршрутизатором по прямой RPKI-сессии.

2. Загрузка на маршрутизатор готовой базы данных с локального кэш-сервера RPKI.

Первый способ требует выполнения на маршрутизаторе сложных криптографических вычислений. Он не рекомендован к использованию из-за своей ресурсоемкости для маршрутизатора.

Второй способ не требует таких больших затрат. Локальный кэш-сервер RPKI загружает в себя базу ROA со всех установленных Trust Anchors по протоколу RSYNC или RRDP и поддерживает ее в актуальном состоянии. Локальный RPKI-сервер на основе своей базы данных ROA генерирует базу данных для маршрутизатора. Каждая запись базы содержит упрощенный вариант ROA, и эта база передается на маршрутизатор по протоколу RPKI-RTR. По умолчанию это TCP-порт 8282. По этим данным на маршрутизаторе настраиваются политики для маршрутизации полученных префиксов.

Как завалидировать свои префиксы

Допустим, вы клиент сервис-провайдера. У вас есть своя AS с парой /24 блоков IP-адресов, вы пиритесь по eBGP со своим провайдером, full view от него не получаете, других пирингов у вас нет. Вам приходит письмо, что провайдер внедряет на своей стороне систему валидации префиксов на основе RPKI и просит завалидировать свои анонсы.

В этом случае вам нужно подписать ROA свои префиксы, чтобы в дальнейшем ваши ресурсы были доступны из сети Интернет.

Для регионального регистратора RIPE NCC шаги такие:

1. Зайдем на портал RIPE в личный кабинет по адресу https://my.ripe.net. В правой части страницы перейдем в Resourses, далее в RPKI Dashboard.

   

   Если вы раньше никогда не заходили на эту страницу, RIPE попросит вас подписать соглашение EULA.

   Затем выбираем тип центра сертификации (Certificate Authority, CA):

   - Hosted хранить сертификат на стороне RIPE;

   - Non-Hosted хранить сертификат на своей стороне.

   Быстрее и удобнее выбрать вариант Hosted. В варианте Non-Hosted вам нужно предоставить XML-файл, сгенерированный вашим ПО центра сертификации. Система RIPE NCC сгенерирует ответный XML-файл, который нужно загрузить и использовать в своем программном обеспечении RPKI CA.

2. В RPKI Dashboard перейдем во вкладку BGP Announncements. В нижней части экрана в меню Show выберем All.

   

3. Вернемся в начало страницы и выберем все префиксы по чек-боксу рядом с надписью Origin AS. Создадим ROA по кнопке Create ROAs for selected BGP announcements.

   

4. Подождем, пока сформируется стейджинг ROA. Внизу появится кнопка:

   

   Нажмем ее и во всплывающем меню нажмем Publish!

   

Все, готово! Вы успешно завалидировали свои префиксы!

Для счастливых обладателей PI-адресов RIPE подготовил отдельную инструкцию для валидации префиксов. А еще удобнее использовать Wizard от RIPE NCC: https://portal.ripe.net/rpki-enduser.

Сейчас все крупные компании внедряют проверку маршрутов на базе RPKI. Рано или поздно валидацию BGP нужно подключить всем, кто хочет, чтобы приложения и сайты были доступны, а проверки маршрутов успешны.

Если же вы сами являетесь сервис-провайдером, то лучше внедрить свою валидацию и фильтрацию маршрутов на основе RPKI.

Но об этом поговорим в следующий раз, всем пока и до встречи!

Меня зовут Николай, и в DataLine я занимаюсь эксплуатацией стенда виртуальных рабочих столов (ВРС) на базе Citrix Vitrual Apps and Desktop. Недавно мы добавили к инфраструктуре ВРС сервис записи пользовательских сессий для двух сценариев:

• служба ИБ по записям расследует инциденты безопасности;

• служба технической поддержки подключается к пользователю по запросу и записывает его работу на ВРС, чтобы найти причины проблем с работоспособностью ПО.

Сегодня расскажу, как Citrix Session Recording решает эти задачи на нашем стенде, и проведу обзор его возможностей.

Кому нужно решение

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

Citrix Session Recording регистрирует на ВРС ключевые события для ИБ и техподдержки, например: подключение внешнего хранилища, изменение конкретных файлов, запуск определенных приложений. Интересующие действия можно потом найти в привязке ко времени.

Как это устроено

Для записи сессий виртуальных рабочих столов используются несколько компонент:

Агент записи сеанса (Session Recording Agent) устанавливается на каждом виртуальном рабочем столе. Он подхватывает HDX-поток трансляцию рабочего стола, которую видит пользователь ВРС.

Сервер записи сеанса (Session Recording Server) управляет хранением файлов записи, отвечает за поиск, индексацию и цифровую подпись записей для обеспечения целостности.

База данных записи сеанса (Database) хранит метаданные по каждой сессии: ID, время, пользователи, группы пользователей, события и так далее.

В консоли политик записи (Session Recording Policy Console) администратор настраивает, какие именно события записывать, для каких пользователей или групп.

Сами файлы записи хранятся в специальном формате локально или в общем хранилище.

В плеере записи сеанса (Session Recording Player) можно найти записи и отследить на временной шкале, где какое событие зарегистрировано. Чем-то похоже на вебвизор:

Как альтернативу десктопному плееру можно использовать WebPlayer, в котором удобно делиться ссылками:

В WebPlayer тоже есть закладки по событиям справа: можно проматывать простои, когда пользователь ничего не делал и на экране ничего не менялось:

Администраторы могут стартовать запись сеанса в интерфейсе Citrix Director.

Какие настройки есть

Что записывается. В консоли политик администратор создает Recording policy и указывает, каких пользователей записывать и как их уведомлять об этом. Для выбранных пользователей или групп запись начнется автоматически со стартом новой сессии. Какие именно события фиксировать, настраивается в отдельной политике Event Logging policy.

Вот какие события можно фиксировать на записи:

• установку запоминающих устройств USB,

• запуск и окончание работы приложения,

• переименование, создание, удаление и перемещение файлов,

• просмотр веб-страниц,

• самые популярные оконные действия.

При этом на записи не отображается контент внутри систем для конфколлов, например: видеоразговоры в Lync, Webex и другое выгруженное содержимое по технологии HDX Flash или Multimedia Redirection (MMR).

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

• права администратора позволяют работать с политиками и файлами записи: просматривать, создавать, редактировать, удалять;

• права на просмотр записей позволяют искать и воспроизводить записанные сеансы.

Где и как хранится. Для записи используется технология HDX, которая отвечает за доставку контента пользователю ВРС. Изначально технология была нужна, чтобы пользователь не замечал большой задержки между действием на физической машине и трансляцией сеанса на его личном экране. HDX-поток уже сильно сжат, так что для записи сессий агент просто подхватывает его и отправляет в хранилище. Это помогает хранить дневную активность пользователя не в гигабайтах, а в мегабайтах.

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

В плеере записи сеанса можно просматривать файлы напрямую из основного хранилища. Если нужно воспроизвести заархивированную запись с сервера клиента, ее импортируют в хранилище восстановленных записей.

Как обеспечивается отказоустойчивость. При потере связи с сервером агент записи по умолчанию может локально хранить очередь для сервера около двух часов. После возобновления работы агент отправит все записи на сервер. Дополнительно можно объединить серверы в кластер и настроить балансировку нагрузки и автоматическое переключение при отказе.

Мы предоставляем Citrix Session Recording как дополнительную опцию к инфраструктуре виртуальных рабочих столов на базе Citrix VDI. Буду рад ответить на вопросы повозможностям этого решения для конкретных кейсов.

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

Для расследования инцидентов мы используем не только журналы c конечных устройств, но и систему контроля действий поставщиков ИТ-услуг (СКДПУ). Она записывает все действия инженеров DataLine с Cloud-152. Это облако аттестовано по требованиям ФЗ-152 и Приказа 17 ФСТЭК России к ГИС, сертифицировано по стандарту PCI DSS и входит в область действия сертификата по ISO/IEC 27001:2013. Так что СКДПУ еще и помогает выполнять требования законов и стандартов.

Также система используется, если нужно помочь клиенту и подключиться к серверам в его информационной системе персональных данных (ИСПДн). Доступ наших администраторов к S3 и некоторым другим системам тоже контролируем через СКДПУ.

В статье покажу, за какой уровень защиты облака у нас отвечает СКДПУ, чем и как он может помочь клиентам.

Место СКДПУ в Cloud-152

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

На уровне Cloud-152 СКДПУ работает, как такая камера с датчиком:

• в один файл идет запись всех действий на экране администратора,

• в другой файл пишется весь ввод с клавиатуры.

Два файла синхронизируются с помощью временной метки. Это позволяет посмотреть все, что делал сотрудник во время пользовательской сессии.

На общей схеме Cloud-152 это выглядит так: облако оборудовано не только забором в виде защищенного сетевого сегмента с межсетевым экраном, но и камерами для наблюдения за каждым инженером:

У администраторов IaaS нет прав доступа к клиентскому сегменту, только к сегменту управления. Если клиент заказывает дополнительные сервисы по администрированию, инженер тоже подключается через СКДПУ.

Мы рассматривали несколько подобных систем и выбрали СКДПУ по нескольким критериям:

• поддерживает основные протоколы администрирования Windows, Linux и сетевых устройств

• хорошо оптимизирована и не особо требовательна к железу;

• небольшой объем файлов с сессиями, к примеру: восьмичасовая сессия весит 100 Мб, за год одна из групп админов израсходовала 140 Гб;

• хорошая поддержка на российском рынке: большинство проблем решаются в первый час;

• можно блокировать запуск определенных программ или консольных команд.

Минус лишь в стоимости лицензии и нюансах администрирования. В консоли СКДПУ есть своя логика, и к некоторым моментам нужно привыкнуть. Например, есть различия у десктопной и веб-консоли. При этом для настройки нужно знать глубоко не только саму СКДПУ, но и операционную систему.

СКДПУ имеет много возможностей по записи действий пользователя. Его можно также использовать как кейлогер, но эту функциональность нужно включать дополнительно. Если поставить нужную галочку, то пароли к целевым системам будут видны на записи. Это тоже нужно учитывать при настройке, иначе журнал сессии может скомпрометировать пароль админа.

Какие записи и как храним

Особенность СКДПУ в том, что каждое запущенное приложение пишется в отдельный файл. Если изображение на экране администратора меняется при переходе в новое приложение, СКДПУ начинает записывать новый файл. В итоге запись каждой сессии дробится на несколько тематических видео. Файлов в архиве больше, зато не нужно проматывать длинные видео в поисках нужного скрина:

В рамках Cloud-152 мы пишем все сессии и все события. Но дополнительно отслеживаем запуск определенных программ в реальном времени. К примеру, запуск консоли управления доменом или определенного сервера на такие события настраиваем уведомления в почту и можем сразу отреагировать на подозрительные действия администратора.

Вместе с этим журналы отправляются в нашу систему для сбора и визуализации данных на основе ELK. Сюда уведомления из СКДПУ поступают в виде записей: запущено приложение..., пользователь ввел фразу. Для определенных событий также можем настроить алерты в системе мониторинга на базе Nagios.

Когда наш сотрудник заходит в Cloud-152, он получает оповещение о записи сессии:

Параллельно с этими записями мы храним журналы входа в Cloud-152 и проверяем, совпадают ли они по времени. Если кто-то попытается обойти СКДПУ, произойдет рассинхрон: система зафиксирует вход в IaaS, но не увидит запись в СКДПУ.

Записи сессий администраторов Cloud-152 хранятся не менее 360 дней. Дополнительно мы делаем резервные копии записей средствами Veeam и отправляем их на хранение в другой наш ЦОД. Бэкапы храним 30 дней.

Как используем записи

Расследуем любые нештатные ситуации. Если какой-то инцидент произошел после подключения нашего сотрудника к серверу клиента, просматриваем записи и перепроверяем корректность работы. Речь не только про ИБ, но и про любые другие проблемы.

Следим за соблюдением правил работы с оборудованием. Многие защиты и права доступа настраиваются на самом оборудовании. Например, в случае с сетевыми устройствами может использоваться протокол TACACS+: с его помощью можем ограничить доступ к оборудованию, прописать права и запретить выполнение определенных команд. Тем не менее, если кто-то из инженеров попытается совершить запрещенную команду, в СКДПУ мы увидим соответствующее событие. Как минимум, появится повод для беседы.

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

Обновляем базу знаний. Cервис полезен и для решения спорных ситуаций. Полтора месяца назад наш инженер разбирал нетиповую проблему на стороне клиента и уже успел забыть точную последовательность действий, а системные журналы перезаписались. Проблема проявилась снова. Мы подняли запись из СКДПУ и поняли, что в действиях инженера не хватало финальной проверки результата. Этот случай добавили в базу знаний и внесли изменения в регламент проверки работ.

Помогаем следить за админами клиента внутри его систем. Размещение клиента в Cloud-152 не позволяет автоматически выполнить все требования 152-ФЗ. На совести клиента остается сама ИСПДн ее тоже нужно приводить в соответствие с законом. В виртуальных машинах клиента могут работать его подрядчики: настраивать 1С, систему документооборота и т. д. За работой администраторов-аутсорсеров лучше тоже на всякий случай приглядывать. Для этого предлагаем клиентам аренду СКДПУ на месяц и более и помогаем ему настроить внутреннее наблюдение за своими администраторами.

СКДПУ подходит не только для Cloud-152. Если клиентам захочется поставить такую систему в любом другом нашем облаке, то скоро запустим новый сервис с ежемесячными лицензиями. Следите за обновлениями!

Когда клиент размещает свой сайт, почту или другой сервис в нашем облаке на базе VMware, то в 90% случаев в качестве граничного устройства используется виртуальный маршрутизатор NSX Edge. Это решение выполняет для виртуального дата-центра функции межсетевого экрана, NAT, DHCP, VPN и так далее.

Но если, например, клиент привык получать на межсетевом экране расширенную аналитику по трафику и более детальный мониторинг, то в облаке ему может понадобиться межсетевой экран нового поколения (Next Generation Firewall, NGFW). К тому же, такие решения предоставляют модули IPS и IDS, антивирус и другие фишки. Для клиентов c такими запросами в качестве одного из решений мы предлагаем NGFW как сервис на базе FortiGate. В статье покажу, как и для чего мы организуем переезд в этот сервис.

Когда стоит рассмотреть NGFW как сервис

Чаще всего наши клиенты рассматривают альтернативы NSX Edge, если на уровне межсетевого экрана нужно решать дополнительные задачи:

• обнаруживать и предотвращать вторжения с помощью модулей IPS и IDS;

• обеспечивать дополнительную антивирусную защиту;

• контролировать приложения, которые используют сотрудники на рабочих местах в облаке;

• интегрировать политики безопасности с каталогами AD и IDM;

• отслеживать и расследовать сложные атаки и инциденты с помощью продвинутой аналитики.

Вместо сервиса можно выбрать и приватное решение закупить виртуальные или физические ресурсы в частное облако под нужды заказчика. К примеру, частное решение разворачивается, если нужен межсетевой экран, сертифицированный по требованиям ФСТЭК. Но у частного варианта есть минус: если проект живет в приватном облаке долго, рано или поздно может возникнуть проблема сайзинга. Например, мы закупили для проекта заказчика межсетевые экраны с небольшим запасом, под этот объем закупили лицензии. Через несколько лет трафик вырос сильнее ожидаемого. Заказчик захотел расширить пропускную способность и уперся в пакетную политику лицензирования вендора: докупить ровно необходимое количество лицензий было нельзя.

NGFW как сервис позволяет избежать проблем с сайзингом, если предсказать рост пропускной способности нельзя. В этом случае заказчику на одном из межсетевых экранов предоставляются выделенные сетевые сегменты виртуальные домены (VDOMы). Трафик предоставляется по принципу Pay-as-you-go: заказчик платит только за ту пропускную способность, которую потребил на виртуальном домене. Количество VDOMов можно увеличивать: в сервисе за это отвечает сервис-провайдер, заказчику достаточно сформулировать запрос.

Вот как упрощенно выглядит сегментация:

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

Как происходит переезд

При переезде из NSX Edge есть один нюанс: у клиента поменяется внешняя адресация. Мы заранее предупреждаем об этом клиента и затем идем пошагово по нашему плану.

Перенос "как есть". На первом этапе вся защита переносится в том виде, в котором ее настроил заказчик.

1. Общаемся с клиентом, выясняем его задачи и уточняем, какие модули NGFW нужны.

2. Запрашиваему клиента необходимую информацию:

   • как сегментирована сеть,

   • какие VLANы используются,

   • какие типы сетей: routed, isolated,

   • как клиент выходит в интернет,

   • какая полоса пропускания,

   • как все мониторится,

   • какие NAT-трансляции используются.

   Так мы выстраиваем архитектуру будущего решения.

3. Запрашиваем конфигурацию с оборудования заказчика либо просим доступ к Edge, чтобы выгрузить конфигурацию самим.

4. Анализируем конфигурацию и заводим сети клиентов: создаем отдельный VDOM на FortiGate и подаем туда VLANы.

5. Переносим все правила доступа со старого оборудования.

6. Создаем NAT-трансляции с новыми адресами, составляем IP-план и отправляем его клиенту.

7. Преднастраиваем VPN-туннели.

8. Согласовываем время даунтайма во время миграции. Общее время зависит от количества VLANов.

9. Переводим трафик с минимальным простоем. Чаще всего делаем это ночью, чтобы влияние переезда было минимальным. Тушим интерфейс на Edge и поднимаем интерфейс с таким же адресом на FortiGate. Параллельно с этим клиент меняет DNS. На каждый VLAN достаточно несколько минут.

Если в этом процессе возникнет какая-то проблема, мы сможем откатиться назад за пару минут.

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

Включение модулей безопасности. Здесь мы настраиваем модули NGFW: IPS, контроль приложений, антивирус, всю работу делаем в тесной связке с клиентом. Сначала мы создаем профили безопасности в режиме мониторинга и только наблюдаем за срабатываниями, но не блокируем их. Например, у нас начал срабатывать модуль IPS. Сначала мы смотрим, что это за трафик, и сообщаем клиенту. Решение принимаем совместно: блокировать такие срабатывания, или это легитимный трафик и срабатывание оказалось ложным. Только после совместного обсуждения включаем правила в режиме блокировки.

Как решаются особые кейсы NGFW+

Иногда NGFW как сервис становится частью комплексного решения, к которому мы подключаем другие модули:

• система управления журналами безопасности,

• VPN-клиенты,

• сервис защиты веб-приложений (WAF),

• другие.

Кратко расскажу, как эти решения работают совместно.

Журналы событий FortiAnalyzer вместе с NGFW помогают видеть более детальную картину трафика. Например, есть модуль индикаторов компрометации: мы видим, что какие-то хосты ломятся на скомпрометированные IP-адреса. Этот трафик блокируется, а хосты мы проверяем антивирусом.

Отдельной политикой на NGFW можно настроить передачу трафика по syslogу в клиентскую SIEM-систему. Или можем просто передавать журналы в клиентский лог-коллектор через IPsec.

FortiAnalyzer также помогает организовать долговременное хранение журналов.

Дополнительный VPN-шлюз для доступа к внутренней инфраструктуре можно настроить с помощью FortiClient VPN. Это средство для защиты конечных точек (endpoint-защиты). С его помощью доступ на удаленный сервер настраивается определенным группам пользователей.

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

Клиентам с WAF мы рекомендуем ограничивать на межсетевом экране доступ к сайтам только с адресов WAF. NGFW в этой связке работает в режиме explicit proxy: запрещено все, что не разрешено.

WAF в такой схеме отбивает все, что связано с вебом. NGFW работает и на вход, и на выход: он также контролирует выход базы данных и веб-серверов за обновлениями. Также NGFW следит за взаимодействием внутренних серверов между собой: как один сегмент сети общается с другим. Даже если какой-то внутренний сервер заразится, то сегментация сети на NGFW не позволит заразе распространиться дальше.

Такие комплексные решения помогают нам в крупных и сложных проектах. Для заказчика они более выгодны и позволяют снять нагрузку с сотрудников.

Единственный случай, когда лучше выбрать комплексный сервис в виде частного решения, необходимость сертификации NGFW или WAF по требованиям ФСТЭК. Администрировать такое решение тоже может сервис-провайдер, но это будет межсетевой экран или WAF под конкретного заказчика.

Представьте задачу: необходимо обеспечить стабильным интернетом и покрыть бесшовным Wi-Fi здание площадью 300 м² с возможной расчетной нагрузкой до 100 человек. На первый взгляд, "вроде изян". Но стоит добавить пару деталей, и задача усложняется:

• здание стоит в лесопарковой зоне, где нет оптики, так что наш вариант мобильная связь;

• нужно обеспечить регулярные видеотрансляции, то есть добиться стабильного интернета при единственном GSM-провайдере;

• бюджет ограничен.

Итого: потери и отвалы от базовой станции подкрадываются в самое неподходящее время.

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

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

Схема решения вкратце

Итак, при первом столкновении с проблемой отвалов я начал с агрегации частот и убедился, что это не поможет. Смена категории LTE-модема с Cat4 на Cat6 или еще круче Cat12 давала преимущество в скорости, но в потерях и отвалах нет. Пришел к выводу, что нужен второй LTE-провайдер. При этом при переключении не должен потеряться ни один кадр и трансляция не должна отвалиться.

На помощь пришла такая связка: агрегация, она же bonding, и TCP-OpenVPN-туннель поверх этого.

• в облаке создал "сервер агрегации" виртуалку с CLOUD HOSTED ROUTER (CHR) на базе Router OS;

• на ней поднял L2TP-сервер с включенным шифрованием IPsec;

• поверх L2TP over IPsec создал два EoIP-туннеля;

• EoIP-туннели агрегированы bonding-интерфейсом;

• вишенка на торте TCP-шный OpenVPN-туннель.

Итоговая схема:

Вместо виртуальной машины в дата-центре в качестве R1 может выступать любая железка с достаточной производительностью. Например, тот же MikroTik серии CCR, компьютер, размещенный где угодно. Главное позаботиться о производительности и стабильных каналах связи, использовать схемы активного резервирования (VRRP в помощь).

Поддержка OpenVPN UDP реализована только в 7-й версии RouterOS, поэтому в этой конфигурации безальтернативно используется протокол TCP.

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

Теперь расскажу подробнее о строительстве схемы. Начнем с R1 (облачного маршрутизатора) и далее R2 (филиального).

Маршрутизатор R1

1. Сначала берем второй белый IP в дата-центре. У меня CHR находился за Edge в облаке VMware, так что обязательно пробрасываем порты на Edge UDP 1701, 500 и 4500 NAT-T IPSec Network Address Translator Traversal. Также делаем разрешающее правило в межсетевом экране Edge.

2. Добавляем в таблицу firewall filter разрешающее правило доступа к маршрутизатору извне для портов UDP 1701, 500 и 4500. Если у вас белые IP непосредственно на маршрутизаторе без пробросов через Edge, галочку NAT Traversal НУЖНО СНЯТЬ!

   Проверяем дефолтный IPsec-профиль:

   

   /ip ipsec profile set [ find default=yes ] dh-group=modp1024 enc-algorithm=3de
   

3. Создаем профиль для L2TP-туннелей:

   

   /ppp profile add change-tcp-mss=no name=profile01 use-compression=no use-encryption=no use-mpls=no use
   

   и настраиваем учетные записи:

   

   /ppp secretadd local-address=172.16.0.1 name=l2tp_R1-R2_ISP1 password=ros7.elements.forever profile=profile01 remote-address=172.16.0.2 service=l2tpadd local-address=172.16.0.5 name=l2tp_R1-R2_ISP2 password=ros7.elements.forever profile=profile01 remote-address=172.16.0.6 service=l2tp
   

4. Активируем L2TP-сервер и включаем шифрование IPsec:

   

   /interface l2tp-server server set authentication=mschap2 caller-id-type=number default-profile=profile01 enabled=yes ipsec-secret=ВАШ КРУТОЙ ПАРОЛЬ use-ipsec=yes
   

5. Поднимаем два EoIP-туннеля поверх L2TP/IPsec-туннелей:

   

   /interface eoipadd keepalive=1s,5 local-address=172.16.0.1 mac-address=00:00:00:00:00:A1 name=eoip-tun1_over_l2tp_R1-R2_ISP1 remote-address=172.16.0.2 tunnel-id=1add keepalive=1s,5 local-address=172.16.0.5 mac-address=00:00:00:00:00:B1 name=eoip-tun2_over_l2tp_R1-R2_ISP2 remote-address=172.16.0.6 tunnel-id=2
   

   Обязательно указываем минимальный keepalive timeout равным 1 секунде и для каждого EoIP-туннеля указываем уникальный ID.

6. Настраиваем bonding и назначаем на него IP-адрес:

   

   /interface bondingadd lacp-rate=1sec mii-interval=1ms mode=broadcast name=bonding1 slaves=eoip-tun1_over_l2tp_R1-R2_ISP1,eoip-tun2_over_l2tp_R1-R2_ISP2
   

   /ip address add address=172.16.1.1/30 interface=bonding1
   

   Тут важно заметить, что в поле mode (режим работы bonding-интерфейса) я указал broadcast, чтобы пакеты отправлялись сразу по двум тоннелям. Таким образом потеря пакета на любом из двух интерфейсов не приведет к потере пакета на bonding-интерфейсе. Остальные значения устанавливаем, как на картинке.

Активируем OpenVPN-сервер

Так как у меня OpenVPN использовался еще и для внешних подключений, то я предварительно сгенерировал сертификаты и импортировал их в CHR. На этом останавливаться подробно не буду. Создаем /ppp profile и /ppp secret для OpenVPN:

/ppp profile add change-tcp-mss=no name=profile02 use-compression=no use-encryption=no use-mpls=no use/ppp secret add local-address=172.16.2.1 name=ovpn_over_bonding1 password=ros7.elements.forever profile=profile02 remote-address=172.16.2.2 service=ovpn/interface ovpn-server serverset auth=sha1 certificate=server.crt_0 cipher=aes256 default-profile=profile02 enabled=yes keepalive-timeout=30 port=1194 require-client-certificate=yes

Обязательно прописываем в nat-таблицу межсетевого экрана правило для нашей серой филиальной сети за маршрутизатором R2, чтобы трафик выходил наружу через R1:

/ip firewall natadd action=masquerade chain=srcnat out-interface-list=WAN src-address=192.168.1.0/24

Обратный маршрут до серой сети за маршрутизатором R2 указываем через OpenVPN-туннель:

/ip routeadd check-gateway=ping distance=1 dst-address=192.168.1.0/24 gateway=172.16.2.2

Маршрутизатор R2

1. Первым делом прописываем маршруты от одного интерфейса LTE-модема до одного белого IP-адреса дата-центра. Запрещаем в настройках межсетевого экрана в цепочке output прохождение пакетов с другого интерфейса:

   /ip routeadd distance=1 dst-address= 198.51.100.10/32 gateway=lte1add distance=1 dst-address= 198.51.100.20/32 gateway=lte2/ip firewall filteradd action=drop chain=output dst-address= 198.51.100.10 out-interface=lte2add action=drop chain=output dst-address= 198.51.100.20 out-interface=lte1
   

2. Приводим в соответствие с R1 дефолтный конфиг /ip ipsec profile:

   

   /ip ipsec profile set [ find default=yes ] dh-group=modp1024 enc-algorithm=3de
   

3. Создаем /ppp profile:

   

   и два L2TP/IPsec-подключения к дата-центру для каждого из провайдеров:

   

   /ppp profile add change-tcp-mss=no name=profile01 use-compression=no use-encryption=no use-mpls=no use/interface l2tp-clientadd allow=mschap2 connect-to= 198.51.100.10 disabled=no ipsec-secret= ros7.elements.forever keepalive-timeout=30 name=l2tp_to_R1_over_ISP1 password=ros7.elements.forever    profile=profile01 use-ipsec=yes user=l2tp_R1-R2_ISP1add allow=mschap2 connect-to= 198.51.100.20 disabled=no ipsec-secret= ros7.elements.forever keepalive-timeout=30 name=l2tp_to_R1_over_ISP2 password=ros7.elements.forever    profile=profile01 use-ipsec=yes user=l2tp_R1-R2_ISP2
   

4. Создаем EoIP-туннели по аналогии с R1, только меняем местами local и remote IP L2TP/IPsec-линков маршрутизатора R2. Bonding-интерфейс такой же, как на R1:

   

   /interface eoipadd keepalive=1s,5 local-address=172.16.0.2 mac-address=00:00:00:00:00:A2 name=eoip-tun1_over_l2tp_R1-R2_ISP1 remote-address=172.16.0.1 tunnel-id=1add keepalive=1s,5 local-address=172.16.0.6 mac-address=00:00:00:00:00:B2 name=eoip-tun2_over_l2tp_R1-R2_ISP2 remote-address=172.16.0.5 tunnel-id=2/interface bondingadd lacp-rate=1sec mii-interval=1ms mode=broadcast name=bonding1 slaves=eoip-tun1_over_l2tp_R1-R2_ISP1,eoip-tun2_over_l2tp_R1-R2_ISP2/ip address add address=172.16.1.2/30 interface=bonding1
   

5. Также импортируем сертификаты, создаем профиль:

   

   Настраиваем OpenVPN-клиента на R2:

   

   /ppp profile add change-tcp-mss=no name=profile02 use-compression=no use-encryption=no use-ipv6=no use-mpls=no use-upnp=no/interface ovpn-clientadd certificate=client.crt_0 cipher=aes256 connect-to=172.16.1.1 mac-address=00:00:00:00:00:C2 name=ovpn_over_bonding1 password=ВАШ КРУТОЙ ПАРОЛЬ profile=profile02 use-peer-dns=no user="ovpn_over_bonding1 " verify-server-certificate=yes
   

6. Туннели загорелись волшебной буквой R, а EoIP еще и RS. OpenVPN тоже завелся. Теперь можно направлять трафик с компьютера трансляций в наш слоеный бутерброд в OpenVPN-туннель. Для этого создаем правило /ip firewall mangle и прописываем сразу новую таблицу маршрутизации:

   

   /ip firewall mangleadd action=mark-routing chain=prerouting dst-address-list=google_sites dst-port=1935 new-routing-mark=pc_to_stream-youtube_over_R1 passthrough=yes protocol=tcp src-address=192.168.1.1
   

7. Создаем маршрут через наш OpenVPN-туннель с данной таблицей маршрутизации:

   

   /ip routeadd check-gateway=ping distance=1 gateway=172.16.2.1 routing-mark=pc_to_stream-youtube_over_R1
   

И готово!

Траблшутинг

• При развертывании конфигурации на действующем железе нужно обязательно переключить прямой и обратный маршруты с туннелей L2TP на OpenVPN-туннель. Если, например, переключить только прямой маршрут, а обратный оставить на L2TP вместо OpenVPN, агрегация полностью работать не будет и пакеты все равно будут теряться.

• Утилиты RouterOS в разделе /tools очень полезны при траблшутинге. Еще неплохо работает связка /tools Packet Sniffer + Wireshark.

• Не забудьте "поиграться с mtu", чтобы достичь лучшей производительности туннелей.

• Качество сигнала никто не отменял. RSRP, RSRQ и SINR покажут, насколько все хорошо. При большом удалении от базовой станции и плохом сигнале помогут внешние направленные антенны.

• Важно! Если провайдер фильтрует трафик и идет блокировка L2TP, то можно поднять другие туннели в качестве основы для EoIP, например: OpenVPN или SSTP.

• Чтобы проверить все в деле, можно сымитировать сбой. Отключаем любой из LTE-интерфейсов или создаем потери искусственно: добавляем в межсетевой экран правило частичной блокировки пакетов и указываем при создании нового правила значение в поле random.

Что еще можно улучшить и оптимизировать

• Не рекомендую заворачивать весь интернет-трафик, так как это вызовет повышенные накладные расходы (утилизация процессоров, каналов и др.). Лучше пользоваться маркировкой для гарантированной доставки действительно необходимого трафика, а все остальное отправлять на LTE-провайдеров. К примеру, я так делал с загрузкой видеофайлов на облачный диск.

• QOS хорошая штука, особенно на каналах LTE, и особенно с VoIP. Не забываем про это, чтобы остальной трафик не забил и так не слишком широкий канал.

• Можно усилить безопасность, если ограничить подключение извне к портам для L2TP и IPsec маршрутизатора R1. Указываем белый IP LTE-провайдера с помощью firewall и адресных листов. Хоть адрес и из NAT и на нем висит не один клиент, все равно будет лучше. Так как IP динамический, то нужно включить на MikroTik функцию ip cloud, чтобы DNS-сервера всегда знали актуальный IP, технология DDNS.

Конечно же, у схемы есть коммерческие аналоги с возможностями работы из коробки, например: peplink MAX HD4 LTE и тому подобное оборудование, агрегирующие соединения. Тут бизнес сам оценивает их стоимость для себя.

Оставляю ссылки на похожие темы:

• Балансировка нескольких каналов по средствам O-VPN и Bonding в ROS

• Надежная работа Asterisk по каналам 3G/4G/LTE. Делаем RAID-массив из двух каналов

Также тем, кому интересна эта тема, рекомендую покопать в сторону MPTCP (Multipath TCP).

Мы размещаем Exchange Server в виртуальной среде, если хотим гибко масштабироваться и более эффективно использовать ресурсы. Но если виртуализировать без оглядки на лучшие практики, можно срезаться на обидных мелочах.

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

Это статья по итогам моего выступления на Raiffeisen DGTL Communications Online Meetup 21 января.

Оговорки и ограничения

Любое решение в виртуальной среде зависит от конкретных параметров физической инфраструктуры. Как бы мы ни хотели виртуализовываться дальше, мы неразрывно связаны с особенностями конкретных физических серверов.

Поэтому в начале оговорюсь про ограничения для Exchange Server 2019. На один сервер берем 256 Гб памяти и CPU не более двух сокетов. Эти требования растут из требований к физическим серверам. Напомню, что установка Exchange Server на железо (Bare-Metal) предпочитаемая архитектура Exchange Server с точки зрения Microsoft. Если у нас четырехсокетная физическая система, то виртуальная машина не должна выходить за пределы двух сокетов по vCPU. Эти параметры установлены опытным путем большими исследовательскими командами вендоров, так что примем за аксиому.

Сначала была NUMA: правила для vCPU

В первом разделе сформулируем правила работы с ресурсами процессора. Для этого нам нужно сначала обратиться к физической топологии неравномерного доступа к памяти, или NUMA.

Топология NUMA дает процессору доступ и к своей локальной памяти, и к памяти других процессоров. Изначально в распоряжении каждого процессора есть:

• собственный банк памяти, который находится в непосредственной близости к CPU;

• несколько уровней кэша.

Все эти ресурсы памяти вместе с процессором и называют NUMA Node. Для простоты сделаем допущение, что количество физических сокетов в нашей системе равно количеству NUMA-нод. На практике это не так, так как существует Sub-NUMA Clustering. Но в рамках данной статьи мы не будем заострять на этом внимание.

Доступ к памяти других процессоров в рамках NUMA мы обозначаем как Memory Access. Когда при сайзинге виртуальной машины мы выходим за пределы ресурсов одной NUMA-ноды, ВМ размазывается по двум нодам, их память тоже размазывается.

Подводные камни на примере сайзинга ВМ в рамках NUMA Node. Допустим, у нас есть двухпроцессорный сервер, где стоят два процессора с 20 физическими ядрами и 256 Гб памяти, по 128 Гб на каждый процессор. У нас есть виртуальная машина с 20 процессорами и 128 Гб памяти. Любой планировщик любого гипервизора по умолчанию будет стараться разместить ее в рамках одной NUMA-ноды.

Если мы докинем ресурсы процессора до 24, то машина переедет на две физические NUMA-ноды. В этой ситуации мы можем накидывать виртуальной машине до 30 виртуальных процессоров. Но если мы назначим ей нечетное количество процессоров при расположении на двух нодах, планировщик сойдет с ума, пытаясь разделить нечетное число на 2. В результате мы просядем по производительности.

Именно поэтому лучшие практики рекомендуют при сайзинге машины обращаться к таблице распределения по ядрам и NUMA-нодам. Вот пример для такой конфигурации: 4 сокета, 4 физических NUMA-ноды, 24 ядра на сокет, 96 логических потоков.

Все становится еще интереснее, когда появляется vNUMA в ESXi.Подробнее про ее причуды мы уже писали тут.

vNUMA позволяет эмулировать физическую топологию NUMA для ВМ и принудительно располагать ВМ на NUMA-нодах. Начиная с VMware версии 6.0, vNUMA старается предоставить машине топологию в соответствии с физическими NUMA-нодами. Но все равно нужно следить, чтобы физические и виртуальные сущности совпадали. Использование vNUMA поддерживается при развертывании Exchange Server 2016/2019, но с соблюдением ограничения в 2 сокета на одну ВМ.

Нюансы многопоточности и переподписки для разных гипервизоров. Если у процессора есть SMT (Simultaneous Multithreading), то разные планировщики обращаются с ней по-разному. Планировщик VMware сначала смотрит, как расположить ВМ по физическим ядрам, и только потом смотрит на гипертрединг и распределяет все по потокам. Hyper-V же сначала старается разложить ВМ по гипертрединговым ядрам, поэтому теоретически может разместить 2 виртуальные машины в одну NUMA-ноду за счет разных потоков.

Для разных случаев пригодятся разные варианты. Так что для VMware обратим внимание на настройку приоритетов гипертрединга, а затем рассмотрим нюансы переподписки на одном хосте.

Когда важнее гипертрединг. Допустим, у нас есть восьмиядерный процессор и виртуалка VMware с восемью ядрами. В такой конфигурации она будет жить на одной NUMA-ноде. Когда мы сайзим ВМ до 16 ядер, планировщик VMware по умолчанию размещает ее на 2 нодах. Но мы можем оставить ВМ в рамках одной ноды, например, чтобы сохранить быстрый доступ к кэшу одного процессора. В этом случае включаем настройку vcpu.numa.preferHT, которая отдает приоритет потокам SMT.

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

Это становится критичным, если мы размещаем на хостах несколько виртуальных машин. Так возникает переподписка, когда суммарное число ядер всех виртуальных машин на хосте превышает количество физических ядер.

В Hyper-V у нас есть 2 вида планировщика: Classic и Core. Нас интересует работа планировщика Core: он никогда не разместит 2 ВМ с нечетным количеством vCPU на двух соседних потоках (такая защита от Meltdown and Spectre), что увеличивает переподписку в угоду безопасности. Поэтому, в случае виртуализации Exchange Server на Hyper-V следует определиться с типом шедулера. Если требования ИБ позволяют, стоит сменить Core на Classic.

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

Exchange Server часто относят к критичным приложениям, поэтому его тоже рекомендуется выделять в отдельный кластер. В этом случае мы изолируем рабочие нагрузки от других виртуальных машин и не заморачиваемся с настройкой приоритетов для гипертрединга. Если же время не так критично, то допустимым уровнем переподписки считается два к одному: два ядра виртуальной машины к одному физическому ядру на процессоре.

Итак, обобщим все рекомендации по vCPU.

• При сайзинге ВМ всегда отталкиваемся от топологии NUMA конкретного физического сервера.

• Количество vCPU делаем кратным числу физических ядер процессора.

• Если мы выходим за пределы NUMA Node по ядрам, не допускаем нечетного количества ядер виртуального процессора.

• Количество виртуальных процессоров должно быть достаточным, но не избыточным. Лучше докинуть vCPU потом, чем бороться с переподпиской.

• Хорошим тоном является изоляция Exchange server в отдельный кластер ESXi или Hyper-V.

• Если это невозможно, используем пул ресурсов, настраиваем приоритеты процессора для этих ВМ.

• В Hyper-V принять решение о типе шедулеров на хостах.

Правила для оперативной памяти

Здесь мы тоже зависим от топологии NUMA, потому что память и процессор неразрывно связаны. Но в случае с оперативной памятью переподписка не допускается: выделенная память должна быть статична, это входит во все рекомендации VMware и Microsoft. В Hyper-V этот вопрос решен за нас: динамическая память отключена по умолчанию. А вот с VMware все не так однозначно, остановимся на этом подробнее.

Резервирование памяти для ВМ VMware. По умолчанию память VMware ESXi будет динамической. Это значит, что гипервизор в любой момент может забрать у виртуальной машины неиспользуемую память за счет балунинга. Так повышается риск вывода памяти в SWAP: когда гипервизор заберет себе освободившуюся память, слепок памяти ВМ отправится на жесткий диск, производительность упадет. Раньше мы подробно описывали это здесь.

При этом у VMware есть опция горячего добавления памяти (Memory Hot-Add), но эта настройка отключает механизм vNUMA и все равно потребует перезагрузки. Так что не советую ею пользоваться: мы все равно получим простой и рискуем снизить производительность.

Для резервирования памяти под виртуальную машину используем Reservation Pools в режиме All Memory Locked. При этом на других хостах кластера должно быть достаточное количество оперативной памяти, чтобы при перебалансировке DRS или при перезапуске ВМ по HA виртуальная машина могла переехать/перезапуститься на новом хосте. Если же мы строим выделенный кластер под Exchange, то вопрос переподписки уже не стоит так остро.

Сайзинг памяти. При сайзинге виртуальной машины имеет смысл заранее определить предельное значение оперативной памяти.

Чтобы рассчитать ожидаемый размер загрузки, смотрим такие параметры:

• количество почтовых ящиков,

• размеры и количество писем,

• количество активных баз данных и их реплик,

• частота резервного копирования и требования к ресурсам для системы резервного копирования,

• количество пользовательских устройств для доступа к почте.

Этот список параметров не достаточен и сильно зависит от конфигурации Microsoft Exchange.

Как отправную точку для расчетов можно использовать Exchange Calculator, если учитывать несколько его особенностей:

• исходит из максимальных лимитов на ВМ,

• не учитывает топологию NUMA на физических серверах,

• закладывает 10% накладных расходов на гипервизор (в реальности эти накладные расходы не превышают пять процентов),

• не учитывает переподписку по CPU, количество ВМ и конфигурацию гипервизоров.

Теперь обобщим рекомендации для оперативной памяти:

• Рассчитываем память, исходя из топологии NUMA.

• Используем 100% резервирование памяти под ВМ.

• Не допускаем переподписку.

• Не используем горячее добавление памяти.

• Используем выделенный кластер для 100% резервирования памяти под сервер.

• Оставляем минимум 20% свободной памяти на хостах для возможности маневра при балансировке ВМ.

• Если нужно увеличить ресурсы, думаем над горизонтальным расширением DAG.

Общие правила для дисков и сети

Правила хорошего тона для дисков и сети применимы не только для Exchange, но касаются виртуализации Windows-сервера вообще. Так что объединил их в один раздел.

Рекомендации для дисковой подсистемы.

В VMware ESXi поддерживаются такие диски:

• VMDK на VMFS6, NFS, vSAN Datastore,

• RDM Raw Device Mapping.

Здесь же поддерживаются разные виртуальные SCSI-контроллеры:

1. LSI Logic SAS. До vSphere 7.0 этот контроллер ставился по умолчанию для виртуальных машин Windows. Как результат, часто можно увидеть развертывания Exchange с его использованием.

   Достоинства:

   • прекрасно распознается Windows без инъекции драйверов;

   • приемлемая производительность по сравнению с AHCI SATA.

   Недостатки:

   • производительность ниже PVSCSI за счет дополнительной прослойки при передаче SCSI-команд;

   • выше нагрузка на CPU по сравнению с PVSCSI;

   • как следствие, более высокая задержка.

2. AHCI SATA Controller. Контроллер SATA можно использовать отдельно или в дополнение к контроллерам LSI или PVSCSI для предоставления большого числа дисков для ВМ. На этом его достоинства заканчиваются.

   Недостатки:

   • выше загрузка CPU на I/O по сравнению с LSI и PVSCSI;

   • ниже общая производительность по сравнению с LSI и PVSCSI;

   • выше латенси по сравнению с LSI и PVSCS.

3. Паравиртуальный SCSI-контроллер (PVSCSI). Контроллер PVSCSI является самым производительным контроллером по сравнению с вышеперечисленными и хорошо подходит для высокопроизводительных сред хранения.

   Достоинства:

   • производительность за счет более прозрачной передачи SCSI-команд;

   • меньше задержка и больше IOPS по сравнению с другими контроллерами;

   • снижение нагрузки на CPU в гостевой ОС (и на ESXi).

   Недостатки (если их можно так назвать):

   • гостевая кластеризация не поддерживается (нельзя отдать Shared VMDK), но это не относится ни к Exchange Server, ни к SQL Server в сценарии Always-On;

   • PVSCSI требует инъекции драйверов в Windows или ВМ, для которой мы хотим заменить LSI на PVSCSI.

   • для добавления требует выключения ВМ.

4. NVMe Controller. Впервые появился в vSphere 6.5. Начиная с vSphere 7.0, является контроллером по умолчанию для ВМ с ОС Windows, вместо морально устаревшего LSI. Этот тип виртуального контроллера оптимизирован для работы на All-Flash массивах (SSD/NVMe). Лишен всех недостатков PVSCSI и сохраняет все преимущества. Следовательно, может рассматриваться как контроллер для баз данных Exchange. На начало 2021 года поддерживает только 15 дисков на контроллер. Этот факт стоит учитывать при планировании хранилищ баз данных Exchange Server.

Для Hyper-V рекомендации по дисковой подсистеме такие:

• VHDX может размещаться на NTFS, ReFS, CSV, SMB3, S2D (т.е. любое поддерживаемое хранилище).

• В сценарии Storage Spaces Direct нужно следить, чтобы виртуальная машина располагалась на хосте-координаторе того тома, где она расположена по хранилищу.

Общие рекомендации к сети.

• Используем синтетические адаптеры: VMXNET3 или Synthetic Network Adapter.

• Включаем и настраиваем RSS со стороны гостевой операционной системы, чтобы параллельно принимать и передавать данные на ВМ по ядрам vCPU. Для VMXNET3 дополнительно включаем Recv Segment Coalescing для IPv4 и IPv6.

• Если есть возможность, используем сетевые адаптеры SR-IOV. Этот способ подойдет, если у нас жесткие требования к пропускной способности сети и нужен гарантированный канал с очень большой скоростью.Но этот пункт скорее для ВМ, которые требовательны к пропускной способности адаптеров.

• Делаем несколько сетевых адаптеров в Exchange-сервере, чтобы использовать механизм SMB Multi-Channel. Так мы сможем не только принимать, но и отдавать несколько потоков через протокол SMB.

И в заключение несколько полезных ссылок по теме:

• Microsoft Exchange Server on VMware vSphere.

• Performance Best Practices for VMware.

• Exchange 2010. Block mode replication.

• Exchange Server Virtualization.

В этой статье расскажу, как работать через API с NSX Edge. Это решение от VMware выполняет для виртуального дата-центра функции маршрутизации, Firewall, NAT, DHCP, VPN и другие. Благодаря возможностям работы через API отправка запросов к Edge становится удобнее и нагляднее, чем в командной строке.

Описанный здесь способ также решает некоторые проблемы обращения к Edge через vCloud Director. При работе через API у нас есть возможность работать с Edge напрямую через NSX или через vCloud Director, а также с помощью API обращаться к БД vCloud Director. Покажу оба варианта.

Вот наиболее интересные сценарии, когда нам пригодится использование API:

1. Миграция Edge в другой NSX-менеджер.

2. Восстановление Edge или части его настроек. Например, если после миграции из одного дата-центра в другой мы также переносим настройки файрвола, VPN, балансировщика нагрузки и т. п.

3. Резервное копирование настроек. Например, если мы хотим сохранить конфигурацию Edge в формате XML и при необходимости вернуться к ней.

В описании я использую NSX-V 6.4.6 и vCloud Director 10.2, однако статья актуальна и для других версий ПО. Для всех экспериментов пользовался документацией по API отсюда.

Готовим инструмент для работы с API

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

Сразу напомню самые распространенные типы запросов:

GET получение информации из инфраструктуры, не выполняет изменения.

POST чаще всего создание нового объекта или добавление конфигурации к существующему.

PUT обновление текущего объекта, старые данные объекта затираются.

DELETE удаление объекта.

Чтобы запросы работали корректно, настроим Postman для работы с NSX-менеджером, который управляет всеми объектами Edge.

1. Открываем Postman и настраиваем авторизацию. Выбираем тип Basic Auth, указываем логин и пароль от админской учетной записи.

   

2. Настраиваем заголовки. Указываем Content-Type: application/xml

   

3. Пробуем вывести список Edge командой GET https://nsx-fqdn/api/4.0/edges (где nsx-fqdn это IP-адрес или FQDN NSX-менеджера).

   

Получили 200 ОК, значит, все в порядке: авторизация, заголовки и другие параметры указаны верно.

Вывод этого запроса покажет длинный список Edge и базовую информацию по каждому из них. Посмотрим, как это использовать в нужном нам сценарии.

Восстанавливаем Edge целиком или его отдельные настройки

Возьмем пример, где актуальны все три сценария использования API.

Итак, у нас есть 2 NSX-менеджера, один из которых мы восстановили в изолированную сеть из бэкапа недельной давности, как описано здесь.

Обозначим оригинальный NSX-менеджер как nsx-fqdn-1, а восстановленный NSX-manager как nsx-fqdn-2. Предположим, по какой-то причине объект edge-8 был удален, и нам необходимо его восстановить.

1. Для начала сформируем запрос на получение конфига этого Edge из восстановленного NSX. Авторизация и заголовки у нас уже настроены, необходимо только указать в запросе нужный FQDN NSX-менеджера.

   GET https://nsx-fqdn-2/api/4.0/edges/edge-8

2. Получаем вот такую конфигурацию. Часть конфигурации изменил, чтобы избежать утечки данных.

   Конфиг целиком.

   <?xml version="1.0" encoding="UTF-8"?><edge>    <id>edge-8</id>    <version>8</version>    <description></description>    <status>deployed</status>    <tenant>88ed64d3-516d-4932-a262-9987e9779f1e</tenant>    <name>vse-test-delete-edge (877a6842-8a67-4dad-87cf-81e155c45763)</name>    <fqdn>vse-f8b2ccec-ef9b-464f-8bab-eb67e27f15c3</fqdn>    <enableAesni>true</enableAesni>    <enableFips>false</enableFips>    <vseLogLevel>info</vseLogLevel>    <vnics>        <vnic>            <label>vNic_0</label>            <name>vnic0</name>            <addressGroups>                <addressGroup>                    <primaryAddress>esxternal-ip</primaryAddress>                    <secondaryAddresses>                        <ipAddress>esxternal-ip</ipAddress>                    </secondaryAddresses>                    <subnetMask>255.255.255.192</subnetMask>                    <subnetPrefixLength>26</subnetPrefixLength>                </addressGroup>            </addressGroups>            <mtu>1500</mtu>            <type>uplink</type>            <isConnected>true</isConnected>            <index>0</index>            <portgroupId>dvportgroup-731</portgroupId>            <portgroupName>internet</portgroupName>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_1</label>            <name>vnic1</name>            <addressGroups>                <addressGroup>                    <primaryAddress>10.0.0.1</primaryAddress>                    <subnetMask>255.255.255.0</subnetMask>                    <subnetPrefixLength>24</subnetPrefixLength>                </addressGroup>            </addressGroups>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>true</isConnected>            <index>1</index>            <portgroupId>virtualwire-380</portgroupId>            <portgroupName>dvs.VCDVStest-1-5ca1ab95-ded5-4af5-bf90-96eaa70e5512</portgroupName>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_2</label>            <name>vnic2</name>            <addressGroups/>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>false</isConnected>            <index>2</index>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_3</label>            <name>vnic3</name>            <addressGroups/>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>false</isConnected>            <index>3</index>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_4</label>            <name>vnic4</name>            <addressGroups/>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>false</isConnected>            <index>4</index>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_5</label>            <name>vnic5</name>            <addressGroups/>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>false</isConnected>            <index>5</index>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_6</label>            <name>vnic6</name>            <addressGroups/>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>false</isConnected>            <index>6</index>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_7</label>            <name>vnic7</name>            <addressGroups/>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>false</isConnected>            <index>7</index>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_8</label>            <name>vnic8</name>            <addressGroups/>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>false</isConnected>            <index>8</index>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>        <vnic>            <label>vNic_9</label>            <name>vnic9</name>            <addressGroups/>            <mtu>1500</mtu>            <type>internal</type>            <isConnected>false</isConnected>            <index>9</index>            <enableProxyArp>false</enableProxyArp>            <enableSendRedirects>true</enableSendRedirects>        </vnic>    </vnics>    <appliances>        <applianceSize>compact</applianceSize>        <appliance>            <highAvailabilityIndex>0</highAvailabilityIndex>            <vcUuid>500615b5-3f65-146a-1d5c-0dce84fc60ea</vcUuid>            <vmId>vm-4274</vmId>            <resourcePoolId>resgroup-53</resourcePoolId>            <resourcePoolName>System vDC (c8a308dd-2509-48ad-ab8e-54e93938394d)</resourcePoolName>            <datastoreId>datastore-1</datastoreId>            <datastoreName>DATASTORE</datastoreName>            <hostId>host-18</hostId>            <hostName>ESXi-host</hostName>            <vmFolderId>group-v453</vmFolderId>            <vmFolderName>Service VMs</vmFolderName>            <vmHostname>vse-f8b2ccec-ef9b-464f-8bab-eb67e27f15c3-0</vmHostname>            <vmName>vse-test-delete-edge (877a6842-8a67-4dad-87cf-81e155c45763)-0</vmName>            <deployed>true</deployed>            <cpuReservation>                <limit>-1</limit>                <reservation>64</reservation>            </cpuReservation>            <memoryReservation>                <limit>-1</limit>                <reservation>256</reservation>            </memoryReservation>            <edgeId>edge-8</edgeId>            <configuredResourcePool>                <id>resgroup-53</id>                <name>System vDC (c8a308dd-2509-48ad-ab8e-54e93938394d)</name>                <isValid>true</isValid>            </configuredResourcePool>            <configuredDataStore>                <id>datastore-1</id>                <name>DATASTORE</name>                <isValid>true</isValid>            </configuredDataStore>            <configuredHost>                <id>host-18</id>                <name>ESXi-host</name>                <isValid>true</isValid>            </configuredHost>            <configuredVmFolder>                <id>group-v453</id>                <name>Service VMs</name>                <isValid>true</isValid>            </configuredVmFolder>        </appliance>        <deployAppliances>true</deployAppliances>    </appliances>    <cliSettings>        <remoteAccess>false</remoteAccess>        <userName>admin</userName>        <sshLoginBannerText>***************************************************************************NOTICE TO USERS This computer system is the private property of its owner, whetherindividual, corporate or government.  It is for authorized use only.Users (authorized or unauthorized) have no explicit or implicitexpectation of privacy. Any or all uses of this system and all files on this system may beintercepted, monitored, recorded, copied, audited, inspected, anddisclosed to your employer, to authorized site, government, and lawenforcement personnel, as well as authorized officials of governmentagencies, both domestic and foreign. By using this system, the user consents to such interception, monitoring,recording, copying, auditing, inspection, and disclosure at thediscretion of such personnel or officials.  Unauthorized or improper useof this system may result in civil and criminal penalties andadministrative or disciplinary action, as appropriate. By continuing touse this system you indicate your awareness of and consent to these termsand conditions of use. LOG OFF IMMEDIATELY if you do not agree to theconditions stated in this warning. ****************************************************************************</sshLoginBannerText>        <passwordExpiry>99999</passwordExpiry>    </cliSettings>    <features>        <nat>            <version>3</version>            <enabled>true</enabled>            <natRules>                <natRule>                    <ruleId>196609</ruleId>                    <ruleTag>196609</ruleTag>                    <loggingEnabled>false</loggingEnabled>                    <enabled>true</enabled>                    <translatedAddress>esxternal-ip</translatedAddress>                    <ruleType>user</ruleType>                    <action>snat</action>                    <vnic>0</vnic>                    <originalAddress>10.0.0.0/24</originalAddress>                    <snatMatchDestinationAddress>any</snatMatchDestinationAddress>                    <protocol>any</protocol>                    <originalPort>any</originalPort>                    <translatedPort>any</translatedPort>                    <snatMatchDestinationPort>any</snatMatchDestinationPort>                </natRule>                <natRule>                    <ruleId>196610</ruleId>                    <ruleTag>196610</ruleTag>                    <loggingEnabled>false</loggingEnabled>                    <enabled>true</enabled>                    <translatedAddress>10.0.0.3</translatedAddress>                    <ruleType>user</ruleType>                    <action>dnat</action>                    <vnic>0</vnic>                    <originalAddress>esxternal-ip</originalAddress>                    <dnatMatchSourceAddress>any</dnatMatchSourceAddress>                    <protocol>tcp</protocol>                    <originalPort>443</originalPort>                    <translatedPort>8443</translatedPort>                    <dnatMatchSourcePort>any</dnatMatchSourcePort>                </natRule>            </natRules>            <nat64Rules/>        </nat>        <l2Vpn>            <version>2</version>            <enabled>false</enabled>            <logging>                <enable>true</enable>                <logLevel>notice</logLevel>            </logging>        </l2Vpn>        <featureConfig/>        <featureConfig/>        <dns>            <version>2</version>            <enabled>false</enabled>            <cacheSize>16</cacheSize>            <listeners>                <vnic>any</vnic>            </listeners>            <dnsViews>                <dnsView>                    <viewId>view-0</viewId>                    <name>vsm-default-view</name>                    <enabled>true</enabled>                    <viewMatch>                        <ipAddress>any</ipAddress>                        <vnic>any</vnic>                    </viewMatch>                    <recursion>false</recursion>                </dnsView>            </dnsViews>            <logging>                <enable>false</enable>                <logLevel>info</logLevel>            </logging>        </dns>        <syslog>            <version>2</version>            <enabled>false</enabled>            <protocol>udp</protocol>        </syslog>        <sslvpnConfig>            <version>2</version>            <enabled>false</enabled>            <logging>                <enable>true</enable>                <logLevel>notice</logLevel>            </logging>            <advancedConfig>                <enableCompression>false</enableCompression>                <forceVirtualKeyboard>false</forceVirtualKeyboard>                <randomizeVirtualkeys>false</randomizeVirtualkeys>                <preventMultipleLogon>false</preventMultipleLogon>                <clientNotification></clientNotification>                <enablePublicUrlAccess>false</enablePublicUrlAccess>                <timeout>                    <forcedTimeout>0</forcedTimeout>                    <sessionIdleTimeout>10</sessionIdleTimeout>                </timeout>            </advancedConfig>            <clientConfiguration>                <autoReconnect>true</autoReconnect>                <upgradeNotification>false</upgradeNotification>            </clientConfiguration>            <layoutConfiguration>                <portalTitle>VMware</portalTitle>                <companyName>VMware</companyName>                <logoExtention>jpg</logoExtention>                <logoUri>/api/4.0/edges/edge-8/sslvpn/config/layout/images/portallogo</logoUri>                <logoBackgroundColor>56A2D4</logoBackgroundColor>                <titleColor>996600</titleColor>                <topFrameColor>000000</topFrameColor>                <menuBarColor>999999</menuBarColor>                <rowAlternativeColor>FFFFFF</rowAlternativeColor>                <bodyColor>FFFFFF</bodyColor>                <rowColor>F5F5F5</rowColor>            </layoutConfiguration>            <authenticationConfiguration>                <passwordAuthentication>                    <authenticationTimeout>1</authenticationTimeout>                    <primaryAuthServers/>                    <secondaryAuthServer/>                </passwordAuthentication>            </authenticationConfiguration>        </sslvpnConfig>        <featureConfig/>        <highAvailability>            <version>3</version>            <enabled>false</enabled>            <declareDeadTime>15</declareDeadTime>            <logging>                <enable>false</enable>                <logLevel>info</logLevel>            </logging>            <security>                <enabled>false</enabled>            </security>        </highAvailability>        <routing>            <version>3</version>            <enabled>true</enabled>            <routingGlobalConfig>                <ecmp>false</ecmp>                <logging>                    <enable>false</enable>                    <logLevel>info</logLevel>                </logging>            </routingGlobalConfig>            <staticRouting>                <defaultRoute>                    <vnic>0</vnic>                    <mtu>1500</mtu>                    <gatewayAddress>external-ip</gatewayAddress>                    <adminDistance>1</adminDistance>                </defaultRoute>                <staticRoutes/>            </staticRouting>            <ospf>                <enabled>false</enabled>                <ospfAreas>                    <ospfArea>                        <areaId>51</areaId>                        <type>nssa</type>                        <authentication>                            <type>none</type>                        </authentication>                    </ospfArea>                    <ospfArea>                        <areaId>0</areaId>                        <type>normal</type>                        <authentication>                            <type>none</type>                        </authentication>                    </ospfArea>                </ospfAreas>                <ospfInterfaces/>                <redistribution>                    <enabled>false</enabled>                    <rules/>                </redistribution>                <gracefulRestart>true</gracefulRestart>                <defaultOriginate>false</defaultOriginate>            </ospf>        </routing>        <featureConfig/>        <gslb>            <version>2</version>            <enabled>false</enabled>            <serviceTimeout>6</serviceTimeout>            <persistentCache>                <maxSize>20</maxSize>                <ttl>300</ttl>            </persistentCache>            <queryPort>5666</queryPort>            <logging>                <enable>false</enable>                <logLevel>info</logLevel>            </logging>        </gslb>        <firewall>            <version>6</version>            <enabled>true</enabled>            <globalConfig>                <tcpPickOngoingConnections>false</tcpPickOngoingConnections>                <enableFtpLooseMode>false</enableFtpLooseMode>                <tcpAllowOutOfWindowPackets>false</tcpAllowOutOfWindowPackets>                <tcpSendResetForClosedVsePorts>true</tcpSendResetForClosedVsePorts>                <dropInvalidTraffic>true</dropInvalidTraffic>                <logInvalidTraffic>false</logInvalidTraffic>                <tcpTimeoutOpen>30</tcpTimeoutOpen>                <tcpTimeoutEstablished>21600</tcpTimeoutEstablished>                <tcpTimeoutClose>30</tcpTimeoutClose>                <udpTimeout>60</udpTimeout>                <icmpTimeout>10</icmpTimeout>                <icmp6Timeout>10</icmp6Timeout>                <ipGenericTimeout>120</ipGenericTimeout>                <enableSynFloodProtection>false</enableSynFloodProtection>                <logIcmpErrors>false</logIcmpErrors>                <dropIcmpReplays>false</dropIcmpReplays>                <enableSnmpAlg>true</enableSnmpAlg>                <enableFtpAlg>true</enableFtpAlg>                <enableTftpAlg>true</enableTftpAlg>            </globalConfig>            <defaultPolicy>                <action>deny</action>                <loggingEnabled>false</loggingEnabled>            </defaultPolicy>            <firewallRules>                <firewallRule>                    <id>131076</id>                    <ruleTag>131076</ruleTag>                    <name>firewall</name>                    <ruleType>internal_high</ruleType>                    <enabled>true</enabled>                    <loggingEnabled>false</loggingEnabled>                    <description>firewall</description>                    <action>accept</action>                    <source>                        <exclude>false</exclude>                        <vnicGroupId>vse</vnicGroupId>                    </source>                </firewallRule>                <firewallRule>                    <id>131077</id>                    <ruleTag>131077</ruleTag>                    <name>test</name>                    <ruleType>user</ruleType>                    <enabled>true</enabled>                    <loggingEnabled>false</loggingEnabled>                    <action>accept</action>                    <source>                        <exclude>false</exclude>                        <vnicGroupId>vnic-index-1</vnicGroupId>                    </source>                    <application>                        <service>                            <protocol>icmp</protocol>                            <icmpType>any</icmpType>                        </service>                    </application>                </firewallRule>                <firewallRule>                    <id>131075</id>                    <ruleTag>131075</ruleTag>                    <name>default rule for ingress traffic</name>                    <ruleType>default_policy</ruleType>                    <enabled>true</enabled>                    <loggingEnabled>false</loggingEnabled>                    <description>default rule for ingress traffic</description>                    <action>deny</action>                </firewallRule>            </firewallRules>        </firewall>        <loadBalancer>            <version>2</version>            <enabled>false</enabled>            <enableServiceInsertion>false</enableServiceInsertion>            <accelerationEnabled>false</accelerationEnabled>            <monitor>                <monitorId>monitor-1</monitorId>                <type>tcp</type>                <interval>5</interval>                <timeout>15</timeout>                <maxRetries>3</maxRetries>                <name>default_tcp_monitor</name>            </monitor>            <monitor>                <monitorId>monitor-2</monitorId>                <type>http</type>                <interval>5</interval>                <timeout>15</timeout>                <maxRetries>3</maxRetries>                <method>GET</method>                <url>/</url>                <name>default_http_monitor</name>            </monitor>            <monitor>                <monitorId>monitor-3</monitorId>                <type>https</type>                <interval>5</interval>                <timeout>15</timeout>                <maxRetries>3</maxRetries>                <method>GET</method>                <url>/</url>                <name>default_https_monitor</name>            </monitor>            <logging>                <enable>false</enable>                <logLevel>info</logLevel>            </logging>        </loadBalancer>        <ipsec>            <version>2</version>            <enabled>false</enabled>            <logging>                <enable>true</enable>                <logLevel>warning</logLevel>            </logging>            <sites/>            <global>                <psk>******</psk>                <caCertificates/>                <crlCertificates/>            </global>        </ipsec>        <bridges>            <version>2</version>            <enabled>false</enabled>        </bridges>        <dhcp>            <version>2</version>            <enabled>false</enabled>            <staticBindings/>            <ipPools/>            <logging>                <enable>false</enable>                <logLevel>info</logLevel>            </logging>        </dhcp>    </features>    <autoConfiguration>        <enabled>true</enabled>        <rulePriority>high</rulePriority>    </autoConfiguration>    <type>gatewayServices</type>    <isUniversal>false</isUniversal>    <hypervisorAssist>false</hypervisorAssist>    <tunnels/></edge>
   

3. Теперь на основе полученной конфигурации в виде XML создадим новый Edge. Для этого:

   • Удаляем из него данную часть

     <id>edge-8</id><version>8</version><status>deployed</status>
     

   • Меняем <name> </name>, если Edge с таким именем уже есть.

   • Если мы хотим восстановиться в другое место, меняем теги расположения

     <resourcePoolId><resourcePoolName><vmFolderId><vmFolderName>
     

     и другие.

   • С помощью тега <password> </password> вставляем пароль на Edge между тегами <userName> и <sshLoginBannerText>, например:

     <userName>admin</userName><password>Test123!test123!</password><sshLoginBannerText>
     

   • Удаляем из раздела NAT теги ruleId, ruleTag, ruleType, например:

     <ruleId>196609</ruleId><ruleTag>196609</ruleTag><ruleType>user</ruleType>
     

4. С помощью итоговой XML выполняем команду на создание нового Edge. Для этого вставим в поле Body всю XML, укажем тип raw XML и отправим запрос.

   POST https://nsx-fqdn-1/api/4.0/edges/

   

Edge восстановлен под именем edge-9.

Теперь отдельно восстановим настройки.

1. Разберемся с ситуацией, когда нам нужно отдельно добавить правила NAT. Для начала нужно понять, в каком формате Edge формирует эти правила. Можно посмотреть в общем конфиге по тегу <nat>. Но чтобы долго не искать, получим NAT-правила отдельным запросом:

   GET https://nsx-fqdn-1/api/4.0/edges/edge-9/nat/config

2. Добавим правила NAT с помощью POST-запроса. Для этого сначала удалим теги ruleId, ruleTag, ruleType, в нашем случае:

   <ruleId>196609</ruleId><ruleTag>196609</ruleTag><ruleType>user</ruleType>
   

   И отправляем POST https://nsx-fqdn-1/api/4.0/edges/edge-9/nat/config/rules

   Пример NAT-правила:

   <natRules><natRule><action>dnat</action><vnic>0</vnic><originalAddress>esxternal_ip</originalAddress><translatedAddress>192.168.1.9</translatedAddress><loggingEnabled>false</loggingEnabled><enabled>true</enabled><description></description><protocol>udp</protocol><originalPort>80</originalPort><translatedPort>80</translatedPort></natRule></natRules>
   

   

3. Важно учесть, что правила NAT через POST-запрос не перезаписываются, а добавляются заново.

   Вот что будет, если выполнить запрос дважды:

   

Аналогично можно выполнить операции и с настройками по другим сервисам (firewall, vpn, load balancer и другие). На будущее мы можем сохранить настройки в виде XML и хранить этот файл в качестве резервной копии.

Используем API вместе с vCloud Director. В нашем сценарии мы случайно удалили нужный нам Edge и затем восстановили его из резервной копии через API. Если Edge использовался vCloud Directorом, но был удален через NSX-менеджер, то сам объект edge-8 удалится из vCenter, а ссылка на него останется. После восстановления наш Edge получил новый id, о котором vCenter еще не знает. При попытке обратиться к сервисам через vCloud Director всплывет белый экран. Чтобы исправить это, внесем исправления в БД vCloud Director для изменения id c edge-8 на edge-9.

1. Отправим запрос для таблицы gateway, чтобы узнать id:

   select * from gateway where name like 'test-delete-edge%'

   Получим:

   -- id=' 877a6842-8a67-4dad-87cf-81e155c45763 ' --name=' test-delete-edge' --backing-ref='edge-8'

2. Проверяем, в каких таблицах есть упоминание об этом Edge:

   select * from global_search('edge-8')

   

3. Проверяем, что выбрали нужный Edge:

   select * from gateway where id = '877a6842-8a67-4dad-87cf-81e155c45763'

4. Обновляем id Edge и убеждаемся, что он изменен.

   update gateway set backing_ref = 'edge-9' where id = '877a6842-8a67-4dad-87cf-81e155c45763'

5. Проверим Edge со стороны vCloud Director.

Теперь сервисы отображаются корректно.

Перенесем сервисы из одного Edge в другой

Иногда с Edge требуется работать напрямую через vCloud Director, но и здесь Postman может пригодиться. Рассмотрим сценарий переноса сервисов через API vCloud Director с сохранением адресации:

1. Открываем Postman.

2. Настраиваем авторизацию:

   Autorization: Basic Auth - administrator@system

3. Затем выполняем GET https://vCD-fqdn/api/versions

   Проверяем, отработал ли запрос и смотрим на версии api.

   

4. Добавляем заголовок с этой версией:

   Accept application/*+xml;version=35.0

5. Теперь перейдем на авторизацию по токену. Сначала получим токен с помощью запроса POST https://vCD-fqdn/api/sessions

   Берем отсюда: X-VMWARE-VCLOUD-ACCESS-TOKEN.

6. Поменяем тип авторизации на Bearer Token и вставим значение X-VMWARE-VCLOUD-ACCESS-TOKEN.

7. Выполняем запрос GET https://vCD-fqdn/api/admin, чтобы убедиться, что авторизация по токену работает.

8. Открываем Powershell и выполняем connect-ciserver vCD-fqdn

   Далее: Get-OrgVdc OrgVDCName| Get-EdgeGateway EdgeName

   Копируем ссылку после Href.

   Href: https://vCD-fqdn/api/admin/edgeGateway/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

   

9. Возвращаемся в Postman и получаем исходный конфиг с помощью этой ссылки:

   GET https://vCD-fqdn/api/admin/edgeGateway/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

10. Создаем тело запроса на основе полученной конфигурации. Для этого берем такую шапку:

    <?xml version="1.0" encoding="UTF-8"?><EdgeGatewayServiceConfiguration   xmlns="http://personeltest.ru/away/www.vmware.com/vcloud/v1.5">
    

    и дальше копируем то, что было между тегами <EdgeGatewayServiceConfiguration></EdgeGatewayServiceConfiguration>

    Например:

    <?xml version="1.0" encoding="UTF-8"?><EdgeGatewayServiceConfiguration   xmlns="http://personeltest.ru/away/www.vmware.com/vcloud/v1.5">            <GatewayDhcpService>                <IsEnabled>false</IsEnabled>            </GatewayDhcpService>            <FirewallService>                <IsEnabled>true</IsEnabled>                <DefaultAction>allow</DefaultAction>                <LogDefaultAction>false</LogDefaultAction>            </FirewallService>            <NatService>                <IsEnabled>true</IsEnabled>                <NatRule>                    <RuleType>SNAT</RuleType>                    <IsEnabled>true</IsEnabled>                    <Id>196609</Id>                    <GatewayNatRule>                        <Interface href="http://personeltest.ru/aways/fqdn-vcd/api/admin/network/xxxxxx" name="network" type="application/vnd.vmware.admin.network+xml"/>                        <OriginalIp>10.0.0.0/24</OriginalIp>                        <TranslatedIp>external-ip</TranslatedIp>                    </GatewayNatRule>                </NatRule>            </NatService>            <GatewayIpsecVpnService>                <IsEnabled>false</IsEnabled>            </GatewayIpsecVpnService>            <StaticRoutingService>                <IsEnabled>true</IsEnabled>            </StaticRoutingService>            <LoadBalancerService>                <IsEnabled>false</IsEnabled>            </LoadBalancerService></EdgeGatewayServiceConfiguration>
    

    Если на Edge меняются портгруппы, необходимо в теге <Interface/> заменить сети из старого Edge на сети из нового Edge, куда переносим сервисы:

    <Interface href="http://personeltest.ru/aways/fqdn-vcd/api/admin/network/xxxxxx" name="network" type="application/vnd.vmware.admin.network+xml"/>
    

11. Добавим новую конфигурацию POST-запросом. Для этого вставим полученную XML в Body в формате raw для пустого Edge. Добавляем заголовок content-type application/vnd.vmware.admin.edgeGatewayServiceConfiguration+xml

    В сам запрос вставляем ссылку на нужный Edge, добавив к url /action/configureServices, например:

    POST https://vCD-fqdn/api/admin/edgeGateway/XXXX/action/configureServices

Конфигурация перенесена.

Этим же способом можно автоматизировать процесс сбора конфигурации. Так можно собирать XML для каждого Edge с помощью скриптов, опрашивающих api. Еще одна отдельная тема открытие доступа к БД vCloud Director, а также некоторые операции с БД. Если интересно узнать об этом подробнее, пишите, расскажу отдельно.

Сегодня отправимся в Калининский район Санкт-Петербурга и со всех сторон посмотрим на дата-центр "Ростелеком-ЦОД", который запустился в декабре 2020 года. Новый ЦОД построили "с нуля" недалеко от корпусов завода ЛОМО по адресу: ул. Жукова, 43 (не путать с проспектом Маршала Жукова!).

Пять лет назад здесь было заброшенное строительство мазутохранилища (любим строить на территориях старых заводов). Сейчас на петербургской площадке заказчики уже арендовали первые стойки и заработали облачные сервисы DataLine.

Несколько фактов про ЦОД

• Общая площадь: 4 266 кв м.

• Общая емкость: 792 стойко-мест.

• 4 машинных зала, до 198 стоек каждый.

• Проектная мощность: 7 400 кВт.

• Соответствует стандарту Tier III.

Из истории

Перспективную территорию в Санкт-Петербурге заметили еще в 2016 году. Когда-то давно здесь хотели построить мазутохранилище для ТЭЦ, но в конце 1980-х строительство забросили, и площадка так и оставалась невостребованной.

Зато этим местом интересовались киношники. В огромных резервуарах стояла вода, в них проходили подводные съемки для петербургских фильмов.

В 2018 году здесь начался демонтаж.

Затем площадку дренировали и подготовили почву к строительству. Так как местность оказалась болотистой, фундамент дополнительно укрепили с помощью бетонной плиты на глубине 8 метров.

В 2019 основное строительство завершилось, а в 2020 началось самое интересное: монтаж инженерных систем. Мы немного следили за процессом и делились наблюдениями в соцсетях по хештегу #дневникстройки заглядывайте по ссылке, если тоже любите стройку.

Посмотрим, что появилось на месте стройплощадки.

Физическая безопасность

Добраться до дата-центра в Санкт-Петербурге удобнее всего по улице Чугунной. На общественном транспорте можно доехать до ст. м. "Выборгская" и сесть на маршрутку К-283 до остановки "Чугунная, 46". Вход и въезд через ворота со стороны ул. Чугунной.

На территории дата-центра действует пропускная система: заранее заказываем пропуск и на входе предъявляем охраннику паспорт. Водителям на своем авто также нужно указать номер машины.

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

Вся прилегающая территория хорошо просматривается благодаря видеокамерам.

Внутрь здания дата-центра проходим через турникет мимо еще одного поста охраны. Здесь оборудован "наблюдательный пункт": охранники видят трансляцию со всех внутренних и внешних камер наблюдения.

Машинные залы

На первом этаже симметрично расположены 2 независимых модуля. В каждом из них по 2 машинных зала с собственными энергоцентром и хладоцентром.

Нужный машзал легко найти по навигации на стенах. Залы назвали в честь островов Санкт-Петербурга:

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

Внутри каждого машинного зала можно разместить до 198 стоек от 5 кВт. Например, этот зал пока пустой, но скоро стойки отправятся на свои места.

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

Стойки в залах расставлены по принципу горячих и холодных коридоров. Оборудование выбрасывает нагретый воздух в горячий коридор и забирает охлажденный воздух из холодного коридора через перфорированные плитки фальшпола. В каждом холодном коридоре поддерживается температура 232 градуса и влажность 3070 %.

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

Такие же желтые трубы расположены под потолком. При пожаре в зал через распылители поступит специальный огнетушащий газ.

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

Энергоснабжение

Cистема энергоснабжения в дата-центре зарезервирована по схеме 2N. В ЦОДе 2 отдельных энергоцентра в каждом модуле.

В случае любой аварии один энергоцентр обеспечит питанием залы не только в своем модуле, но и в противоположном.

Каждый модуль оборудован источниками бесперебойного питания (ИБП) и дизельными генераторными установками (ДГУ). Все ИБП тоже зарезервированы по схеме 2N. То есть к каждой стойке подходят 2 независимых ввода бесперебойного электропитания.

Если питание от одного городского ввода пропадает, ИБП автоматически передадут его нагрузку на аккумуляторные батареи (АКБ).

Дата-центр может работать от АКБ до 10 минут. Этого времени хватает для запуска ДГУ. Именно ДГУ отвечают за гарантированное энергоснабжение: даже если весь город обесточен, ДГУ обеспечивают бесперебойную работу оборудования в ЦОДе.

Установки тоже зарезервированы по схеме 2N: трех ДГУ уже достаточно для питания четырех машзалов, а в дата-центре их 6. Система спроектирована таким образом, что зарезервированы не только ДГУ, но и трассы.

Во время работы ДГУ довольно сильно вибрируют. Чтобы вибрация не влияла на основной фундамент, все ДГУ установлены на отдельное бетонное основание.

Каждый дизельный двигатель потребляет примерно 300 литров в час. Топливохранилище ДГУ рассчитано на 25,2 куб. м. При максимальной проектной загрузке ЦОДа ДГУ могут работать в аварийном режиме 12 часов без дозаправки. В рабочем режиме и при нормальной загрузке гораздо больше.

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

Если же запасы начнут истощаться, топливо для дозаправки подвезут за 6 часов. Все сроки прописаны в контракте с поставщиком, предусмотрены премии за быстрое выполнение заказа. Заправка на работу дизеля не влияет.

Для топливозаправщика на территории ЦОДа оборудована специальная площадка. На месте заправки поставщик подключается к трубопроводу, открывает задвижки и насосы автоматически начинают работу.

Холодоснабжение

Охлаждение оборудования обеспечивает чиллерная схема холодоснабжения с этиленгликолем в качестве теплоносителя. На крыше работают чиллеры и охлаждают циркулирующий в трубах гликоль. В двух хладоцентрах на первом этаже находятся насосы, расширительные баки, разводка всех труб и оборудование для управления системой. А в машинных залах, помещениях АКБ, энергоцентре и телеком-аппаратных установлены внутренние блоки кондиционеров.

Все элементы зарезервированы по схеме N+1. Это значит, что выход из строя любого из элементов не повлияет на работу системы: нагрузка распределится между оставшимся оборудованием.

В каждом машинном зале установлено 8 прецизионных кондиционеров Vertiv PCW PH136EL. 4 из 8 кондиционеров в зале с функцией пароувлажнения.

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

К обратной магистрали подключены расширительные баки: они ограничивают колебания давления из-за разницы температур.

Из обратного контура насосы забирают нагретый этиленгликоль и отправляют его на крышу к чиллерам, чтобы охладить до 10 градусов.

Трубы на крышу идут через вентиляционные камеры на втором этаже.

На крыше установлены 6 чиллеров Vertiv FD4130-LN. Чиллеры окружены звукоизолирующими панелями. Дата-центр расположен в стороне от жилых кварталов, но так мы точно уверены, что шум не выйдет за пределы промзоны.

Здесь же на крыше находятся аккумулирующие баки. В них хранится охлажденный этиленгликоль на случай отказа электропитания чиллеров. Если городское электропитание пропадает, во время перехода на ДГУ часть чиллеров перезапускается. Для выхода на рабочую мощность чиллерам нужно до 5 минут, а баков хватит на 6 минут.

Пожарная безопасность

Дата-центр оборудован газовой станцией пожаротушения. Отсюда трубы расходятся по всему дата-центру: в нашей системе пожаротушения 16 направлений. Система зарезервирована по схеме 2N. Всего здесь стоит 24 баллона, на каждое направление тушения предусмотрен основной и резервный запас огнетушащего вещества. Внутри баллонов находится хладон-227еа, этот газ безопасен для ИТ-оборудования в ЦОДе.

Если в помещении возникает дым, система автоматической пожарной сигнализации отправляет сигнал от датчиков пожарообнаружения. Сигналы поступают в диспетчерскую, где сидят дежурные инженеры. Здесь расположен контрольно-индикационный блок, где сразу загорается табло "ТРЕВОГА" или "ПОЖАР". Если сработали оба датчика, в дата-центре запустится система оповещения.

Чтобы дежурные могли быстро понять, где и какой датчик сработал, на мониторы автоматизированного рабочего места выведена вся схема здания с расстановкой датчиков.

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

Мониторинг

В систему мониторинга стекаются сигналы от всего инженерного оборудования. Инженеры круглосуточно отслеживают основные показатели работы: состояние систем энергоснабжения и кондиционирования, климат в каждом зале, физическую безопасность. Для наблюдения за многими параметрами в центре мониторинга оборудована видеостена. У дежурных в диспетчерской также стоит отдельный монитор для слежения за системой. Здесь можно "провалиться" внутрь и посмотреть состояние оборудования и его параметры.

Все показатели систем мониторинга со всех площадок сводятся в единый ситуационный центр в Москве.

Телеком

В дата-центр независимыми маршрутами заведены 2 телеком-ввода от магистралей "Ростелекома".

Также на площадке есть операторы со своей оптикой: Северен-Телеком, ОБИТ, Комфортел. Еще здесь работает Филанко и скоро появится Авантел. Дата-центр готов принять любого телеком-провайдера, удобного клиенту.

На площадке обеспечивается надежная сетевая связность с другими дата-центрами группы "Ростелеком-ЦОД".

Вспомогательная инфраструктура и быт

Для транспортировки оборудования предусмотрено несколько зон погрузки и разгрузки. Вот один из заездов с пандусом:

Так выглядит зона разгрузки внутри:

Не забыли и про бытовые удобства. На кухне почти все готово, скоро здесь появится еще и гарнитур с удобными ящиками для хранения посуды:

Команда дата-центра весь 2020 год готовила новую площадку для комфортной работы коллег и клиентов, несмотря на пандемию.Строительство и эксплуатация дата-центра организованы по нашим единым стандартам, за качество отвечала петербургская часть большой команды "Ростелеком-ЦОД".

Будем рады видеть вас в гостях! Приезжайте в Санкт-Петербург знакомиться и на экскурсию.

В новостях про запуск дата-центров вы обязательно встретите упоминание мощности в киловаттах на стойку. За последний год наша объединенная команда DataLine и Ростелеком-ЦОД запустила 4 дата-центра, и мы каждый раз сталкивались с комментариями в соцсетях и вопросами в чатах:

Сегодня по порядку ответим: как мы считаем мощность на стойку, почему эта цифра не ограничивает заказчика, а наоборот, экономит его ресурсы. Объясню с точки зрения статистики и возьму пару наглядных аналогий из популярной книги Статистика и котики (очень классного пособия для обновления забытых знаний).

Представим, что у нас 10 котиков (а мы знаем примеры, когда и 100 котиков бывает). Самый маленький котик ест 1 кг корма, средний 3, а самый крупный вообще 10. Мы не покупаем каждому по 10, а подсчитываем общий расход корма на всех и планируем покупки из среднего значения. Так же, ну или почти так же со стойками.

Как мы считаем киловатты на стойку и причем тут котики

Показатель средней мощности на стойку помогает провайдеру еще на этапе проектирования спланировать основные ресурсы: электричество, холод и место. В случае с котиками такие ресурсы тоже есть: корм, вода и туалет.

Этот вид планирования называют capacity management (можете так и передать своим пушистым). Мы уже рассказывали о нем раньше в другой статье. Напомню, что основной принцип такого планирования электричество, холод и место в дата-центре должны заканчиваться одновременно. Мы не можем допустить использование какого-то ресурса вхолостую и потому следим, чтобы все расходовалось равномерно. С закупками для котов бывает похожая ситуация: оптимальнее покупать корм и наполнитель сразу, еще и скидку от зоомагазина получить.

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

Чтобы подвести достаточно электричества к каждой запланированной стойке, нужно знать ее потребление. Возникает вопрос, как предсказать мощность стоек. Тут есть 2 варианта дата-центров:

• Если это корпоративный ЦОД, то требования компании могут включать любое количество высоконагруженных стоек. Например, недавно мы спроектировали для заказчика зал со стойками более 15 кВт.

• Если это коммерческий ЦОД с множеством независимых заказчиков, нужно оценить реальные потребности рынка.

Во втором случае нам помогает наша статистика. Вот уже 13 лет мы ежеминутно собираем данные по потреблению наших 5000 стоек.

В статистику входят компании из разных отраслей. У кого-то уходит 7 кВт на стойку, у кого-то 3 кВт. Мы считаем среднее арифметическое по потреблению и смотрим динамику за последние годы. Сейчас в среднем получаем 4 кВт на стойку. Рост потребления с 2010 года составляет не больше 100 ватт на стойку в год. Так что для нового дата-центра мы закладываем небольшой запас и получаем те самые 5 кВт на стойку.

Знатоки статистики скажут, что среднее арифметическое не единственный способ узнать центральную тенденцию. И будут правы. Среднее арифметическое не сработает, если у нас есть высоконагруженные стойки, которые существенно сдвинут среднее в свою сторону. Обратимся к таким случаям.

Как статистика учитывает исключения из правила

Основной контраргумент в споре про 5 киловатт примерно такой: Если я поставлю в стойку 3 блейд-корзины, они будут потреблять существенно больше 5 кВт, и что тогда? Давайте разбираться с точки зрения статистики и реальной практики.

Начну с теоретической статистики. Прожорливые стойки намного больше среднестатистической называют выбросом. Для статистики это выглядит так:

Чтобы среднестатистическая стойка отражала реальную ситуацию в машзале, из совокупности рекомендуют убирать 510 % экстремально больших и экстремально маленьких значений и считать усеченное среднее. Так в статистике очищают выборку от исключительных случаев.

Значит, при проектировании мы всегда должны учитывать долю нестандартных стоек у заказчиков. Сейчас кажется, что мы все чаще видим в наших дата-центрах оборудование для high-performance computing с потреблением в районе 25 кВт. Но, по сухой статистике, это все еще пара десятков серверов на зал: как раз вписываются в те самые 10 % выброса.

Допустим, у нас в машинном зале стоит 198 стоек со средним потреблением 5 кВт. Добавим пару стоек в 25 кВт и посчитаем среднее:

(1985+225)/200 = 5,2

5,2 кВт, совсем небольшая разница. Но если таких мощных стоек будет уже 10 (около 5 %), то среднее значение отклонится на целый киловатт:

(1985+1025)/208 =5,96

При этом типичная стойка в этом зале по-прежнему будет потреблять 5 кВт.

На практике эти подсчеты не означают, что мы не учитываем потребности заказчиков с нестандартными стойками. В прошлый раз мы уже показывали, что спокойно размещаем стойки на 8, 11, 15 кВт с соблюдением нескольких правил. Стараемся ставить их в такие места, где с охлаждением точно не будет проблем. Если же у заказчика много высоконагруженных стоек, выделяем для них особые ряды и залы с дополнительным охлаждением. В некоторых новых дата-центрах мы сразу проектируем отдельные залы со стойками повышенной мощности под особые запросы.

Что будет, если планировать стойки с большим запасом

Теперь посмотрим внимательнее на проектирование 3 ресурсов в дата-центре. Что будет на каждом этапе планирования, если мы решим сделать запас больше одного кВт на стойку?

Итак, мы начали проектировать ЦОД от здания: берем общую площадь, вычитаем место под офисную часть и вспомогательные помещения. Понимаем размер машинных залов и прикидываем количество стоек: с учетом всей инфраструктуры исходим из 6 кв. м на стойку. Получившиеся стойки умножаем на планируемую среднюю мощность. Допустим, берем на стойку 6 кВт.

Если мы строим ЦОД в столице, его емкость составит не меньше 1 0002 000 стоек. Итого, 9 000 кВт вместо 7 500 для усредненных 1,5 тысяч стоек. Добавим к этому 30 % на тепло. Уже 11 700 кВт, а не 9 750. Смотрим, есть ли у нас столько подведенной мощности, или нужно докинуть электричества.

Дальше распределяем электричество по нескольким точкам отсечки на схеме электроснабжения:

Посмотрим на мощность самой стойки, которая определена PDU (справа). Дальше по схеме справа налево идет мощность зального щита ЩР. Затем следует мощность щита распределения от ИБП (ЩИБП). Дальше ИБП, и так доходим до ГРЩ. Каждое из этих устройств имеет свою мощность, необходимо распределять нашу нагрузку в этих пределах. Для стоек помощнее нам понадобятся дополнительные ИБП и вообще оборудование помощнее это снова дополнительные расходы.

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

Итого, каждый лишний киловатт приведет к дополнительным затратам на электричество, оборудование для электроснабжения и холодоснабжения. Вся лишняя стоимость по нескольким статьям размажется по всем стойкам нового дата-центра. Но цена за киловатт для заказчика растет не линейно. На каких-то масштабах каждый новый киловатт в 2 раза дороже предыдущего из-за дополнительных затрат на инфраструктуру. Стоимость инфраструктуры растет пропорционально росту мощности, эффекта масштаба здесь уже нет. Зачастую дешевле взять две стойки по 5 кВт, чем одну на 10 кВт.

Именно поэтому мы не рекомендуем брать стойки с запасом на будущее экономически невыгодно не только проектировать на вырост, но и брать стойки на вырост.

Всегда ли заказчику нужно больше 5 кВт в стойке

Когда к нам приходит новый заказчик со стойками больше 5 кВт, наш дизайн-центр должен подготовить проект. Задача ответственного инженера согласовать проект с точки зрения соответствия запросам заказчика. В идеальном сценарии заказчик берет свои требования из реальной статистики: У меня на другой площадке работает точно такое же оборудование и оно потребляет те самые 7-8 заявленных киловатт. Но такое бывает нечасто. Чаще есть примерный список оборудования, которое будет установлено в дата-центре.

Нередко бывает, что в спецификации на серверное оборудование мощность считают по мощности блоков питания и затем закладывают запас 30 %. Получается, что нагрузку рассчитали на бумаге. Но в реальности инженеры никогда не грузят свою систему на 100 %. Реальный коэффициент спроса с сервера будет максимум 80 %, так что искусственный запас будет лишним. Такие расчеты мы корректируем, обсуждаем и согласовываем с заказчиком.

Для понимания общей картины наши инженеры копают еще глубже и анализируют нагрузку с точки зрения задач системы. В сервере несколько потребителей электричества: процессор, память, диски, кулеры. Больше всего ресурсов требует CPU. Например, у сервера со средним потреблением 11,2 кВт на процессор уходит 800900 Вт. При этом далеко не все нагрузки требуют максимальной утилизации процессора. Если мы говорим о среднестатистических задачах вроде файловых шар, почты, системы хранения данных, терминальных серверов или веб-серверов, то загрузка CPU составит 2030 %. Серьезную нагрузку на процессор стоит планировать в случае баз данных: там мы легко можем дойти до 8090 %.

Про 5 кВт с точки зрения ИТ мы говорили с моим коллегой Андреем Будреевым в нашем последнем выпуске подкаста Разговоры из-под фальшпола. Заодно обсудили будущее процессоров с точки зрения экологии заглядывайте на огонек и делитесь своими прогнозами.

Так что не бойтесь дополнительных вопросов от специалистов дата-центра. Мы помогаем заказчикам грамотно планировать нагрузку и за счет этого не только экономим деньги заказчиков, но и правильно распределяем свои ресурсы.

Привет, Хабр! Меня зовут Виктор, я главный инженер-энергетик в мегаЦОДе "Удомля". Мои коллеги уже показывали, как мы организуем гарантированное электропитание дата-центра с помощью ДГУ и регулярно проверяем их работоспособность. Но кроме ДГУ есть другое оборудование, которое может одновременно обеспечить гарантированное электроснабжение и бесперебойное питание. Речь о дизельных динамических ИБП (ДИБП). Такие установки стоят в нашем мегаЦОДе, и мы уже немного рассказывали про их устройство в экскурсии по дата-центру.

Сегодня покажу, как мы проводим тестирование дизельных двигателей ДИБП, чтобы быть уверенными в их надежности.

Немного про устройство ДИБП

ДИБП совмещает функции нескольких устройств в одном: один блок заменяет систему из ДГУ, статических ИБП и аккумуляторных батарей. Правда, и ревут они сильнее: уровень шума от классических ДИБП сравним с шумом от перфоратора.

Схема электроснабжения с ДИБП строится немного по-другому. Городское электропитание с понижающих трансформаторов идет двумя независимыми маршрутами в распределительное устройство низкого напряжения (РУНН). А оттуда через ДИБП электричество поступает сразу на ИТ- и инженерное оборудование. Если питание от города пропадет, ДИБП мгновенно примет всю нагрузку на себя.

У нас в Удомле стоят дизель-роторные источники бесперебойного питания Euro Diesel. В таких ДИБП дизельный двигатель с помощью электромагнитного сцепления соединяется со статогенератором переменного тока. Этот генератор состоит из аккумулятора кинетической энергии и синхронной обратимой электрической машины.

Электромашина может работать в режиме электродвигателя и генератора. Пока ДИБП работает на городском питании, электромашина работает как двигатель и запасает в аккумуляторе кинетическую энергию. Если городское питание пропадает, накопленная энергия высвобождается в обратном направлении и позволяет электромашине обеспечивать электроснабжение дата-центра. Эта же энергия запускает дизель и помогает ему выйти на рабочую частоту. Дизель запускается за одну минуту, и затем уже он обеспечивает питание дата-центра и накопление энергии в аккумуляторе.

Вот так вкратце выглядит схема переключения:

Годовое техническое обслуживание ДИБП на ЦОДе "Удомля" разделено на этапы и проводится несколько раз в течение года. Такой поэтапный график помогает нам сократить простой ДИБП на время обслуживания. Отдельно обслуживаем электрическую часть: проверяем электромагнитное сцепление, проводим обслуживание аккумулятора кинетической энергии и обратимой синхронной электрической машины. Отдельно проверяем и тестируем дизельный двигатель ДИБП. Такое годовое ТО дизеля мы провели в феврале, расскажу о нем подробнее.

План тестирования дизельного двигателя

В тестировании дизеля участвуют наши инженеры службы эксплуатации и инженеры вендора. Во время ТО мы контролируем несколько параметров:

• проверяем резиновые шланги и натяжение ремней генератора,

• проверяем температуру замерзания и уровень охлаждающей жидкости,

• контролируем исправность работы предпусковых подогревателей и состояние радиатора охлаждения двигателя,

• проверяем напряжение заряда батарей, уровень и плотность электролита,

• замеряем остаточную емкость и напряжение АКБ,

• меняем фильтры и масло в двигателе,

• проводим тест дизельного двигателя ДИБП при нагрузке мощностью 100 %.

Благодаря такой программе теста мы не только гарантируем, что ДИБП не подведет в критический момент, но и параллельно контролируем работу систем вентиляции и топливоснабжения.

Тестовый пуск двигателя ДИБП проводится при стопроцентной нагрузке. Когда мы в прошлый раз рассказывали про тестирование ДГУ, то показывали вариант тестирования с реальной нагрузкой. Двигатель ДИБП мы будем обслуживать и тестировать под эквивалентной нагрузкой. Создадим ее с помощью нагрузочных модулей: эти электромеханические устройства моделируют нагрузку нужной мощности.

Такой способ тестирования наиболее рационален для нашего случая. Во-первых, мы не зависим от сторонних нагрузок. ЦОД это живой организм, и количество ИТ-нагрузок может меняться. Во-вторых, проведение теста не влияет на клиентское оборудование и инженерные системы. Даже если во время теста что-то пойдет не так, электроснабжение клиентского оборудования и инженерных систем ЦОДа не пострадает.

Подготовка к тестированию

Оповещение. За 7 календарных дней до начала ТО служба технической поддержки предупреждает о работах клиентов ЦОДа и службу эксплуатации. Обязательно указываем время и последовательность тестирования. На 6 установленных ДИБП у нас отводится 6 дней.

Заказ нагрузочных модулей. До начала ТО в ЦОД поставляются расходные материалы и нагрузочные модули. Мы используем 2 модуля, по 1 мВт каждый.

Переключение ДИБП и подключение нагрузки. Мы начинаем ТО с остановки ДИБП и подключения модулей. Все переключения производятся на двух щитах ДИБП: управления и силовом.

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

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

Регламентные работы перед тестовым пуском

Первые этапы по плану ТО нужно выполнить при выключенном генераторе. Поэтому сначала выведем установку в ремонт.

1. Перейдем к панели управления ДИБП. На дисплее слева мы видим, чтопитание ИТ-оборудования и инженерных систем ЦОДа идет по стандартной схеме. На схеме обозначены автоматические выключатели в цепи: QD1, QD2 включены, QD3 отключен.

   

   Справа видим ключ в положении "Нагрузка защищена". Это означает, что бесперебойная работа всего оборудования под защитой ИБП. Электромашина работает в режиме электродвигателя, аккумулятор накапливает кинетическую энергию, все хорошо:

   

2. Справа при помощи верхнего ключа переводим режим работы на механизм обходного пути, или байпас (о нем уже рассказывали в одной из статей). С его помощью запитанное от ДИБП оборудование сразу переводится на питание от города в обход установки, а генератор отключается от сети. Теперь на схеме мы видим, что выключатели QD1 и QD2 отключены, QD3 включен:

   

3. Чтобы никто случайно не включил установку и не поставил под угрозу выполнение регламентных работ, мы переводим выключатели QD1, QD2 в ремонтное положение на силовой панели ДИБП:

   

После остановки накопителя и генератора проводим регламентные работы по плану тестирования: проверяем ремни, жидкости, фильтры, все системы и агрегаты.

Тестовый пуск двигателя ДИБП под нагрузкой

После всех манипуляций по плану ТО переходим к заключительной стадии тесту дизельного двигателя под нагрузкой 100 %.

1. На силовом щите ставим выключатели QD1, QD2 обратно в рабочее положение. Ключ управления переводим в положение "УПРАВЛ. ЧЕРЕЗ HMI". Кнопки на сенсорной панели станут активны.

2. Включаем машину в режиме "БАЙПАС-RUN". Видим на схеме, что QD1 включен, QD2 выключен.

   

   Теперь генератор получает питание от городской сети и работает как электродвигатель, раскручивая аккумулятор кинетической энергии. ИТ-оборудование и инженерные системы ЦОДа получают питание по байпасу через QD3.

3. Переводим ДИБП в режим тестирования: открываем щит управления и устанавливаем переключатель "TEST KS" в положение 1.

   

   В режиме теста выключатель QD2 блокируется. На экране панели появляется надпись "РЕЖИМ ТЕСТА KS".

4. Следующий шаг подключение нагрузочных модулей к шинам генератора.

   В самом начале мы подключили нагрузочные модули к щиту. Теперь включаем нагрузку при помощи автоматов QDL в силовых панелях ДИБП. Проводим эту операцию в ручном режиме: закатываем выключатель QDL в рабочее положение, разблокируем его ключом, взводим пружину и включаем.

   

5. Чтобы запустить двигатель ДИБП, проводим тестовый отказ сети. Нажимаем кнопки "ОТКАЗ СЕТИ" и "FORCE" на панели управления.

   

6. Двигатель в работе, обратимая электрическая машина в режиме генератора питает нагрузочные модули, городская сеть отключена.

   ДИБП работает в режиме генератора.

7. Теперь поднимаем нагрузку до необходимых значений. Для этого используем переключатели на панелях нагрузочных модулей. На панели управления ДИБП видим, что этот параметр достиг 1764,1 кВт.

   Смотрим на работу ДИБП под нагрузкой.

Двигатель работает в этом режиме около 2 часов. Во время теста мы контролируем несколько параметров ДИБП:

• температуру подшипников,

• скорость вращения валов,

• давление масла,

• воздух в помещении и температуру жидкостей,

• заряд батареи.

Также контролируются электрические параметры: частота, мощность и напряжение.

Фиксация результатов и переключение обратно

После испытаний мы в обратной последовательности отключаем нагрузочные модули, выводим ДИБП из тестового режима и переводим ключ на панели управления в положение "НАГРУЗКА ЗАЩИЩЕНА". Сценарий переключения отработан, никакие перебои в электроснабжении помешать работе дата-центра не должны.

По результатам испытаний в протоколах указываем все полученные параметры. ДИБП переходит на следующий круг проведения ТО по годовому графику.

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

Сегодня вместе с @kvolodin мы расскажем, почему бесконечное увеличение ресурсов ВМ может вредить пользователям и как спланировать рост производительности очевидными, но действенными способами. Статья полезна тем, кто переехал или планирует переезд в облако и еще знакомится с нюансами облачной среды.

Очевидные причины: ограничения железа и бэкапов

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

Но так было не всегда. В старых версиях vCloud Director мы не могли жестко ограничить некоторые параметры и прописывали лимиты только в договоре. К сожалению, иногда информация из контракта даже не попадала к инженерам клиента, и они могли почувствовать последствия на своей шкуре.

Много лет назад мы предоставили клиенту квоту в 20 ТБ и предупредили про ограничение на диск в 16 ТБ. Резервное копирование данных делали с помощью Veeam Backup&Replication. Когда клиент вышел за пределы диска в 16 ТБ, все задачи на создание бэкапов просто зависли. Veeam не успевал забэкапить большую ВМ и на всякий случай оставлял неполный снэпшот, а затем создавал новый. Дерево снэпшотов стало расти слишком быстро, общая производительность диска тоже упала. Пришлось полночи заново создавать дерево снэпшотов, а затем переносить данные на диски поменьше.

В те времена от подобных инцидентов нас защищал мониторинг. Мы сразу видели непорядок на дашбордах и обращали внимание клиента на проблему. Трудность была в том, что в случае IaaS сами виртуалки оставались ответственностью клиента. Инженеру клиента нужно было самому пересоздавать ВМ, иногда с большим трудом.

Клиенту выделили квоту в 40 ТБ на СХД, а для диска ВМ прописали ограничение в 20 ТБ. Администратор клиента создал ВМ в 30 ТБ и разметил все дисковое пространство одним диском. Техподдержка обнаружила проблему, сообщила клиенту, что нужно пересоздать ВМ с дисками меньшего размера, но администраторы долго не выходили на связь.

В это время данные начали записываться на созданный диск большими темпами. Пока на СХД было свободное место, мы увеличивали размер дата-стора и ждали ответа от клиента. Но если бы расширять дата-стор дальше было невозможно, клиенту пришлось бы рисковать данными. Нужно было бы создать новый диск и перегнать данные на него. Миграция такой большой ВМ могла потребовать несколько дней, и оставалась вероятность неудачного переезда.

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

Но даже если физический лимит не превышен, могут возникнуть другие трудности.

Неочевидная работа гипервизора

Если виртуальная машина в облаке начинает тормозить и захлебываться, клиент чаще всего ищет причину в нехватке ресурсов. Увеличение виртуальной машины кажется логичным и быстрым ходом. Но в некоторых случаях расширение только ухудшает скорость работы.

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

Клиенту облака по умолчанию доступна только информация из диспетчера задач и монитора ресурсов. Бывает и так, что на ОС клиент видит загрузкучасти ядер на 100%. В это же время мы на гипервизоре видим, что часть ядер не используется, потому что приложение не рассчитано на многопоточность. В таких ситуациях парадоксальным образом помогает именно уменьшение ресурсов до необходимого и достаточного уровня. После этого гипервизор лучше распределяет небольшие ВМ в очередях.

Некорректный сайзинг приложения в облаке

К сожалению, переезд приложения с физических хостов не всегда возможен в лоб. Даже если все работало на физических 24 процессорах, столько же процессоров в облаке не всегда решают проблему.

Один из клиентов перед переездом на новое железо решил временно разместить в облаке виртуальную АТС. Мы заглянули в документацию вендора и обнаружили явную несовместимость с vCloud Director. Производители АТС изначально не гарантировали стабильную работу своего приложения в облачной среде. Тем не менее, нашим инженерам удалось настроить работу софта с помощью нескольких хитростей. Клиент спокойно работал в облаке, пока не дождался поставки собственного железа. Но если быон захотел внести изменения в настройки, возникли бы трудности.

У крупных производителей софта несовместимость с облаком сразу прописана в документах. Менее очевидно дело обстоит с самописным ПО.

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

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

Например, бывают ситуации, когда пользователь привык к быстрой работе на ноутбуке с высокочастотными процессорами, а в облаке сталкивается с низкой скоростью. Характеристики Enterprise-железа в дата-центре рассчитаны на долгосрочную работу в режиме 24/7 и не допускают пограничных состояний. Если такой пользователь разгонял процессоры на своем ноутбуке до опасного максимума, то в облаке он не сможет добиться тех же скоростей от похожего процессора.

Случается и так, что приложение рассчитано на высоконагруженную базу, но размещается в облаке на SATA-дисках. Клиент видит загрузку процессоров и увеличивает ресурс CPU, не подозревая проблемы именно с дисками.

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

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

Подозрительная активность на ВМ

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

Неправильная настройка облачного межсетевого экрана у новых клиентов встречается не так уж редко. Иногда администраторы разрешают на граничном маршрутизаторе всем и все, а потом забывают об этом. Если мошенник обнаруживает уязвимость и завладевает машиной, то он забирает все ресурсы сразу, и докидывание процессоров не решает проблему.

Откуда берутся лимиты на ресурсы в облаке

Ограничения на диск

1. Есть технические ограничения СХД. Яркий пример: блочный том многих моделей NetApp не может быть более 16 ТБ.

2. Мы как провайдер провели тесты производительности СХД и рассчитали оптимальный размер дата-стора.

3. Инфраструктура резервного копирования лучше справляется с бэкапом нескольких мелких объектов, чем одного большого.

Ограничения на CPU и память

1. Ограничен размер физического хоста, на котором располагаются ВМ клиентов.

   При размере хоста 144 vCPU и 2 TБ памяти ВМ большего размера не получится создать при всем желании. (Cпасибо, кэп!)

2. Для оптимального обращения к памяти мы учитываем особенности работы мультипроцессорных систем. Мы уже рассказывали об этом в статье про первую виртуальную машину.

   У клиента может быть сервис, который сам эффективно распределяет ресурсы памяти, тогда проблем не возникнет. В остальных же случаях нужно настраивать лимиты.

3. С помощью некоторых лимитов мы можем управлять виртуальной платформой и предоставлять предсказуемый сервис с соблюдением SLA.

Ограничения на IOPS

В облаке также встречаются клиенты, у которых намного выше среднего параметры IOPS: количество операций ввода/вывода. Чаще всего это происходит в трех случаях:

1. Клиент решил протестировать выделенные мощности на больших нагрузках.

2. У клиента наблюдается аномальная нагрузка, например, из-за некорректной работы самописного софта или вирусов.

3. Клиент установил высокопроизводительное приложение.

На любой из этих случаев мы задаем ограничения потребляемых дисковых мощностей, опираясь на результаты нагрузочного тестирования СХД. Сейчас можем ограничить каждый диск фиксированным значением IOPS или исходить из IOPS на ГБ.

Как новому клиенту вписаться в лимиты и обеспечить производительность

1. При планировании переезда в облако ознакомиться с документацией на ПО. Некоторые производители софта сразу указывают, что их приложение не работает в облачной среде.

2. До переезда протестировать работу приложения в облачной инфраструктуре. Большинство провайдеров позволяют клиентам брать пробный период и запускать синтетические тесты.

3. Не стесняться обращаться в техподдержку. Инженеры могут оценить производительность со стороны гипервизора и дать рекомендации.

4. Расти маленькими шагами: увеличить диски намного проще, чем резко их уменьшить. Увеличивать процессоры тоже лучше постепенно, начинать с одного ядра.

5. Расти не вертикально, а горизонтально. Например, не добавлять 8 процессоров на одну ВМ, а создать 4 ВМ по 2 процессора на каждой. Вдобавок это уменьшит площадь отказа.

6. Ставить виртуальные машины на внутренний мониторинг. В этом случае клиент может выбрать наиболее важные показатели работы ВМ и быстро получать оповещения об их состоянии. Это позволит вычислять неочевидные проблемы, которые не заметны на общем мониторинге.

Разберем доступные на рынке решения для организации хранения документов и расскажем о возможностях сервисов на базе open-source решения Nextcloud. Вебинар будет интересен тем, кто ищет безопасное для компании и удобное для сотрудников решение для хранения корпоративных файлов и совместной работы над документами.

В программе:

• Удобно, но небезопасно, и наоборот: сетевой диск, публичные облачные хранилища и диски.

• Open-source решение Nextcloud.

• Разворачиваем Nextcloud самостоятельно.

• Сервис DataLine на базе Nextcloud: возможности, которые сложно получить в варианте on-premise.

• Не просто хранилище: платформа для совместной работы на базе Nextcloud.

• Кейсы и демонстрация основных модулей решения Nextcloud.

Начало вебинара в 11.00. Продолжительность 1 час. Участие бесплатное, но нужно зарегистрироваться.