Selectel дата-центры

В прошлых частях цикла «Введение в 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/

Из on-premises в облако — легко и без рисков

• Только факты. Расскажем о нюансах построения облачной инфраструктуры и ее отличиях от on-premises.
• Кейсы. Покажем, как настроить vCloud Availability. Расскажем о полезных инструментах VMware.
• Обратная связь. Ответим на вопросы, обсудим ваши кейсы.

Присоединяйтесь и прокачивайте свои знания по VMware!
Все подробности — по ссылке.
promo.selectel.ru/webinar_vmware_20_02_2020/

Спикер:
Иван Колегов — менеджер продукта VMware, Selectel.

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

Прежде всего рассмотрим сам процесс работы типичного 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/

Согласно докладу IDC «The Digitization of the world: from edge to core», объём глобальной инфосферы вырастет с 33 зеттабайт в 2018 году до 175 зеттабайт в 2025 году. При этом 49% хранящихся в мире данных будут находиться в общедоступных облачных средах. Как же реально устроен рынок облачных технологий? Что ждет его в будущем? Как оптимизировать IT-инфраструктуру и не допустить ошибок? Генеральный директор Selectel Олег Любимов подробно рассказал обо всем в интервью на радио Медиаметрикс Станиславу Жураковскому.

​О компании

C.Ж.: Selectel это… Что делает Selectel?

О.Л.: Selectel — это сервис-провайдер в области IT. Мы строим дата-центры и внутри дата-центров реализуем спектр услуг, ориентированных на предоставление IT-инфраструктуры для бизнеса. Это аренда выделенных серверов, облачные сервисы, обработка данных, хранение данных и всё связанное с этим.

Надо понимать, что бизнес дата-центров — очень «слоёный» бизнес. На самом низком уровне идут дата-центры, то есть здания, специально подготовленные для размещения IT-оборудования. Но в настоящее время мало клиентов, готовых потреблять услугу в простом, примитивном виде, когда необходимо самостоятельно покупать, размещать, обслуживать оборудование, решать проблемы с подключением интернет-провайдеров. Обычно бизнес потребляет более высокоуровневый тип услуг — готовую облачную инфраструктуру. Там можно через веб-панель управления заказать необходимый объем ресурсов, управлять им в реальном времени, дозаказывать что-то сверх необходимого в случае пиков нагрузки (например, сезонных), делать резервные копии и т. д.

Люди делают резервные копии?

Конечно. Это одна из самых востребованных услуг.

А почему?

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

О клиентах

Средний чек в отрасли?

Это будет, как средняя температура по больнице. Для понимания, нижняя граница стоимости предоставляемых нами услуг — 200 рублей в месяц для самого простого виртуального сервера. Верхняя граница — миллионы рублей в месяц. Средний чек можно рассчитать как 30-40 тысяч рублей в месяц, но очень усреднённо.

Что чаще заказывают?

Зависит от сервис-провайдера и клиента. Мы больше специализируемся на публичном облаке и на выделенных серверах, где медианный чек ближе к 40-50 тысячам рублей. Есть сервис-провайдеры, специализирующиеся на сегменте В2С, стартапах, индивидуальных предпринимателях, — это традиционный хостинг, виртуальные серверы. Там чек намного ниже: сотни и тысячи рублей. На другом конце этого бизнеса есть системные интеграторы, энтерпрайз сервис-провайдеры. Здесь продажи единичные, но совершённые госкомпаниям, крупному ритейлу и т. п., а речь уже идёт о миллионах рублей.

У вас в основном В2В продажи?

Если смотреть по выручке, то да, в основном В2В.

Госкомпаний сколько в структуре?

Единицы процентов. Мы не специализируемся на этом.

А почему?

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

Самые заказываемые отрасли? Откуда к вам приходят клиенты — из IT, верно? А реже откуда приходят?

Реже всего приходят банки, что связано с особенными требованиями к сохранности данных. Есть клиенты среди банковского сектора, но они не держат у нас ключевые системы. Они выносят к нам промо-страницы, связанные с единичными акциями данные, блоги и тому подобное. Вся биллинговая информация остается внутри банка. Так же в медицине. Меньше всего услуги дата-центров заказывают отрасли с высокоуровневыми и хорошо построенными решениями. Например, системы бронирования билетов у авиакомпаний. Их никогда не будет в абстрактном коммерческом дата-центре, потому что есть несколько систем общемировых, куда интегрированы все авиакомпании (например, Amadeus). Никто не будет создавать локальную копию этой системы и разворачивать в России.

Какие ключевые ошибки совершают клиенты при покупке услуг?

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

Об IT-отрасли

Сильно ли повлиял на рынок 2014 год?

