27 февраля (четверг) в 11:00 по московскому времени
Продолжительность: 1 час

Зарегистрироваться
Работа с облачными БД может быть простой и быстрой

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

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



promo.selectel.ru/webinars/dbaas/

Всем привет! У нас готов первый дайджест в 2020 году — январский. Анонсируем новые сервисы, напоминаем о полезных публикациях в блогах компании, рассказываем о событиях и открытых вакансиях.

Оглавление:

• Serverless
• Managed Kubernetes
• DBaaS is…
• Тестирования
• Актуальная версия vCloud Availability
• Защита от DDoS-атак
• HyperServer для SAP HANA
• IT-б(л)ог
• Слово HR

selectel.ru/blog/digest-january-2020/

Приглашаем вас на Selectel MeetUp — мероприятие с короткими содержательным докладами и живым общением. 12 марта мы поговорим об информационной безопасности — обсудим ее практические аспекты и разберем кейсы компаний по защите данных. Митап пройдет в Санкт-Петербурге по адресу: ул. Цветочная, д. 19. Продолжительность мероприятия — 3 часа.

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

Поговорим о защите данных в IT

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

Представители Selectel, Veeam Software, Group-IB, Qrator Labs и Digital Security поделятся лучшими практиками и расскажут об опыте создания надежных систем информационной безопасности.

Подробнее о мероприятии читайте по ссылке. Присоединяйтесь, чтобы узнать, как построить защищенную информационную систему!
promo.selectel.ru/events/infosec/

В прошлых частях цикла «Введение в SSD» мы рассказали про историю появления дисков и интерфейсов взаимодействия с накопителями. Третья часть познакомит читателя с современными форм-факторами дисков.

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

«Классический» форм-фактор SSD

Форм-фактор 2.5″ был предложен в 1988 году компанией PrairieTek и позже был закреплен в стандарте EIA/ECA-720. Такие накопители могут подключаться как по SATA, так и по PATA, хотя последние уже не очень распространены. Диски данного форм-фактора длиной 100 мм, шириной 69.85 мм и высотой от 5 до 19 мм.

Говоря о форм-факторе 2.5″ невольно вспоминается его старший брат — 3.5″. Твердотельные накопители в таком формате редкость, но существуют по сей день. Например, ExaDrive от компании Nimbus Data. Диск может похвастаться невероятной вместимостью: 100 ТБ в одном 3.5″ накопителе.

У 2.5″ есть и младший брат: форм-фактор 1.8 дюймов. Данный форм-фактор использует для подключения mSATA и был распространен в ноутбуках.

U.2

U.2, так же известный как SFF-8639, был разработан в декабре 2011 года командой SSD Form Factor Working Group. Стандарт SFF-8639 разрабатывался в первую очередь для корпоративного сегмента с поддержкой PCIe-, SAS- и SATA-дисков. Внешне U.2 диски отличаются от 2.5″ другим коннектором и фиксированной высотой в 15 мм. На дисках в форм-факторе U.2 встречается рельефная нижняя стенка для улучшения теплоотвода.

U.2 реализует три вида интерфейсов: SATA, SAS и PCIe. Однако, каждый разъём поддерживает только один из интерфейсов. Так, в SAS-бэкплейне PCIe диск «не заведется». Это вызывало определенные неудобства, которые обязательно должен был решить другой форм-фактор.

U.3

20 марта 2018 года организация Open Compute Project представила форм-фактор U.3, который решает существующую проблему U.2. Согласно спецификации, интерфейсы SAS, SATA и PCIe поддерживаются на всех пинах, а выбор интерфейса производится в автоматическом режиме в зависимости от предоставляемых диском интерфейсов. Накопители U.3 совместимы с системами, использующими U.2, но не наоборот.
На данный момент нет дисков с форм-фактором U.3.

M.2

Этот форм-фактор так же известен как Next Generation Form Factor (NGFF). Первая версия стандарта M.2 была выпущена группой PCI Special Interest Group (PCI-SIG) в декабре 2013 года. Данный форм-фактор не ограничивается твердотельными накопителями: существуют Wi-Fi и Bluetooth-модули в таком исполнении.

Несмотря на то, что M.2-устройство часто фиксируется винтом, интерфейсы M.2 поддерживают «горячую замену». Таким образом, замена на «горячую» возможна, если устройство и материнская плата поддерживают такую возможность.

В сравнении с предыдущими форм-факторами M.2 предоставляет максимальную гибкость при проектирования устройства. Следующие характеристики устройства могут варьироваться:

