Доброго времени суток.
При работе с Bitrix‑инфраструктурой в определенный момент вы можете столкнуться с проблемой увеличения времени открытия различных страниц на вашей площадке (сайте), медленной отдачей заказов или замедленной выгрузкой новых товаров на площадку. Чаше всего это связанно с ростом проекта и повышением потока клиентов, из‑за чего сервера могут не справляться. И здесь мы сталкиваемся с необходимостью расширения Bitrix‑инфраструктуры — спасти ситуацию может переезд на новые сервера, а вместе с тем и улучшение пропускной способности площадки.
Хорошо. Представим, что выбрали физический сервер. В этом случае, если проект будет расти на 20–30% в год, то через непродолжительное время понадобиться опять переезжать (тем более что чаще всего выбор сервера заканчивается на первой ссылке в поисковике и выборе сервера с характеристиками выше текущего). Такой вариант конечно же самый простой и стабильный, потому что от вас не требуется много времени на анализ и построение инфраструктуры: арендовал сервер, переехал и продолжаешь работать.
Однако, в долгосрочной перспективе вы потеряете больше часов и денег, чем один раз переедете на облачный сервер. Поэтому нашим клиентам в силу очевидных преимуществ мы рекомендуем отказ от физических серверов в пользу облачных решений, и в этой статье мы это подробно продемонстрируем. Материал будет полезен тем, кто хочет переехать на новый сервер, но не может определиться между физическим и облачным решением. Также разберем все возможные нюансы при переезде.
Статья будет состоять из несколько пунктов:
Что такое облачный сервер(облако)
Кому подходит облако
Почему облако - это будущее?
Плюсы облака по сравнению с физическими серверами
Managed service: для кого применимо?
Подбор облачного решения для Bitrix-проектов
Пример подбора, настройки в внедрения такого решения: наши практики
Самое популярное заблуждение об облаке для Bitrix-проектов
Выводы
Что такое облачный сервер (облако)
Под «облаками», как правило, подразумеваются сервера, которые развернуты с использованием аппаратной виртуализации в вашем любимом дата‑центре. Аппаратная виртуализация, в основном, достигается за счет различного специализированного программного обеспечения, например: KVM, Hyper‑V, VirtIO и т. д. Облачный сервер — это удаленный сервер или совокупность серверов, ресурсы которых предоставляются пользователям через интернет. Пользователь сам определяет требуемый набор вычислительных мощностей, а затем оплачивает их аренду. В любой момент этот набор можно расширить или сократить без простоев и перебоев в работе. Отличный мануал по этой теме представлен в Yandex.Cloud [тут].
Главное отличие облака от физического сервера состоит в том, что вы можете самостоятельно динамически изменять характеристики вашего сервера как в большую сторону, так и в меньшую — в зависимости от ваших потребностей. В то время как характеристики физического сервера статичны и, как правило, не подлежат изменению, если речь идет об аренде сервера в дата‑центре.
Кому подходит Облако
Облако подойдет для нескольких видов Bitrix-проектов:
Интернет магазин - самый подходящий кандидат для переезда в облако.
Новостной портал - за счет растущей аудитории здесь нам пригодится динамическое расширение
Корпоративный портал Битрикс24.
Почему Облако — это будущее?
Если вы переезжаете в облако, то вы забываете что такое переезд с сервера на сервер. За счет возможности снятия снапшотов и развертывания из них новых нод инфраструктура вашего проекта может быть легко отмасштабирована как по горизонтали, так и по вертикали. Если у вас динамично развивающийся проект, то это может оказаться для вас актуальным.
Понадобились большие вычислительные ресурсы? Вы можете легко добавить необходимое их количество в личном кабинете в панели управления вашим облаком.
Необходимы диски больших размеров? Вы также можете добавить их в личном кабинете, либо создать бакет для хранения большого количества данных.
Плюсы Облака по сравнению с физическими серверами
Это очень актуально для интернет‑магазинов. Почему? Потому что на деятельность интернет‑магазина может влиять (и часто так и происходит) такой фактор как сезонность.
Пример 1: У вас магазин экипировки для зимних видов спорта. Летом посещаемость крайне мала, а зимой — наоборот. Соответственно иметь в запасе сервер 96 CPU 256 RAM 365 дней в году нет необходимости. Весной вы снижаете характеристики вашего сервера в два раза, и за счет этого экономите. Осенью вы снова наращиваете свои мощности и подготавливаете инфраструктуру к наплыву клиентов.
Пример 2: У вас интернет‑магазин по продаже бытовой техники. Не за горами «Чёрная пятница». Для того, чтобы магазин не «лежал» из‑за наплыва посетителей вы добавляете вычислительных мощностей вашему проекту в несколько кликов. После распродажи можно вернуть характеристики обратно. То же самое касается предновогоднего ажиотажа. В итоге за счёт динамического изменения инфраструктуры мы выжимаем из нашего проекта максимум производительности, при этом экономим средства в холодный сезон.
Также из плюсов хотелось бы выделить:
Оплата за серверы только на момент использования.
Например, сайт необходим только в летнее время, в зимнее время нет необходимости его держать. Вы выключаете сервер и не платите за него. Здесь хотелось бы уточнить, что вы не платите за ресурсы RAM и CPU. За задействованные диски оплата будет списываться.
Оплата происходит по часовому тарифу.
На физических серверах списание производится авансом за месяц. На облачных — оплата только за рабочие часы.
Например, вы арендуете dev‑сервер на неделю и платите только за неделю использования.
Снятие снапшотов.
Разворачивайте свои dev‑серверы в пару кликов. Снимаете снапшот с основного сервера и на основе данного снапшота разворачивается копию. Это занимает всего минут 10 без необходимости заново настраивать программное обеспечение и сервисы.
Отсутствие работ по отслеживанию состояния физического сервера.
Для облачного сервера не актуальна проблема поломки комплектующих. В центрах хранения и обработки данных (ЦОД), где разворачивается виртуальная инфраструктура, запланировано многоуровневое резервирование вычислительных ресурсов. Сбои могут быть, но они не несут фатальных проблем, характерных для физических серверов. Неполадки устраняются на порядок быстрее, чем при эксплуатации физического сервера благодаря резервированию и специализированному персоналу. Уже нет необходимости следить за RAID‑массивом. Нет необходимости следить за состоянием вашей оперативной памяти и температурой на процессоре. Нет необходимости следить за качеством ваших дисков и сколько осталось циклов записи/чтения. В облачных решениях все эти проблемы находятся в зоне ответственности дата‑центра. При этом аварийно‑восстановительные работы проводятся без простоя (или почти без простоя) на стороне ЦОД.
Виртуальный сервер позволяет не думать о технической поддержке сервера.
На физическом сервере никто не застрахован от всевозможных неполадок, которые могут привести к простою площадки.
Пример: Вышла из строя материнская плата на сервере, вследствие чего операционная система начала давать сбой. Решением данной проблемы будет полная переустановка операционной системы. Хоть проблема и заключается только в операционной системе, не стоит забывать о том, что на ней была произведена настройка огромного списка сервисов, перенастройка которых с самого начала займет много времени. Ситуация крайне неприятна, особенно в тех случаях, когда из оставшихся копий остались только восстановленные данные, но настройки были полностью утеряны. При использовании виртуальных машин данной проблемы практически не наблюдается. В случае падения, вам понадобиться только snapshot‑системы, который развернется всего за пару минут.
Невероятно высокая скорость развертывания.
Этот фактор является одним из главных достоинств виртуальных машин, и убедиться в этом можно, представив себе следующую ситуацию.
Пример: Допустим, возникла необходимость открыть еще один филиал организации. Все внимание сосредоточено на информационной инфраструктуре: все сервисы, функционирующие в основном офисе, должны быть развернуты как можно быстрее, и виртуальная система позволяет сделать это за несколько минут. Вся процедура развертывания от начала и до конца сводится к развертыванию snapshot на новой виртуальной машине. От пользователя или управляющего лица не требуется никаких лишних настроек и никаких однотипных действий. Всё работает так, как и настраивалось. Также стоит добавить, что отпадает потребность в квалифицированном специалисте. Таким образом, выгода еще увеличивается.
Managed service: для кого применимо?
На текущий момент мы наблюдаем тренд на микросервисную архитектуру — то есть разделение всех сервисов на разные серверы, и выделение для каждого сервиса своего сервера.
Пример:
Отдельный сервер Redis
Отдельный сервер MySQL
Отдельный сервер PHP
Почему это необходимо?
За счет возможности вертикального и горизонтального масштабирования мы сможем выделять больше ресурсов именно для того сервиса, который в этом нуждается. Также это улучшает траблшутинг нашего проекта, и каждый сервис не зависит от другого. В случае падения MySQL из‑за проблемы в ядре операционной системы, вам необходимо будет только восстановить MySQL, другие сервисы не будут задеты и будут работать без ошибок. По этой причине в облаках появляются все больше и больше так называемых Managed service, которые реализованы как готовое решение на стороне дата‑центра.
Managed service — это сервис, который предоставляет дата‑центр для различных баз данных, сервисов автоматизации и сервисов балансировки. Это готовое решение, которое реализовано силами дата‑центра и готово к использованию.
Пример: Имеется MySQL Managed service. Вам нет необходимости разворачивать MySQL и настраивать его. Вы арендуете этот сервис после чего вам выдают доступ. Все, что вам необходимо, — это залить dump вашей базы данных и приступить к работе. Следить за состоянием MySQL уже нет необходимости. За отказоустойчивостью и репликацией следит дата‑центр.
Самые популярные сервисы для Bitrix‑проектов:
Managed service баз данных mysql или MongoDB.
Managed service Redis.
Managed service балансировщик.
Managed service k8s.
Однозначно рекомендуем использовать Managed service для MySQL и MongoDB, так как это дает возможность повысить отказоустойчивость вашей базы данных практически на 99% и использовать несколько нод на запись или чтение, тем самым увеличивая пропускную способность вашего проекта.
Также очень хорош Managed service Redis и Managed service балансировщика.
На Bitrix‑проектах это решение является рекомендованным. За счет балансировщика вы сможете настроить резервный сервер и направлять на него трафик, в случае падения основного сервера, а за счет Managed service MySQL/Redis вы сможете не беспокоится на счет падения двух этих сервисов и за консистентность данных при запросах с разных серверов вашего кластера.
Подбор облачного решения для Bitrix-проектов.
На текущий момент для Bitrix‑проектов мы бы могли рекомендовать три дата‑центра:
Yandex Cloud. Является самым отличным решением благодаря разнообразию сервисов и настроек, которые в сумме дают возможность добиться отказоустойчивости вплоть до 97%. Проблем в работе Битрикс‑проектов не наблюдали, все работает как часы. Очень удобный личный кабинет. Встроенный мониторинг. Также важно отметить высокую скорость работы HDD‑дисков при больших объемах данных. Если у вас большое количество статики от 2 ТБ, то вам однозначно сюда. Правда, за все вышеуказанные плюсы имеем соответствующий ценник.
Selectel. Данный дата‑центр является наилучшим решением для физических серверов, однако для облачных решений не все так гладко. Нет возможности выбрать себе характеристики сервера при помощи конструктора, имеются только готовые конфигурации облачного решения. Нет возможности самостоятельно менять характеристики сервера. Все необходимо делать только через support, что, соответственно, увеличивает время на проработку этого момента. Также имеем высокий ценник, в каких‑то моментах даже дороже Yandex. Из плюсов — удобное и быстрое S3-хранилище. Если у вас много статики в S3, и вы привыкли к Selectel, то вам сюда.
Timeweb Cloud. Выбирая эту облачную платформу, вы убьете сразу двух зайцев: сможете моментально собрать и разpвернуть нужную конфигурацию сервера, полностью совместимого с Bitrix‑проектами, и в дальнейшем бесшовно менять его конфигурацию хоть каждую минуту. А главное — стоимость этого решения будет, как минимум, в 2 раза дешевле предыдущих. Такое ощущение, что облако создавалось именно под Битрикс, они идеально совместимы (в штате есть сертифицированные компанией 1С специалисты). Среди сервисов имеется удобный балансировщик нагрузки, а также управляемые базы MySQL и Redis, есть серверы с CPU 5 ГГц и быстрыми NVMe‑дисками внутри по умолчанию. Помимо этого, вы можете самостоятельно выбирать регион размещения — у провайдера есть локации в Санкт‑Петербурге, Новосибирске, Польше, Казахстане, Турции и в Нидерландах.
Для тех, кто твердо решил переехать в облако, будет полезна информация о нашей совместной акции с Timeweb Cloud: при переезде в облако вместе с Nixys в подарок:
1) Стартовый бонус на тестирование сервисов Timeweb Cloud.
2) Компенсация 100% затрат на инфраструктуру в Timeweb Cloud на время переезда.
3) Скидка 80% на аренду инфраструктуры после переезда на сервис Timeweb Cloud.
Подробнее об акции можно узнать на нашем сайте в поле обратной связи.
Теперь сравним цены. Берем сервер 8 CPU 16 RAM 500 SSD.
Физический сервер ~ 6100р. Однако, в данную стоимость не заложены часы работы вашего системного администратора на решения и отслеживания проблем с железом.
Yandex Cloud ~ 18627 р.
Облако Selectel ~ 40789 р.
Timeweb Cloud ~ 8569 р.
Все цены были взяты с официального сайта соответствующего облака/дата центра. Цены действительны на момент публикации статьи.
Также мы можем отметить дополнительные дата‑центры:
cloud.mts.ru — подойдет только для очень больших проектов; сложен в освоении.
www.reg.ru — только для очень маленьких проектов; мало конфигураций.
sbercloud.ru — имеются скидки при обслуживании, если у вас открыт расчетный счет в их банке.
firstvds.ru — нет Managed service.
Пример подбора, настройки в внедрения такого решения: наши практики
За последние месяцы мы перевезли порядка 20 проектов с физического сервера на облачное решение. С каждым переездом мы все больше и больше убеждаемся, что для Bitrix‑проектов это является best practice. За счет быстрых дисков и сервисов удавалось достичь более быстрого отклика площадок, чем это было на физическом сервере. Также нами были выработаны оптимальные настройки для MySQL в случаях, если был отказ от использования Managed service. Достигнута отказоустойчивость в пределах 95%.
Пример 1: У нас есть проект, который всегда имел простой площадки на новогодние праздники. Отклик площадки возрастал до 10–15 секунд. После того, как мы осуществили переезд в облако и динамически увеличили мощности Bitrix‑монолита, что устранило проблему.
Пример 2: Другой высоконагруженный интернет‑магазин. Была проведена работа по оптимизации базы и подготовки к облачном решению. Отказоустойчивость MySQL была реализована за счет синхронной репликации, без повышения лицензии Bitrix до enterprise за счет percona xtradb cluster и proxySQL. После этого была получена оценка 90 баллов в синтетических тестах Bitrix/admin. На текущий момент проект имеет горячую замену на случай падения основной базы данных. Отказоустойчивость кода была реализована за счет выноса статики в s3-хранилище и разделения кода на два сервера. В случае падения боевого сервера имеется горячая замена на второй сервер. Redis для сессий был вынесен в Managed service и скорость работы более чем устраивает.
Пример 3: Монолитный проект с физическим сервером, который уперся в потолок по своим характеристикам. 64 СPU и 256 RAM. Средняя LA на сервере составляла 73. Было принято решение распилить монолит на микросервисную архитектуру. Для MySQL был развернут кластер Managed service MySQL c характеристиками 24 CPU и 96 RAM. Для хранения сессий и кэша кластер Managed service Redis 4 CPU 64 RAM. Для кода были развернут кластер с php, состоящий из трех нод. Нами был написан pipeline для push изменений на 3 сервера, после чего настроили балансировщик на проверку доступности каждого из серверов, который в случае падения переключается на резервный сервер, за счет переезда на новое железо и виртуальные машины. Общие характеристики серверов остались практически на том же уровне: за счет микросервисной архитекторы мы смогли оптимально выставить характеристики для каждого сервиса. В случае роста проекта нашего клиента мы спокойно сможем использовать горизонтальное масштабирования для увеличения ресурсов.
Самое популярное заблуждение об облаке для Bitrix-проектов
Очень часто слышим от клиентов о том, что они боятся переезжать в облако только по одной причине, и как правило причина действительно у всех одна: «база будет работать гораздо медленнее по сравнению с физическим сервером«.
Мы можем подтвердить данное суждение только в одном случае — если вы запускаете MySQL со значениями по умолчанию. Однако, если покопаться в настройках MySQL, то вы получите те же значения, что и на физическом сервере. Также плюс к этому MySQL по умолчанию всегда будет запускаться только на быстрых SSD‑ или NVMe‑дисках. Из этого мы можем сделать вывод, что данный миф, который появился, скорее всего, в начале появления облаков, не является действительным. Сейчас, за счет кэширования базы данных (привет отличной работе percona xtradb), за счет быстрых дисков и оптимизации, Bitrix MySQL в облаке работает точно так же, как и на физическом сервере.
Выводы.
Мы однозначно рекомендуем переезжать в облако всем проектам Bitrix, так как использование физических серверов — честно говоря пережиток прошлого.
Переезд в облако избавит вас от:
1) вечных переездов с одного железа на другое;
2) нехватки CPU/RAM/дисков, так как все значения вы сможете регулировать динамически;
3) мониторинга состояния железа на сервере;
4) затрат времени на долгое время развертывание dev‑окружений;
5) проблем с помесячной оплатой: платите только тогда, когда пользуетесь;
Облако позволит вам:
1) использовать микросервисную архитектуру;
2) динамически масштабировать инфраструктуру горизонтально или вертикально.
Облако — это будущее, которое сейчас уже пользуется большим спросом. Попробуйте и вы, в этом нет ничего страшного =)))).
Надеемся, статья была полезной. Вопросы можете задавать в комментариях.
Также подписывайтесь на наш telegram‑канал [DevOps FM] — там много полезного для DevOps‑инженеров и системных администраторов.
Рекомендации для чтения: