Рейтинг
0.00

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

17 читателей, 531 топик

12 марта пройдет вебинар по Managed Kubernetes — мы ждем вас



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



promo.selectel.ru/webinars/kubernetes/

Развертывание и базовая настройка Mikrotik CHR



Cloud Hosted Router — это специальная версия Mikrotik RouterOS, которая разработана для развертывания в облачной инфраструктуре как операционная система для виртуальных машин, но может быть также развернута и на реальном железе.

CHR создавалась для 64-битных систем и совместима с большинством гипервизоров.

Системные требования CHR:
  • процессор: x86_64 с поддержкой аппаратной виртуализации;
  • ОЗУ: 128 МБ и более;
  • диск: 128 МБ и более (максимально 16 ГБ).

Установка Mikrotik CHR на виртуальную машину
В статье рассмотрена установка CHR на Облачную платформу Selectel. Будем считать, что проект уже создан, а регион выбран.

selectel.ru/blog/mikrotik-chr-install/

27 февраля приглашаем на вебинар по облачным базам данных



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

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

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

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



promo.selectel.ru/webinars/dbaas/

Облачное хранилище как репозиторий для VBR



Мы все любим пользоваться привычными инструментами и следим за их развитием. Выпуск десятой версии Veeam Backup & Replication ознаменовался появлением новых крутых возможностей для системных администраторов, об одной из которых мы сегодня расскажем.

С повсеместным приходом виртуализации управление IT-инфраструктурой стало гораздо проще и удобнее, однако перед системными администраторами вставали новые задачи:
  • Чем обеспечивать резервное копирование виртуальных машин?
  • Где взять место для хранение резервных копий?
  • Как обеспечить минимальные RTO и RPO в случае сбоя?
  • Как минимизировать риски утери резервных копий?

Ответы на эти и подобные вопросы напрямую влияют на отказоустойчивость инфраструктуры и ее способность быстро восстановить работу в случае наступления катастрофы. Эта способность носит название Disaster Recovery, о чем мы рассказывали в одной из предыдущих статей.

Важным нововведением в Veeam Backup & Replication 10 стала возможность использования S3-совместимых объектных хранилищ данных, предоставляемых облачными провайдерами не только как место для хранения архивных резервных копий, но и как репозиторий для выполнения операций резервного копирования и восстановления. Облачное хранилище Selectel совместимо с новым функционалом приложения и позволяет выполнять резервное копирование и восстановление штатными средствами Veeam Backup & Replication.

Отдельно, хочется отметить, что данный функционал доступен даже для бесплатной версии Veeam Backup & Replication 10 Community Edition, что автоматически переводит возможность его применения на качественно новый «облачный» уровень.

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

Подробнее:
selectel.ru/blog/s3-vbr/

Дайджест Selectel: об услугах, новинках и событиях (январь 2020)



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

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

Открыта регистрация на Selectel MeetUp: информационная безопасность



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

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

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

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

Введение в SSD. Часть 3. Форм-факторная


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

Приглашаем на вебинар по VMware



Из 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.

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

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