• ширина;
• длина;
• высота;
• вид ключа и поддерживаемые интерфейсы.

Точный размер и тип ключа можно узнать по типу устройства.


Add-in-Card

Как мы узнали ранее, SSD могут использовать PCIe линии для подключения через специальные разъемы. Но существуют диски, использующие PCIe с оригинальными коннекторами. Такой форм-фактор называется AiC, то есть Add-in-Card. PCIe карты различаются по размерам.

Самым большим вариантом в Add-in-Card является Full-Height Full-Length (FHHL) профиль. Размер карты FHHL составляет 120 миллиметров в высоту и 312 миллиметров в длину. Твердотельные накопители обычно создаются в минимальном профиле: Half-Height Half-Length (HHHL) с высотой 79.2 мм и длиной 175.26 миллиметров.

NF1
В августе 2018 года Samsung представила форм-фактор NGSFF (Next Generation Small Form Factor), так же известный как M.3 или NF1. Форм-фактор от Samsung отличается от M.2 увеличенной шириной и отсутствием разнообразия в коннекторах. Длина NGSFF-диска составляет 110 миллиметров, а ширина — 30 миллиметров, что эквивалентно самой большой M.2-плате.


NF1 использует коннекторы, идентичные коннекторам типа «M» форм-фактора M.2, тем не менее, M.2 и NF1 не совместимы между собой. PCI-SIG не одобряет использование разъема M.2 в данном форм-факторе, так как установка M.2 устройств в NF1 разъем может привести к повреждению устанавливаемого оборудования.

Данный форм-фактор разработан для серверного сегмента: увеличенная ширина позволяет вместить до 36 накопителей в 1U сервер.

EDSFF


Enterprise & Data Center SSD Form Factor (EDSFF), известный как Intel Ruler SSD разработан EDSFF Working Group. EDSFF представляет две версии серверных SSD-дисков: короткий (E1.S) и длинный (E1.L).

Короткая версия EDSFF, E1.S, очень похожа на своего ближайшего конкурента — NGSFF, но имеет металлический корпус, который одновременно защищает плату от механических повреждений и выступает салазками для установки в сервер. Размеры диска E1.S не сильно отличаются от NGSFF: 111 миллиметров в длину и 31 миллиметр в высоту.


E1.L почти в три раза длиннее E1.S, его длина — 325 миллиметров. Увеличение длины накопителя позволяет увеличить объём диска. В мае 2019 Intel представила SSD D5-P4326 объёмом в 15.36 ТБ, а в будущем планирует выпустить модель с вместимостью 30,72 ТБ.

Заключение
Большинство форм-факторов давно устоялись, а все изменения в накопителях происходят «под капотом». Тем не менее, производители придумывают новые форм-факторы для NVMe, преследуя цель увеличить количество дисков в одном юните серверного пространства.

В нашей Selectel Lab вы можете протестировать Intel SSD D5-P4326 15.36 TB в сервере на базе высокочастотного Intel Xeon W-3235.
selectel.ru/lab/

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

Прежде всего рассмотрим сам процесс работы типичного Web-приложения:

• Запрос пользователя попадает на Front-end.
• Front-end делает запрос в Back-end.
• Back-end отдает ответ на Front-end.
• Front-end формирует и отдает пользователю результат.

Если у нас есть только один Front-end и один Back-end, то балансировать тут особо и нечего. Усложним задачу. Теперь у нас есть один Front-end и два Back-end сервера. Если балансировщик отсутствует вообще и программно не настроено распределение запросов, то один Back-end всегда будет простаивать, а второй принимать на себя всю нагрузку. Так или иначе нужно распределить запросы между двумя серверами.

И вот мы плавно переходим к методам балансировки. В нашем Балансировщике нагрузки для Облачной платформы Selectel реализовано два самых эффективных и часто используемых алгоритма:

• Round Robin (циклический алгоритм);
• Least connections (алгоритм наименьших соединений).

Рассмотрим каждый из алгоритмов подробнее.

Round Robin
Этот алгоритм очень прост для понимания. Запросы отправляются на все балансируемые серверы попеременно. Так что, в описываемом нами случае с одним Front-end и двумя Back-end серверами все выглядит просто замечательно. В идеальном варианте у нас нагрузка на каждый Back-end будет распределена равномерно, то есть 50% на 50%. Но есть одна серьезная проблема.

Несмотря на то, что запросы равномерно распределились по серверам, их обработка будет занимать разное время. А это значит, что через N-ное количество запросов загрузка обоих Back-end серверов станет различной. Это не будет являться проблемой ровно до того момента, пока один из них не начнет отдавать в ответ ошибки.

