Грабли при переездах на виртуальную платформу с физического железа



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

    А дальше мы, как платформа, начинаем это принимать и бить себя рукой в лицо, потому что клиенты начинают жаловаться, что что-то в облаке не так работает. Проблема же — минимум в 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.
    Техносерв
    79,00
    Компания
    Поделиться публикацией

    Комментарии 17

      +4
      малый бизнес: компетенций не хватает, техническое образование оставляет желать лучшего

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

        +1
        > Проблема в том, что адаптер PVSCSI не поддерживается Vmware для ОС Debian.
        А на кой черт ваша вмварь нужна, если они поленились предоставить самому популярному серверному дистрибутиву Linux драйвера, хотя бы через свой репозиторий?
          0
          Мы говорим о максимальной производительности VM, а не о том, что данная ОС не работает в VMWare в принципе.
            0
            Мы говорим о том, что вмварь не собрала пакет для Debian с драйверами для своих виртуальных устройств.
            Не говоря уже о том, что открытых драйверов нет, поэтому сами дебианщики собрать этот пакет не могут.

            Ну а сообщать о том, что вмваре лень поддерживать потенциальные 50%+ линуксов на серверах (debian, ubuntu), пытаясь скрыть это обтекаемыми фразами — прямо таки в лицо веет философией продаванов.
              0
              Не буду комментировать политику продаж компании VMware. Я написал о нашем опыте, надеясь, что он кому-то окажется полезным. Уверен, что за виртуализацией будущее, но не все сервисы будут виртуализированы.
                +1

                Плохой у вас опыт, если не научились пользоваться HCL и не знаете про интеграцию драйверов в ядро.

                  +2
                  Не буду комментировать политику продаж компании VMware.

                  Но вы, со своей стороны, можете иметь не только VMware.

                    0
                    Но вы, со своей стороны, можете иметь не только VMware.

                    В столь сложных вещах лучше специализироваться на одном ПО, а не прыгать с одного на другое.
            +1
            Проблема в том, что адаптер PVSCSI не поддерживается Vmware для ОС Debian. Vmware не поддерживает эту ОС.

            А это про что?
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Ссылку специально выбрал на самую старую версию в HCL, Debian 8 и 9 там тоже есть.
                А драйверы синтетических устройств давно интегрированы в ядро и надо лишь доставить open-vm-tools из официального репозитория.
              +1
              не всем катит RHEL, кому то только Debian, а раз VMware не поддерживает ее то зачем такое облако?
              0
              Ещё один клиент всё не мог к нам переехать, потому что его старый облачный провайдер не отпускал. Снижал скорость канала.


              Шта?
              Казалось бы, облачные провайдеры априори немелкие фирмы, где плюс-минус один клиент — это не заметно. А иначе не будет никакой эластичности облака.
                0
                Облачный провайдер управляет ресурсами. И для него нет никакой сложности в том, чтобы выборочно ограничить одного из клиентов в предоставлении какой-либо услуги или ресурсах. Хотя вы правы — это очень странное решение. 
                  0
                  И для него нет никакой сложности в том, чтобы выборочно ограничить одного из клиентов в предоставлении какой-либо услуги или ресурсах


                  Это понятно, что техническая возможность есть. Речь не об этом.

                  Речь о том, что «эластичность», присущая облаку, начинает проявляться на огромных объемах серверов. И это не 10 серверов, когда ваш клиент покидает 5 серверов, что составляет 50%, и вам это критично.
                0
                жирная ВМ на 16 Гб
                Хм… по мне так ниже средней, жирная это 512 Гб и выше

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

                Самое читаемое