2014 год очень сильно повлиял в сторону роста российского рынка. Особенно в период с конца 2014 и до начала 2015 года. Здесь не столько политические, сколько экономические причины. Когда доллар, условно, был 30, а стал 60 рублей, все российские клиенты убедились, что платить западным сервис-провайдерам (в первую очередь, Amazon, Microsoft и Google Cloud) в два раза дороже, чем в России. Было два пика перетока клиентов от западных сервис-провайдеров к российским: конец 2014-го — начало 2015-го, и апрель — май 2018-го, когда Роскомнадзор пытался заблокировать Telegram, но в итоге заблокировал всё, кроме Telegram’а. Под блокировку большого диапазона IP-адресов Amazon, Microsoft и Google Cloud, где Telegram прыгал с одного сервера на другой, чтобы уйти от Роскомнадзора, попало много российских ресурсов, размещенных на западных серверах. Тогда был очень большой приток российских клиентов с западных хостинг-провайдеров обратно в Россию.

Куда движется IT-рынок? Что делают западные компании отличного от российских?

По IT очень легко предвидеть будущее. Можно посмотреть на происходящее на Западе, у нас подобное будет через несколько лет. Для разных отраслей — срок разный, но в среднем около 4-5 лет. В России многие компании держат информационные системы на серверах, размещенных внутри офиса. Это более 50% компаний, особенно в малом бизнесе. На Западе — 80-90% компаний обращаются в специализированные дата-центры. И в течение 4-5 лет мы достигнем западных цифр. Мы оптимистично смотрим на рост рынка не столько из-за увеличения потребления услуг существующими клиентами, сколько из-за перехода компаний с собственной инфраструктуры в дата-центры.

Почему так много компаний у нас ещё не переехало?

Возможно, виновата некоторая инерционность мышления. Компании с трудом доверяют информационные системы сторонним сервис-провайдерам. Хотя страхи напрасны. Давно работают стандарты облачных услуг. Есть специальные услуги, сертифицированные соответствующим регулятором. Есть услуга защищенного сегмента ЦОД, когда оборудование огорожено как физически, так и с сетевой стороны. Таким образом важная информация может надежно храниться и обрабатываться.

Об облаках

Насколько облачная услуга будет стоить дороже или дешевле для компании?

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

В этом есть смысл? Нужно ли бизнесу столько вычислительных данных?

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

Доля российских компаний в услуге какая? Будет ли она изменяться?

Рыночная доля составляет примерно 60%. И думаю, она постепенно увеличится. Потому что упомянутый кейс с Роскомнадзором постоянно висит над связностью между российским и зарубежным интернетом. Если у вас бизнес и информационная система размещены в Amazon, Microsoft и Google Cloud, — без разницы где, но за пределами России, в силу различных причин доступ может быть заблокирован. Навсегда или на время — трудно предугадать. Думаю, доля российских игроков будет постоянно увеличиваться. Другая причина — российские сервис-провайдеры догоняют западных сервис-провайдеров, у них появляются новые услуги.

Пойдут ли российские компании за рубеж?

Маловероятно. Может быть, за исключением русскоязычного рынка ближнего зарубежья — Беларусь, Украина, Казахстан, Узбекистан. Эти страны всегда тяготеют к России. Местных сервис-провайдеров там немного, к западным подключаться не очень выгодно в силу географии, большой удаленности, задержек сети и неудобства использования. В этом направлении у российских компаний есть определенные перспективы. Выход на рынок США или Евросоюза будет тяжелым. У локальных сервис-провайдеров на домашних рынках изначальное преимущество. Американский или рынок Евросоюза в десятки раз больше российского — объемы потребления, масштабы, количество оборудования, размеры дата-центров и т. д. Чем крупнее объект, тем он выгоднее удельно на единицу мощности. Конкурировать в этом случае тяжело. Еще один момент, российскую компанию, не очень хорошо спрятавшую свои корни, сейчас с подозрением воспринимают на Западе.

В общем, тоже понятно, почему. Спасибо огромное. Через некоторое время узнаем, как у вас дела!

Selectel, провайдер облачных сервисов и услуг дата-центров, представил катастрофоустойчивый кластер Облака на базе VMware в московском регионе. Решение обеспечивает бесперебойную работу информационных систем. В основе разработки лежит технология VMware Stretched vSAN.
selectel.ru/services/cloud/vmware/

Катастрофоустойчивый кластер облака развернут в Москве на двух независимых инфраструктурных площадках уровня Tier3. В случае аварийной ситуации в основной локации происходит перезапуск виртуальных машин в резервной. Вероятность простоев или сбоев в работе информационных систем и приложений сводится к минимуму.

В комплексных тестах решения допустимая точка восстановления (Recovery Point Objective, RPO) приближалась к нулю. Эта характеристика описывает особенности восстановления данных. Например, равная одной минуте RPO означает, что при аварии возможна потеря только введенной за последнюю минуту информации. Таким образом, в катастрофоустойчивом кластере риск утраты данных на уровне СХД ничтожен. Такая эффективность обеспечивается синхронной репликацией данных.

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

Александр Тугов, директор по развитию услуг Selectel

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

Катастрофоустойчивый кластер Облака на базе VMware соответствует требованиям федерального закона № 152-ФЗ «О персональных данных». В нем можно обрабатывать и хранить персональные данные вплоть до первого уровня защищенности. В июне 2019 года Облаке на базе VMware было отмечено знаком доверия VMware Cloud Verified. Ранее профессионалы отрасли признали сервис «Облаком года» в рамках национальной премии «ЦОДы.РФ».