Для пользователя такие ошибки будут выражаться в том, что запрашиваемые функции просто перестанут адекватно работать, например, пользователь не сможет «положить товар в корзину». С точки зрения бизнеса подобные ошибки равноценны упущенной прибыли, а следовательно, к вопросу балансировки следует подойти еще более ответственно.

Least connections
Теперь, зная потенциально уязвимое место алгоритма Round Robin, перейдем ко второму алгоритму Least connections. Суть его в том, что балансировщик смотрит сколько соединений установлено на каждом из подконтрольных ему серверов и определяет минимально загруженный. Именно на него начинают отправляться новые запросы.

Казалось бы, вот он — идеальный механизм балансировки. Серверы будут равномерно загружены вне зависимости от времени исполнения запросов. Но это справедливо ровно до того момента, пока перед нами не встает необходимость балансировки нагрузки между двумя и более Front-end серверами.

Когда пользователь установил соединение с одним из Front-end сервером, то все его последующие запросы нужно отправлять на тот же самый сервер. Если же будет отрабатывать только алгоритм Least connections, то мы создаем ситуацию, когда установивший сессию пользователь может быть направлен на другой Front-end. И это означает повторную необходимость в авторизации, чего быть не должно. Тут на помощь нам приходит такая полезная опция балансировщика, как Sticky sessions.

Sticky sessions
Название говорит само за себя. Указанный механизм заставляет балансировщик направлять запрос одного и того же пользователя на один и тот же Front-end сервер. Для этого балансировщику нужно опознать пользователя, используя один из трех доступных вариантов:

• по ARP-cookie;
• по HTTP-cookie;
• используя Source IP.

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

• ARP-cookie в большинстве случаев идеален для сложных веб-приложений, но выдачу этого фрагмента данных необходимо заранее реализовать в коде приложения.
• HTTP-cookie — отличный вариант для авторизации пользователя. Балансировщик вначале задействует алгоритм Least connections для выбора сервера, а затем прикрепляет собственный HTTP-cookie, чтобы последующие запросы клиента отправлялись только на тот же самый сервер.
• Source IP — тут тоже все вроде просто. Балансировщик смотрит на соответствующее поле пакета и все запросы с одного IP-адреса отправляет на один и тот же Front-end сервер. При этом балансировщик еще и учитывает параметр «вес» подконтрольных серверов, но об этом поговорим ниже.

Отметим, что вариант Source IP имеет очень серьезный «подводный камень», а именно пользователей, которые приходят из сетей мобильных операторов связи. В некоторых случаях сотни пользователей могут приходить с одного-единственного IP-адреса. И все они будут заботливо отправлены балансировщиком на один Front-end сервер, который вполне может и лечь под нагрузкой. Так что, выбирая этот вариант, нужно учитывать возможность возникновения подобной ситуации.

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

Сама собой напрашивается аналогия с автоматической коробкой переключения передач в машине, где есть псевдо-ручной режим (TipTronic / AutoStick / Steptronic / Multitronic и другие). Автомобиль управляется автоматической коробкой переключения передач, но водитель может ограничивать ее работу диапазоном передач или напрямую указать желаемую передачу для движения. При этом автоматика постарается выполнить команду водителя, но не даст коробке работать в недопустимых для нее условиях.

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

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

• HTTP/HTTPS;
• PING;
• TCP.

Проверки гибко настраиваются по нескольким параметрам, таким как:

• интервалы проверки;
• таймауты соединения;
• для HTTP-запросов — URL и ожидаемые коды ответа;
• пороговые значения успешных и неуспешных запросов подряд.

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

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

Сценарии использования
Мы детально рассмотрели в нашей Базе Знаний использование Балансировщика нагрузки для равномерного распределения запросов между разными серверами. Теперь расскажем о том, в каких сценариях можно его применять.
kb.selectel.ru/47683265.html

Масштабирование
Горизонтальное и вертикальное масштабирование без даунтайма — всегда актуально. Облачная платформа Selectel позволяет легко произвести оба вида масштабирования, но для того, чтобы не было перерывов в обслуживании как раз подойдет Балансировщик нагрузки.

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

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

Отказоустойчивость
Мы уже не раз рассказывали о том, что такое High Availability и для чего используется. Процесс балансировки нагрузки как раз подразумевает отказоустойчивость в плане обслуживания запросов клиентов. Как только балансировщик «понимает», что подконтрольный ему сервер не может более отвечать на запросы (ну к примеру, он перегружен), то трафик переводится на другие серверы.

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

