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

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

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

Расскажу чуть больше про типичные ситуации.

Руты

Совсем ликбез, но мы часто видим рут-доступ по SSH на Linux-машинах и жизнь без апдейтов на Win-машинах. Почему это важно? Потому что есть вирусы типа «Пети». Конечно, клиенты часто говорят, что они лично никому не нужны и никто их атаковать не будет. Но ботнетам плевать — они ломятся на все устройства в сети и перебирают уязвимости и пароли.

Хорошая практика — делать аутентификацию по ключам, а не паролям и закрывать «лишние» порты. В идеале — использовать таблицы доступа. Переезд — хороший повод настроить, актуализировать ACL-листы, выставить наружу только те сервисы, которые реально нужны из большого Интернета.

Звучит довольно просто, но многие горят уже на этом. Потому что у многих в ИТ в обычном бизнесе (вроде производства мороженого или автосервиса) как-то много лет назад кто-то настроил, и они так и живут, ничего не трогают. Потом поверх этого нарастают пласты новых фич, и в результате в археологии начинают копаться, только когда что-то не работает. Не превентивно.

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

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

Пример стандартной настройки ACL клиентами:

Параллельность

У клиентов часто плохая архитектура построения сервисов: пользуются виртуализацией, как физикой. Есть одна жирная виртуальная машина, и если с ней факап, то бизнес встаёт раком. Нет load-балансеров, нет распараллеливания нагрузки на сервера, нет репликации. Вся прелесть облаков в том, что ВМ может быть много. Вот так не надо:



А вот так надо:



Ещё часто на эти грабли наступают те, у кого полстойки было в офисе. Стоял сервак — жирная ВМ на 16 Гб. Масштабирование у неё — допокупка памяти и диска. А надо ставить избыточные машины и балансер.

Легаси по железу

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

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

Достаточно разобраться, как их настраивать, и не ставить свои внутри облака. Почитать инструкцию по листам доступа и разделения на подсети и реализовать это средствами облака, а не поднимать отдельные ВМ.

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

Ресурсы впритык

Довольно часто встречается жесточайшая экономия на виртуальных машинах. База 28 Гб, а виртуальной машине выдают 4 Гб памяти. При больших запросах начинаются вылеты с экзепшнами или просто всё тормозит. Давайте увеличим память? Нет, надо попробовать оптимизировать! А пока релизится, пусть захлёбывается.

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

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

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

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

Совместимость

Миграция ОС: многие стараются пользоваться тем, что уже имеют. И не обращают внимания на совместимость своих ОС с VMware. Допустим, есть высоконагруженные базы данных Дебиан. Проблема в том, что адаптер PVSCSI не поддерживается Vmware для ОС Debian. Vmware не поддерживает эту ОС. UPD: точнее, не работает с достаточно высокой производительностью. И мы видели случаи, когда по базе данных разница в 3-4 раза по производительности по дискам отличается от такой же базы на другой ОС, к примеру, CentOS. Мы не рекомендуем использовать ПО, у которого нет отметки «поддерживается Vmware».

Или в LVM, собранном на SSD дисках, добавляются еще диски 7K по ошибке, а далее клиент пытается нас обвинить, что скорость SSD дисков не соответствует заявленной.

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

Мы можем посоветовать в сложных случаях перейти на CentOS или Red Hat, но вообще-то об этом лучше думать до планирования переезда.

Более редкие случаи

Клиент готовится к миграции в облако. Системный администратор сделал на своих серверах RAID-5 в состоянии degraded, «задел» перед увольнением. Потом покинул компанию. Прошло некоторое время, началась подготовка к переезду. В процессе подготовки из RAID вылетел один диск. Там база 1С. Восстановить сами не смогли: что-то с физикой диска. Резервное копирование не было настроено. Без комментариев, что называется.

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

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

Получили от клиента претензию, клиент купил VDC и добавил VM два интерфейса, один внутренней сети, другой внешней, и, по сути, запутался в двух интерфейсах. Чтобы организовать маршрутизацию, использовал сетевые мосты и решил было установить гипервизор PROXMOX 5. Помогли всё оперативно разрулить — особенность была в том, что с подобной нашей архитектурой заказчики до этого не работали. Хорошо, они вовремя обратились до построения вот этой конструкции с гипервизором в гипервизоре.

У одного клиента удалённые рабочие места тормозили. Решение простое: оказалось, у него на сотню машин в офис приходит 10 Мбит/с.

Ещё один клиент всё не мог к нам переехать, потому что его старый облачный провайдер не отпускал. Снижал скорость канала. Это только усугубляло ситуацию в их отношениях. У нас можно по быстрому каналу выгрузить все ВМ и выложить их на закрытый обменник. День на выгрузку: обед — вечер, на следующий день он уехал. Всё. Вот так оно и должно быть.

Банально люди путают скорость: один товарищ Мегабайт от Мегабита начал отличать только после разговора с нами.

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

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

Текст подготовлен Дмитрием Максимовым, руководителем службы эксплуатации Техносерв Cloud.