На чём стоит экономить в облаке



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

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

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

    Рассмотрим ситуации, когда выгоднее фиксированные тарифы, а когда — pay-as-you-go-концепция (PAYG). Плюс рассмотрим, что можно выключить лишнего, и где чаще всего впустую расходуются ресурсы. Пройдёмся по основным видам ресурсов: CPU, RAM, виртуальным дискам, сети и бэкапам.

    Собираем информацию


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

    Чем мониторить


    На выбор — огромное количество систем сбора и визуализации информации, но я хотел бы обратить внимание на ключевые:

    • Zabbix — старый добрый швейцарский нож в системах мониторинга. Графики бедные и страшноватые, на мой вкус.
    • Kibana — часть стека ELK. Подойдёт не для любого типа данных, но часто позволяет делать очень сложные визуализации, включая картографические.
    • Grafana — очень гибкий инструмент, который позволяет интуитивно понятно сформировать красивые информационные панели. Мне кажется, что он наиболее разнообразен в плане различных типов графиков.
    • Собственные панели вендора облака. Про них часто забывают, но часто они могут предоставить вам уникальную низкоуровневую картину потребления ресурсов вашими машинами.

    Как оптимизировать тариф




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


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


    Можно взять два ядра вместо четырёх без потери производительности.

    Если больше 10 % времени ВМ простаивает, то нужно попробовать пересчитать на PAYG-модель. Только при этом машина должна быть выключена, когда не используется. Например, раз в сутки включается нода, компилирует проект и выключается обратно.


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

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

    Аналогично поступаем с различными тестовыми и экспериментальными машинами. Чаще всего их выгоднее оплачивать по факту потреблённых ресурсов, а не с фиксированным тарифом. Если нашли машину, которая потребляет от силы 1 %, то выключаете и переводите на PAYG.

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

    Некоторые клиенты используют API vCloud Director для того, чтобы включать и выключать ВМ по расписанию, чтобы ещё больше экономить на потребляемых ресурсах. Очень хорошим подходом будет использование оркестрации для управления облаком, включения и выключения нод при изменении нагрузки.

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

    Оперативная память


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

    Используя тарифный план PAYG, есть смысл конфигурировать ВМ так, чтобы она оптимально утилизировала выделенные ей ресурсы, имея запас по производительности для пиковых нагрузок. При этом резерв не должен быть x4 или x10 от среднего потребления вашего приложения: это просто нерационально дорого. Конечно, лимиты всегда определяются индивидуально под каждую задачу, но чаще всего стоит стремиться, чтобы запас не превышал 25 %.

    Виртуальные диски


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


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

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


    Правильный вариант. Каждому типу данных — своя скорость диска.

    Теперь надо решить вопрос, на каком диске размещать саму ВМ. У платформы vСloud Director есть особенность: она резервирует на диске место под оперативную память ВМ в момент её запуска. При этом вы заранее выбираете тип хранилища. Сама ОС не слишком критична к IOPS, большинство компонентов уже загружено в RAM, и диск не нагружают. Тем не менее, если вы сэкономите и разместитесь на медленном диске, то получите долгий ребут и пробуждение из спящего режима из-за невысокой скорости чтения swap и конфигурационных файлов.

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

    Диски под БД


    Очень часто диски под БД берут «на вырост». Это типичная ошибка для облачных систем. Если вам нужно 60 ГБ, то и берите сколько нужно с небольшим запасом. Условные 200 ГБ быстрого диска будут съедать финансы и простаивать.

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

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

    Не забывайте сбрасывать логи на отдельное медленное хранилище, чтобы не тратить драгоценное место на быстром диске с БД. Они имеют тенденцию к очень быстрому поглощению свободного места, особенно в случае MS SQL. Также крайне желательно исключать логи из образов регулярных бэкапов.

    Сеть


    С Сетью поступаем аналогично: не гонимся за круглыми цифрами 1–10–100 мегабит, а сразу берем 45 мегабит, если у вас средняя загруженность канала — в районе 40. Берите ресурсов ровно столько, сколько необходимо.

    Уточняйте возможность управления этим параметром с вашей стороны. У нас клиент сам не может его менять, то есть pay-as-you-go не работает, а смена ширины канала возможна раз в месяц. Тем не менее есть облака, где этот параметр настраивается в реальном времени.



    В облаке на базе vCloud Director есть замечательная штука NSX Edge — виртуальный маршрутизатор. Он бесплатный и может заменить собой более дорогие решения, которые требуют дополнительных мощностей и покупки лицензий. В нём есть балансировщик, который в простых ситуациях может заменить такие решения, как Haproxy и виртуальные appliance Citrix NetScaler. Не нужно покупать лицензии для коммерческих продуктов, и за ресурсы NSX Edge вы не платите. Он есть по умолчанию.

    В случае необходимости NSX Edge можно масштабировать. Умеет работать как VPN трёх видов:

    1. IPsec VPN-тоннель Site-to-Site — для организации защищённого канала между облаком и офисом или другими облаками, где размещены ресурсы клиента.
    2. SSL VPN — для доступа клиента с мобильных устройств и персональных компов, при этом можно не использовать более дорогие решения вроде Checkpoint Cisco и Fortigate.
    3. L2VPN — так же, как IPSEC Site-to-Site, но соединяет на уровне L2.

    CPU


    Здесь можно обеспечить экономию несколькими вариантами.

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

    Вовсе не обязательно использовать одинаковые процессоры на всех своих машинах. Более того, комбинация из инстансов с частотой ядра 2,4 ГГц и, например, 3,1 ГГц может оказаться более экономически привлекательна.

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

    Обратите внимание: уменьшать оперативную память и CPU облако даст только при выключенной ВМ, иначе система могла бы запаниковать. Расширять же ресурсы можно на работающей машине, если ОС поддерживает и включён режим горячего добавления.

    Резервное копирование


    Клиент при использовании услуги Резервного копирования платит за две вещи: за количество ВМ и за объём данных на дисковом пространстве. Опять начинаем с анализа.

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

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

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

    Если хранить резервные копии нужно долго, то стоит рассмотреть вариант холодных хранилищ. Обычно это ленточные библиотеки с медленным восстановлением. Вариант идеален для архивных данных. Хороший пример — Amazon Glacier, где начало развёртывания из старого бэкапа начинается через три–пять часов после запроса. Условно ваши данные нужно физически найти, достать со склада и считать. Зато и стоимость за гигабайт хранения становится намного выгоднее.

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

    Резюме


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

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

    Не забывайте также про возможность гибридных схем. Использование облачных ресурсов для сглаживания нерегулярных пиковых нагрузок практически идеально укладывается в концепцию pay-as-you-go.

    Comments 13

      0
      Спасибо за статью!
        0
        Спасибо! Полезная информация, в закладки.
        • UFO just landed and posted this here
            +1

            С vmware vcloud director память самое дорогое, такова лицензия :)

            +1
            Диски могут быть тонкими и дедуплицироваться, ядра можно делить между несколькими ВМ, а память если используется, то практически монопольно
              0
              Если у вас резервируется память, то откуда взялся VSWP из статьи?
              У платформы vСloud Director есть особенность: она резервирует на диске место под оперативную память ВМ в момент её запуска.
                0
                Мы не говорим про конкретного облачного провайдера, в каких-то случаях резервирование память на 100% оправдано и своп не создаётся. Но часто операторы пытаются экономить, но это не значит, что ВМ будет свопится туда. Просто не все клиенты оптимально используют память, и очень много выделено для Вм, но фактически не используется никогда.

                Также речь не только про своп, а и про дамп памяти ВМ, при её приостановке, например.
                  0
                  Оказывается платформа тут ни при чем, просто некоторые провайдеры так экономят на лицензиях, чтобы побольше заработать.
                    +2
                    Начнём с того, что статья «немножко устарела». С такими вещами, как vCD (да и вообще продукты VMware) зачастую нет смысла читать статьи такого возраста. Блин, даже дисковые и cpu шедулеры меняются.
                    А вот по существу: создание .vswp это поведение vSphere, а не vCD. Логично, что при отсутствии резервирования памяти, размер этого файла будет равен размеру памяти VM. Ключевой момент в том, что это своп уровня гипервизора, а не уровня гостя, т.е. vswp read/write происходит в том случае, когда у гипервизора не достаточно RAM для предоставления VM (если со стороны VM есть «demand»). Т.е. .vswp не будет и не должен работать, если имеет место мисконфигурация VM и её дали памяти сильно меньше, чем нужно гостю. Если сделать полное резервирование памяти, то файл .vswp на датасторе всё равно будет создан, но он будет минимального размера.
                    Теперь о vCD: при создании машин от команды vCD (а не напрямую в vSphere) резервирование памяти для VM не предусмотрено. Есть резервирование на уровне Resource Pool, который фактически является vCD Organization VDC. Пример: вы купили 1 TB памяти с 20% резервированием с моделью Allocation Pool. Это значит, вы можете создать машины с суммарной сконфигурированной RAM 1 TB. Создаёте машину с 64 GB RAM, и на ресурс пул приземляется Reservation 20% от 64, т.е. 12800 (а не сразу 200 GB, что есть 20% от 1TB). А вот на уровень VM резервирование не прилетает. Это нормальное поведение vCD (правда, я давно не интересовался моделью reservation и совсем не интересовался flex).
                    И более того, даже если вы заразерервируете память на уровне VM, vCD на это плевать и он зачтёт размер памяти в requested storage. Емнип, у vCD в схеме базы даже нет полей с данными резервирования compute ресурсов на уровне именно VM. Т.е. при синке inventory он этих данных от vCenter'а не получает, да ему и не зачем (типа логика «облачности» тогда страдает, ну вот эта вот философия, ага). Пример: создали вы VM 40GB диск, 40 GB RAM. Вам админ vSphere зарезервировал всю память на этой VM (за красивые глаза), включаете. Но Requested Storage на Storage Policy всё равно будет 80 GB. Это точно справедливо для vCD 9.1 и 9.5 (уверен, что для 9.7 и 10 в этом плане ничего не поменялось).
              0

              Разве своп как раз на самых быстрых дисках не должен быть в общем случае, если планово допускается активное свопование? Или дешевле памяти добрать?

                0
                Если у вас ВМ свопится, то это плохой провайдер. Тут лучше что-то другое придумать. Но если свопится, то быстро.
                  0
                  Кажется мы о разных свопах. Я о свопе в самой виртуалке.
                    +4
                    Я тут выше немножко расписал. Но вот два примера:
                    1. Вы дали машине 8GB RAM, запустили, внутри гостя (например, венда) создается swap-файл, т.е. внутри VMDK, прям на файловой системе (скажем, NTFS). И вот приложение в вашем госте начинает требовать больше, чем вы дали машине. У гипервизора свободной памяти в достатке, но VM страдает просто из-за мисконфигурации. А вот начинается активная запись в swap и чтение из него (тот, который внутри гостя на NTFS лежит). Машине плохо, но гипервизор в этом не виноват;
                    2. Вы дали машине 8GB RAM, запустили. Demand у неё 6GB, и ей этих 8 хватает. Внезапно у гипервизора перестаёт хватать памяти для неё (из-за noisy neighbour'а, например) и он может выделить только 2, а вот нужные 6 не может. И вот если не спасают всякие танцы TPS (который если современный, с солью, и его не конфигурировали, то сильно он не сдедуплицирует), не помог balooning, то в последнюю очередь начинает работать swap на уровне гипервизора и он пишет туда данные вытесненных страниц памяти. Это когда уже у ESXi не хватает памяти для VM. Этот файл .vswp создается на датасторе vSphere в каталоге VM, а не внутри гостя (не в вашей венде). Это крайний случай механизмов экономии памяти, он работает последним и если он запустился, то это плохо. Более того, даже приходится делать ручной unswap (или ребут хехе), но это уже другая история. В общем, этот .vswp файл по размеру соответствует размеру памяти VM (сконфигурированной памяти), что логично. Но при достаточном количестве ресурсов он не активен, т.е. запись в этот файл не ведется, как нет и чтения из него.
                    Так вот, если у гипервизоров массово не хватает памяти для VM, и .vswp файлы активно пишутся и читаются, то вас вряд ли спасёт даже современный all-flash массив.

                    Ну вот это вот на пальцах так, кратко.

              Only users with full accounts can post comments. Log in, please.