Развертывание приложений
В работе DevOps большую популярность имеет техника развертывания приложений, под названием «канареечный релиз». Такое забавное название берет свое начало из работы шахтеров. Основную опасность при работе в шахте представляет метан, бесцветный газ без вкуса и запаха. Сам по себе он не токсичен, однако его опасность очевидна. Чтобы произошел взрыв, достаточно даже небольшой концентрации от 5% до 16%.

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

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

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

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

Пора прерывать новостное затишье — это первая рассылка Selectel в 2020 году. Сегодняшний выпуск посвящен новым сервисам «Облачной платформы Selectel», обновленной защите от DDoS-атак, решению Selectel HyperServer для SAP HANA и vCloud Availability. В конце письма — статьи в блоге и актуальные вакансии.

Три беты в «Облачной платформе Selectel»
1. «Облачные функции»
Создавайте приложения, не думая о поддержке инфраструктуры, вместе с нашим первым Serverless-сервисом — «Облачные функции». Мы долго работали над этим продуктом — собирали вашу обратную связь и учитывали каждое пожелание.
Облачные функции
«Облачные функции» — сервис бессерверных вычислений, который позволит сосредоточиться на написании кода. Он хорошо справится с автоматизацией фоновых задач, вычислениями на статичных сайтах, ETL-процессами и бэкендом для мобильных приложений. Доступная среда выполнения — Python 3.6.
Создайте свою первую функцию в нашей панели управления уже сейчас. Если возникнут вопросы, читайте об услуге в базе знаний или пишите на support@selectel.ru
selectel.ru/services/cloud/serverless/
kb.selectel.ru/54807252.html

2. Managed Kubernetes
Раньше мы предоставляли сервис для развертывания кластера Kubernetes, обслуживанием которого приходилось заниматься вам. Теперь мы исправили это и запустили по-настоящему автоматизированный Managed Kubernetes, стабильность и надежность которого обеспечивается нашими специалистами. Он упростит процесс создания кластеров и автоматизирует их обслуживание.

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

Сервис находится в режиме бета-тестирования, поэтому master-ноды предоставляются бесплатно. Серверы нод-групп, входящих в состав кластера, тарифицируются по стоимости ресурсов «Облачной платформы Selectel». Cоздайте готовый к работе кластер в несколько кликов в панели управления.
my.selectel.ru/vpc/projects

3. «Облачные базы данных»
Облачные базы данных
Хорошая новость для тех, кто ждал появления «Облачных баз данных» в Selectel — мы запустились в бета-версии! Сервис позволит быстро и легко развертывать высокопроизводительные и надежные кластеры баз данных PostgreSQL, не тратя время на их конфигурацию и обслуживание. Настройки кластеров БД оптимизированы под выбранную вами конфигурацию сервера и тип кластера.
Продукт находится на стадии тестирования и сбора обратной связи. А это значит, что вы можете повлиять на его развитие. Оцените бесплатно возможности управляемой БД в панели Selectel и поделитесь впечатлениями. Подробнее об услуге читайте в базе знаний.
selectel.ru/services/cloud/managed-databases/
kb.selectel.ru/54811990.html

Все на тест
Актуальная версия vCloud Availability
Мигрировать в «Облако на базе VMware» и создавать там катастрофоустойчивую инфраструктуру стало еще заманчивее, ведь в Selectel мы используем новую версию продукта vCloud Availability.
В новой редакции вы сможете более гранулярно настраивать параметры аварийного восстановления, выставлять очередь загрузки виртуальных машин в облаке и задавать сетевые настройки. Никогда настройка Disaster Recovery не была такой простой! И, самое главное, вы можете протестировать ее бесплатно. Для этого пишите на sales@selectel.ru или звоните по телефону +78005550675
selectel.ru/services/cloud/vmware/public-cloud/
HyperServer для SAP HANA
Мы представили новое решение — хостинг SAP HANA. Оно построено на нашей услуге Selectel HyperServer. В новом решении мы подготовили кейсы использования сервиса для размещения SAP HANA, а также напомнили о возможностях HyperServer. Всю информацию об этом читайте на странице.
selectel.ru/solutions/hyperserver/
Защита от DDoS-атак
Мы обновили «Защиту от DDoS-атак», оказываемую совместно с компанией Qrator Labs.

• Теперь для каждого тарифа указано его полное описание, что помогает сравнить и выбрать подходящий.
• В абонентскую плату включен легитимный трафик. Вместо 3 Мбит/cек — 10 Мбит/сек. И это без изменения стоимости!
• Для тарифов группы Large Business добавлены дополнительные полосы легитимного трафика. Вы можете заказать к своему тарифу дополнительную полосу на 100, 250 или 500 Мбит/сек со скидкой до 30%.

Напишите на sales@selectel.ru — мы поможем подобрать нужную защиту для ваших проектов.
Работа в Selectel
Присоединяйтесь к нашей команде! Есть открытые вакансии в Санкт-Петербурге и Москве, посмотреть полный перечень можно здесь.

• Разработчик Python (Выделенные серверы)
• Санкт-Петербург
• Продакт-менеджер услуг Kubernetes
• Санкт-Петербург
• Системный администратор отдела поддержки облачной инфраструктуры
• Санкт-Петербург
• Директор по развитию продуктов дата-центров
• Санкт-Петербург, Москва

selectel.ru/careers/all/

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

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

Новый сервис отлично справится с автоматизацией фоновых задач (отправкой писем, генерацией скриншотов или работой с API), вычислениями на статичных сайтах, ETL-процессами и бэкендом для API и мобильных приложений.
selectel.ru/blog/serverless-guide/

Сегодня мы представляем открытую для тестирования бета-версию Managed Databases для PostgreSQL, использование которой будет бесплатным на период бета-тестирования.

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

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

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

selectel.ru/blog/dbaas-beta/

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

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

Услуга аренды выделенных серверов появилась практически с начала работы компании. Нашей задачей было предоставлять в аренду качественные серверы, которые будут работать в наших собственных дата-центрах. Вместе с этим заказчику предоставлялся на выбор безлимитный интернет-канал 100 Мбит/с или же интернет-канал с пакетом трафика в 30 ТБ и скоростью 1 Гбит/с, а также «белый» IP-адрес. По желанию на сервер устанавливалась нужная операционная система. В комплексе заказчик получал полностью готовый к работе выделенный сервер, который можно было использовать под любые цели и задачи.

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

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

Особенности классических серверов

• Заказчик самостоятельно осуществляет мониторинг работы физических серверов.
• Установка ОС происходит в ручном или полуавтоматическом режиме.
• Модификация конфигурации (для серверов произвольной конфигурации) выполняется инженерами вручную. Требуется дополнительно обговаривать время и срок исполнения.
• От заказчика требуется глубокое понимание того, как работает программное обеспечение.
• Заказывается на длительный срок (от 1-го месяца).

Особенности облачных серверов

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

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

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

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

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

Мы не стали полагаться на готовые решения в сфере управления выделенными серверами, предпочтя им создание собственной системы управления. Это позволяет нам не только избежать потенциальной ситуации с vendor lock-in (зависимость от поставщика программного решения), но еще и иметь полный контроль над всеми используемыми функциями.

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

• управление питанием разных типов устройств (IPMI, PDU);
• управление различным сетевым оборудованием;
• сложная система учета ресурсов и развертывания, которая должна вызывать нужные действия в определенном порядке.

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

• Взять из пула свободный сервер нужной конфигурации и привязать его к аккаунту клиента.
• Выделить новый IP-адрес и также привязать к аккаунту.
• Прописать настройки для сетевого порта этого сервера на коммутаторе.
• Подготовить скрипт для установки ОС.
• Запустить сервер по питанию.
• Дождаться окончания работы скрипта по установке ОС.

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

• очистка HDD скриптом, перезаписывающим всю поверхность нулями;
• очистка SSD методом Secure Erase;
• контроль показателей S.M.A.R.T.

Это гарантирует то, что, если на сервере остались конфиденциальные данные — они не попадут к другим клиентам. В случае, если показатели S.M.A.R.T. выявляют проблемы с диском — его меняют на другой.

Теперь же все эти операции, кроме замены диска автоматизированы и не требуют ручного вмешательства инженеров. Помимо показателей S.M.A.R.T. скрипт отслеживает общее время работы диска и даже если все остальные показатели в норме — диск заменят при наработке определенного количества часов. Если любой из дисков сервера по каким-либо причинам не предоставил данные S.M.A.R.T., то система автоматически передаст этот сервер на диагностику инженерам.

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

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

Попробовать новую систему в действии можно буквально уже сейчас, пройдя по ссылке — заказать выделенный сервер!

Мы благодарны вам за отзывы, ведь они помогают нам улучшать наши продукты. Если вам что-то особенно понравилось, то тоже пишите — нам будет приятно об этом узнать.
selectel.ru/services/dedicated/