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

selectel.ru/promo/for-programmers/

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

blog.selectel.ru/perf-i-flamegraphs/

selectel.ru/careers/internships/

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

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

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

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

Основные принципы ботостроительства


Деятельность чат-ботов строится вокруг 3 основных действий:

• Получение или вывод информации происходит через определенные каналы связи, например, в Slack или диалогах Vk.com
• Распознавание намерения — это комплексный анализ полученной информации для формирования ответа
• Обработка действия — любая работа, проведенная на серверной стороне, необходимая для подготовки верного ответа. Например, если был запрошен прогноз погоды, то будет произведен запрос к некому API о погоде в городе N, и пользователю будут отправлены результаты этой команды

Основные действия чат-ботов объединяются в рамках задачи сохранения контекста для создания человекоподобной формы общения и поддержки диалога. Чат-бот должен «помнить» предмет разговора и адаптировать свои ответы соответствующим образом.

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

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

Ботостроительство
Изложенные выше 3 принципа работы чат-ботов (канал, анализ, действие) можно реализовать по-разному. Самый простой вариант — проводить сравнения поступающего текста и отправлять пользователю соответствующие ответы.


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

Для этого нам необходимо понимать, о чем говорит пользователь, контролировать ход диалога и в некоторых случаях выполнять определенные действия (например, бронировать переговорные комнаты). Добиться этого можно, используя следующие инструменты:

• DialogFlow (Google)
• Wit.ai (Facebook)
• Azure Bot Service (Microsoft)
• Rasa Core (Open Source)

При выборе продукта учитываются следующие факторы:

• Насколько критично размещение исполняемого кода бота в рамках существующих систем
• Например, в случае Wit.ai и Dialogflow мы не контролируем полностью весь процесс — мы отдаем этим приложениям текст и получаем готовый ответ. Используя Rasa Core или Azure BotBuilder SDK, мы можем хранить всю переписку в границах внутренних систем
• Сколько каналов связи необходимо подключить
• Dialogflow предоставляет возможность использования ограниченного количества коннекторов, которые подключают мессенджеры и социальные сети через указание ключей доступа. Для Wit.ai и Rasa Core можно использовать любое количество каналов, но логику подключения к ним необходимо реализовать самостоятельно (зачастую это очень тривиальная задача). Azure Bot Service имеет возможность использования коннекторов к определенным каналам, но не ограничен ими, и его можно подключать также к другим источникам самостоятельно
• Насколько просто можно вносить изменения в базу знаний бота

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


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

• Рост числа сотрудников компании, а вместе с этим увеличивающийся поток однотипных вопросов вроде «Как пользоваться корпоративной библиотекой?» и «Где пообедать?»
• Регулярное бронирование переговорных и оформление пропусков
• Поиск информации и документов в корпоративной базе знаний

Создание и подключение бота в Dialogflow занимает несколько минут. В начале рассмотрим принципы работы чат-бота в системе, а затем добавим выполнение сложных действий.

Создание бота в Dialogflow
Создание архитектуры
Далее в тексте мы будем оперировать такими понятиями, как:

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

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

Намерение включает в себя тренировочные фразы, параметры и ответы. Внутри тренировочной фразы мы выделяем параметры (например, время или место), которые необходимы для формирования корректного ответа.

Ответ указывается либо в намерении, либо Dialogflow отправляет запрос на наш сервер, который выполняет необходимую работу и возвращает обратно ответ на примере нашего чат-бота:

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

Работа с намерениями
Рассмотрим работу с Dialoglow на примере бронирования переговорной. Мы создаем агент управления бронированиями и определяем следующие намерения:

• Просмотреть существующие бронирования
• Забронировать переговорную

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

• Забронируй на сегодня в 23.15 на 30 минут на меня
• Привет. Прошу забронировать на 08.11.2018 переговорную с 15:00 до 16:00
• Забронируй
• Мне нужна переговорная

Принцип работы сбора данных в намерениях следующий:

• Dialogflow на основе полученного ввода понимает, о каком намерении идет речь. В нашем примере — бронирование переговорных
• Если обязательные параметры не были указаны в первом сообщении (например, время встречи), то чат-бот задаст уточняющие вопросы
• После получения всех данных Dialogflow отправит запрос на наш сервер в VPC для бронирования нужной комнаты

Посмотрим на этот процесс в действии:


Обработка действия осуществляется отправкой запроса со всеми данными на заранее добавленный адрес сервера действий (Webhook URL):


По адресу website.ru/webhook находится сервер, который выполняет обработку сложных команд (в нашем примере возвращает строку «Привет от сервера!»). Github Gist для быстрого старта:


Создание бота с помощью RASA
Для использования чат-бота без сторонних сервисов для распознавания текста можно использовать инструменты наподобие Rasa, которые позволяют полностью управлять всем процессом работы бота. Rasa — набор программных компонентов с открытым исходным кодом, которые содержат распознавание речи и управление диалогами. Уже сейчас можно посмотреть на Boilerplate, который я подготовил для знакомства с платформой, а более подробную инструкцию мы опубликуем, если будут запросы от Habr-сообщества.

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

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

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

Обычная L2 схема
По мере роста IT-инфраструктуры в дата-центре у клиентов возникает необходимость объединять серверы, СХД, файерволы в единую сеть. Для этого Selectel изначально предлагает использовать локальную сеть.

Локальная сеть устроена как классическая «кампусная» сеть в пределах одного дата-центра, только вот коммутаторы доступа расположены непосредственно в стойках с серверами. Коммутаторы доступа далее объединены в один коммутатор уровня агрегации. Каждый клиент может заказать подключение к локальной сети для любого устройства, которое он арендует или размещает у нас в дата-центре.

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


Неважно, в какой стойке стоит очередной сервер — Selectel объединяет серверы в единую локальную сеть, и не надо думать о коммутаторах или местоположении сервера. Вы можете заказать сервер тогда, когда он будет нужен, и он будет подключен к локальной сети.

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


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

По мере роста количества дата-центров, стоек, серверов схема все более усложняется. Сначала связность между серверами разных дата-центров осуществлялась просто на уровне коммутаторов агрегации с использованием технологии VLAN.


Но идентификационное пространство VLAN весьма ограничено (4095 VLAN ID). Так что для каждого дата-центра приходится использовать свой набор VLAN, что сокращает количество возможных идентификаторов, которые можно использовать между дата-центрами.

Проблемы L2
При использовании схемы на уровне L2 с использованием VLAN некорректная работа одного из серверов в дата-центре может привести к перебоям в предоставлении услуги по другим серверам. Из наиболее частых проблем можно отметить:

• Проблемы с STP (Spanning-Tree Protocol)
• Проблемы с широковещательными штормами (Broadcast Storm)
• Проблемы с некорректной обработкой мультикаста
• Человеческий фактор (перенос линков, перенос VLAN)
• Проблемы с организацией резервирования по L2
• Проблемы с unknown-unicast трафиком
• Проблемы с количеством МАС-адресов
• Проблемы с STP зачастую касаются в том числе и настроек клиентских серверов или клиентского оборудования. В отличие от популярных точек обмена трафиком, мы не можем полностью фильтровать STP на портах доступа и гасить порты при поступлении STP PDU. На STP у ряда производителей сетевого оборудования реализуется такой базовый функционал коммутаторов дата-центра, как обнаружение петель в сети.

При некорректной работе с STP со стороны клиентского оборудования может быть затронут весь STP-домен как минимум одного коммутатора доступа. Использование расширений протокола STP, таких как MSTP, также не является решением, поскольку количество портов, VLAN, коммутаторов зачастую превышает архитектурные возможности масштабирования протокола STP.

Broadcast
Сеть в дата-центре может быть построена на устройствах разных производителей. Порой достаточно даже отличий в версии ПО коммутаторов, чтобы коммутаторы по-разному обрабатывали STP. Так, например, в дата-центре «Дубровка 3» расположено 280 стоек, что превышает максимально возможное количество коммутаторов в одном STP-домене.

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

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

Защищая сеть целиком, коммутатор агрегации «положит» порт, на котором произошла сетевая аномалия. К сожалению, это приведет к неработоспособности как пяти серверов, из-за которых произошел данный инцидент, так и к неработоспособности других серверов (вплоть до нескольких стоек в дата-центре).

Multicast
Проблемы с некорректной обработкой multicast-трафика — очень специфичные проблемы, возникающие в комплексе из-за некорректной работы ПО на сервере и ПО на коммутаторе. Например, между несколькими серверами настроен Corosync в multicast-режиме. Штатно обмен Hello-пакетами осуществляется небольшими объемами. Но в ряде случаев серверы с установленным Corosync могут пересылать достаточно много пакетов. Этот объем уже требует или специальной настройки коммутаторов, или использования корректных механизмов обработки (IGMP join и другие). При неправильном срабатывании механизмов или при срабатывании порогов могут быть перерывы сервиса, которые затронут других клиентов. Конечно, чем меньше клиентов на коммутаторе, тем меньше вероятность возникновения проблем от другого клиента.

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

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

Никакая автоматическая патч-панель не проложит новый кабель, если он потребуется. Ошибиться можно и при настройке коммутатора или маршрутизатора. Указать неправильный номер порта, номер VLAN, опечататься при вводе числового значения. При указании каких-то дополнительных настроек не учесть их влияние на существующую конфигурацию. При увеличении сложности схемы, усложнении схемы резервирования (например, по причине достижения текущей схемой предела масштабирования) вероятность человеческих ошибок возрастает. Человеческая ошибка может быть у любого, независимо от того, что за устройство находится в стадии конфигурирования, сервер, коммутатор, маршрутизатор или какое-то транзитное устройство.

Организация резервирования по L2, на первый взгляд, кажется простой задачей для небольших сетей. В курсе Cisco ICND проходят основы использования STP в качестве протокола, как раз изначально предназначенного для организации резервирования по L2. STP имеет массу ограничений, которые в этом протоколе, что называется, «by design». Надо не забывать, что любой STP-домен имеет очень ограниченную «ширину», то есть количество устройств в одном STP-домене, довольно мало по сравнению с количеством стоек в дата-центре. Протокол STP в своей изначальной версии разделяет линки на используемый и резервный, что не обеспечивает полной утилизации аплинков при нормальной эксплуатации.

Использование других протоколов резервирования по L2 налагает свои ограничения. Например, ERPS (Ethernet Ring Protection Switching) — на используемую физическую топологию, на количество колец на одном устройстве, на утилизацию всех линков. Использование других протоколов, как правило, сопряжено с проприетарными изменениями у разных производителей или ограничивает построение сети одной выбранной технологией (например, TRILL/SPBm-фабрика при использовании оборудования Avaya).

Unknown-unicast
Особо хочется выделить подтип проблем с unknown-unicast трафиком. Что это такое? Трафик, который по L3 предназначен на какой-то конкретный IP-адрес, но по L2 широковещается в сети, то есть, передается на все порты, принадлежащие данному VLAN. Данная ситуация может возникать по ряду причин, например, при получении DDoS на незанятый IP-адрес. Или если при опечатке в конфигурации сервера был указан несуществующий в сети адрес в качестве резервного, а на сервере исторически существует статическая ARP-запись по этому адресу. Unknown-unicast появляется в случаях наличия всех записей в ARP-таблицах, но при отсутствии МАС-адреса получателя в таблицах коммутации транзитных коммутаторов.

Например, порт, за которым расположен сетевой хост с данным адресом, очень часто переходит в выключенное состояние. Подобный вид трафика лимитируется транзитными коммутаторами и обслуживается зачастую так же, как и broadcast или multicast. Но в отличие от них, unknown-unicast трафик может быть инициирован «из интернета», а не только из сети клиента. Особенно велик риск возникновения unknown-unicast трафика в случаях, когда правила фильтрации на пограничных маршрутизаторах позволяют подмену IP-адресов снаружи.

Даже само количество МАС-адресов может иногда быть проблемой. Казалось бы, при размере дата-центра в 200 стоек, по 40 серверов в стойке, вряд ли количество МАС-адресов сильно превысит количество серверов в дата-центре. Но это уже не соответствующее действительности утверждение, так как на серверах может быть запущена одна из систем виртуализации, и каждая виртуальная машина может быть представлена своим МАС-адресом, а то и несколькими (при эмуляции нескольких сетевых карт на виртуальной машине, например). Итого мы можем получить с одной стойки в 40 серверов больше нескольких тысяч легитимных МАС-адресов.

Такое количество МАС-адресов может повлиять на заполненность таблицы коммутации на некоторых моделях коммутаторов. Кроме того, для определенных моделей коммутаторов при заполнении таблицы коммутации применяется хеширование, и какие-то МАС-адреса могут вызвать хеш-коллизии, ведущие к появлению unknown-unicast трафика. Случайный перебор МАС-адресов на арендованном сервере со скоростью, скажем, 4,000 адресов в секунду, может вызвать переполнение таблицы коммутации на коммутаторе доступа. Естественно, на коммутаторах применяются ограничения по количеству МАС-адресов, которые могут быть изучены на портах коммутатора, но в зависимости от конкретной реализации данного механизма, данные могут трактоваться по-разному.

Опять же, отправка трафика на МАС-адрес, зафильтрованный данным механизмом, ведет к появлению unknown-unicast трафика. Самое неприятное в данной ситуации, что коммутаторы редко тестируются у производителя на самовосстановление после случаев с переполнением таблицы коммутации. Разовое переполнение таблицы, вызванное, скажем, ошибкой одного клиента в параметрах hping или в написании скрипта, обеспечивающего мониторинг его инфраструктуры, может вести к перезагрузке коммутатора и перерыву связи для всех серверов, расположенных в стойке. Если же такое переполнение случается на коммутаторе уровня агрегации, то перезагрузка коммутатора может привести к 15-минутному простою всей локальной сети дата-центра.

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

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

Связь front и back-end, резервное копирование
Как правило, использование локальной сети начинается с разделения функционала front и back-end сервисов, выделения СУБД на отдельный сервер (для повышения производительности, для разделения типа ОС на сервере приложений и СУБД). Поначалу использование L2 для данных целей выглядит оправданным, в сегменте всего несколько серверов, часто они даже расположены в одной стойке.


Серверы включаются в один VLAN, в один или несколько коммутаторов. По мере увеличения количества оборудования, все новые и новые серверы включаются в коммутаторы новых стоек в дата-центре, от чего L2-домен начинает расти в ширину.


Появляются новые серверы, в том числе резервные серверы БД, серверы резервного копирования и тому подобные. Пока проект живет в одном дата-центре, проблем масштабирования, как правило, не возникает. Разработчики приложения просто привыкают, что на очередном сервере в локальной сети IP-адрес меняется только в последнем октете, а прописывать какие-то отдельные правила маршрутизации не требуется.

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


Казалось бы, надо всего лишь соединить одним VLAN два коммутатора агрегации в ДЦ1 и ДЦ2. Но что стоит за этим простым действием?

Резервирование ресурсов
Во-первых, мы увеличиваем ширину L2 домена, таким образом все потенциальные проблемы локальной сети ДЦ1 могут возникнуть в ДЦ2. Кому понравится, что его серверы расположены в ДЦ2, а инцидент, связанный с недоступностью локальной сети, произойдет по причине некорректных действий внутри ДЦ1?

Во-вторых, надо позаботиться о резервировании этого VLAN. Коммутатор агрегации в каждом дата-центре — точка отказа. Кабель между дата-центрами — еще одна точка отказа. Каждую точку отказа следует зарезервировать. Два коммутатора агрегации, два кабеля от коммутаторов агрегации до коммутаторов доступа, два кабеля между дата-центрами… Каждый раз увеличивается количество компонентов, а схема усложняется.


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

Но MPLS-устройства, как правило, в два раза дороже, чем не-MPLS. И надо отметить то, что MPLS-коммутатор в 1U, обладающий хорошей степенью масштабируемости, реализацией полноценного функционала MPLS в Control-plane, на практике, не существовал до последнего времени. В итоге хочется избавиться или минимизировать влияние проблем L2 на существующую сеть, но при этом сохранить возможность резервирования ресурсов.

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

Внутри дата-центра мы можем сохранить существующие схемы взаимодействия серверов друг с другом по L2, а выход к серверам в другом дата-центре будет осуществляться по L3.


Таким образом, дата-центры связаны между собой L3-связностью. То есть эмулируется, что между дата-центрами установлен маршрутизатор (на самом деле, несколько, для резервирования). Это позволяет разделить L2-домены между дата-центрами, использовать в каждом дата-центре свое собственное пространство VLAN, осуществлять между ними связь. Для каждого из клиентов можно использовать повторяющиеся диапазоны IP-адресов, сети полностью изолированы друг от друга, и из сети одного клиента не попасть в сеть другого клиента (кроме случаев, когда оба клиенты согласны на такое соединение).

Мы рекомендуем использовать для локальных сетей IP-сегменты из адресации 10.0.0.0/8. Для первого дата-центра сеть будет, например, 10.0.1.0/24, для второго — 10.0.2.0/24. Selectel на маршрутизаторе прописывает IP-адрес из этой подсети. Как правило, адреса .250-.254 резервируются для сетевых устройств Selectel, а адрес .254 служит шлюзом для попадания в другие локальные сети. На все устройства во всех дата-центрах прописывается маршрут:

route add 10.0.0.0 mask 255.0.0.0 gw 10.0.x.254

Где x — номер дата-центра. За счет этого маршрута серверы в дата-центрах «видят» друг друга по маршрутизации.


Наличие такого маршрута упрощает масштабирование схемы в случае, например, появления третьего дата-центра. Тогда для серверов в третьем дата-центре прописываются IP-адреса из следующего диапазона, 10.0.3.0/24, на маршрутизаторе — адрес 10.0.3.254.


Отличительной особенностью реализации такой схемы является то, что она не требует дополнительного резервирования на случай отказа дата-центра или внешних каналов связи. Так, например, при отказе дата-центра 1 целиком сохраняется связь между дата-центром 2 и дата-центром 3, а при реализации схемы с подачей L2 между дата-центрами через какой-то один из них, как на рисунке:


От работоспособности дата-центра 1 зависит связь дата-центра 2 и дата-центра 3. Или требуется организация дополнительных линков и использование сложных схем L2 резервирования. И при сохранении L2 схемы все равно вся сеть целиком очень чувствительна к некорректной коммутации, образованию петель коммутации, различным штормам трафика и иным неприятностям.

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


Резервирование маршрутизатора
Это все впечатляюще, но между проектами получается единая точка отказа — это маршрутизатор. Как быть в этом случае? На самом же деле, маршрутизатор не один. На каждый дата-центр выделяется два маршрутизатора, а для каждого заказчика они формируют Virtual IP .254 с использованием протокола VRRP.

Использование VRRP между двумя рядом стоящими устройствами, имеющими общий L2 сегмент, оправдано. Для дата-центров, разнесенных территориально, используются разные маршрутизаторы, а между ними организуется MPLS. Таким образом, каждый клиент, подключающийся к локальной сети по такой схеме, подключается в отдельный L3VPN, сделанный для него на этих MPLS-маршрутизаторах. И схема, в приближении к реальности, выглядит так:

Адрес шлюза для каждого сегмента .254 резервируется по VRRP между двумя маршрутизаторами.

Заключение
Обобщая все вышесказанное — изменение типа локальной сети с уровня L2 на уровень L3 позволило нам сохранить возможность масштабирования, увеличило уровень надежности и отказоустойчивости, а также позволило реализовать схемы дополнительного резервирования. Более того это позволило обойти существующие ограничения и «подводные камни» L2.

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

selectel.ru/services/dedicated-servers/

«Облако на базе VMware» в Москве и новые типы дисков, «Выделенные серверы» готовых конфигураций в дата-центре «Авиамоторная», CDN Selectel в коммерческой эксплуатации и еще много интересного



Итоги года
2018 год был насыщенным и продуктивным для Selectel. Мы открыли седьмой дата-центр — «Авиамоторная», впервые провели SelectelTechDay в Москве, запустили легко масштабируемое «Облако на базе VMware», «Облачный репозиторий Veeam Cloud Connect» для хранения резервных копий, комплекс услуг «Мультиоблачная среда» и внедрили бюджетную линейку серверов Chipcore с посуточной оплатой от 200 руб./день. На протяжении всего года мы улучшали панель управления, чтобы работать с ней было просто и понятно. Укрепляли партнерские отношения, впервые стали победителями «Премии Рунета» и заняли 2 место в рейтинге TAdviser самых зрелых российских провайдеров облачных услуг (по управляемости, безопасности и доступности сервисов). И это далеко не все наши достижения.
В 2019 мы не будем останавливаться на достигнутом, уверены, что новый год станет еще эффективнее и успешнее.

Новости услуг
Готовые конфигурации в «Авиамоторной»
В нашем новом московском дата-центре «Авиамоторная» стали доступны «Выделенные серверы» готовых конфигураций. Заказать сервер с нужными характеристиками вы можете в панели управления, локация «МСК-3». Он будет готов в течение 2-х часов после заказа.
selectel.ru/about/data-centers/?dedicatedab=true&location=aviamotornaya

НДС для Microsoft Azure и Office 365
С 1 января 2019 года покупка облачных сервисов Microsoft Azure и Office 365 облагается НДС 20%. Это связано с тем, что с нового года вступили в силу изменения в Налоговый кодекс РФ. Они распространяются на услуги в электронной форме, которые оказывают иностранные организации российским компаниям. Если у вас возникнут вопросы по нововведениям, свяжитесь с нами удобным способом: позвоните по телефону +7 (800) 555-06-750, напишите на sales@selectel.ru или обратитесь в техподдержку.

CDN Selectel в коммерческой эксплуатации
Мы внимательно относимся к вашей обратной связи: стараемся учитывать пожелания, чтобы сделать продукт еще лучше. В сентябре мы запускали открытое тестирование услуги CDN Selectel и давали вам возможность оценить ее функциональность. Спасибо всем, кто поделился обратной связью по итогам тестирования, мы учли ваши комментарии. Рады сообщить, что теперь услуга CDN Selectel введена в коммерческую эксплуатацию. Она подойдет компаниям, которые хотят ускорить доставку контента с наименьшими затратами на территории России, СНГ и Европы. А для тех, кто работает по всему миру, у нас по-прежнему есть CDN Akamai.
Подробнее с информацией об услуге и тарифах вы можете ознакомиться на сайте. Для заказа CDN Selectel доступна уже сейчас в панели управления.
selectel.ru/services/additional/cdn/

«Облако на базе VMware» в Москве и новые типы дисков
Мы запустили новый регион для «Облака на базе VMware» в Москве. Это значит, что вы можете выбрать ближайшую к офису или клиенту локацию, сэкономить на организации прямых каналов связи и уменьшить сетевые задержки между облаком и пользователями.
Кроме того, появилась возможность выбора пулов с нужным оборудованием и типами дисков, которые различаются по производительности операций ввода-вывода и цене.
Silver пул с процессорами Intel Xeon 6140 на базе гибридного vSAN, доступные типы дисков:

• vHDD до 150 IOPS
• Fast vHDD до 2,000 IOPS

Gold пул с процессорами Intel Xeon 6140 на базе All-Flash vSAN, доступные типы дисков:

• vSSD до 5,000 IOPs
• Fast vSSD до 25,000 IOPS

Узнать об услуге больше и ознакомиться с ценами вы можете на сайте. Создавайте виртуальные дата-центры в нужной локации, выбирайте политики хранения и управляйте своей облачной инфраструктурой из единой панели управления Selectel.
selectel.ru/services/cloud/vmware/

Новый раздел — «Мультиоблачная среда»
В панели управления появился новый раздел — «Мультиоблачная среда».

Вы можете выбрать наиболее подходящие для ваших бизнес-задач технологии и продукты, объединить ресурсы разных облачных провайдеров, дополнив их услугами Selectel. Заполните заявку, и специалисты Selectel свяжутся с вами для уточнения деталей.
my.selectel.ru/multicloud

Мероприятия

Southbridge проводит 3-дневный интенсив по Kubernetes в Санкт-Петербурге, где каждый участник создаст кластер и развернет в нем приложение. Selectel предоставляет облако для практики. Ждем вас 1–3 февраля в «Центре Событий» или на онлайн-занятиях. Регистрируйтесь, по промокоду Selectel скидка 3%.
slurm.io

Вебинар «Как создать чат-бота в Azure»
В начале декабря мы провели вебинар «Как создать чат-бота в Azure за 15 минут». Мы совместно проделали путь по развертыванию чат-бота от отправной точки в виде концепции до его эксплуатации с применением средств автомасштабирования.

Посмотрите вебинар в записи и узнайте о потенциальной экономии от внедрения чат-бота, особенностях его архитектуры в Azure и настройке сервисов IaaS.
www.youtube.com/watch?v=0vqZUZ3BlmE

Открыли первый митап сообщества AWS Rus
Докладом «DevOps and Serverless on AWS» инженер Selectel Никита Завьялов открыл первый митап сообщества AWS Rus в Москве. Он поделился кейсами внедрения AWS-сервисов и рассказал, почему использовать их в DevOps — это удобно.

Смотрите запись встречи, задавайте вопросы в комментариях или пишите на aws-sales@selectel.ru.
www.youtube.com/watch?v=uKu2GsqbNBg

И как аналогично меняется политика оплат Google, Netflix, Apple, Microsoft и всех других иностранных компаний, предоставляющих в России свои услуги онлайн. Так как Selectel является партнером многих из таких компаний, мы постарались досконально разобраться в вопросе.

По новому закону
С 1 января 2019 года вступили в силу изменения в налоговом законодательстве. Из самых громких — повышение ставки НДС с 18% до 20% и изменения в «законе на гугл»: теперь иностранная компания должна самостоятельно уплачивать НДС, если она оказывает на территории России услуги в электронной форме.

Ранее платить НДС иностранным компаниям нужно было только за конечных пользователей — физических лиц. Юридические лица и ИП сами выступали в роли налоговых агентов и уплачивали НДС самостоятельно.

Что такое услуги в электронной форме
Определение услуг в электронной форме предусмотрено пунктом 1 статьи 174.2 НК РФ. Это те сервисы, что предоставляются через интернет, например: виртуальный сервер, облачное хранилище, электронные книги, подписки на использование ПО, стриминговые сервисы, интернет-реклама и другое.

Примеры конкретных сервисов
Важно отметить: продукты компании Microsoft (например, Microsoft Office 365, Microsoft Azure) до 2019 года предоставлялись без НДС на территории РФ как лицензионные, однако с 01.01.19 данные продукты признаны как услуги в электронной форме и облагаются налогом в размере 20%.

На примере облачных сервисов AWS
Рассмотрим на примере Amazon Web Services, что означают для вас как для российских покупателей изменения закона с 1 января 2019. AWS (как и другие иностранные компании) предупредил о грядущих изменениях.




При оплате через Selectel
Если вы подумали: «При чем тут Selectel, вы же выделенные серверы продаете?», то, напомним, Selectel — партнер Amazon Web Services. То есть вы можете покупать услуги AWS, как и Microsoft Azure, Google Cloud и Alibaba Cloud, в рамках нашего решения «Мультиоблачная среда».

В таком случае вы получаете возможность:

• Оплачивать сервис через единую панель my.selectel.ru с расчетного счета фирмы в рублях
• Получить полный пакет подтверждающих документов
• Получать русскоязычную техническую поддержку 24/7
• Консультироваться у сертифицированных архитекторов
• Приобретать другие вычислительные ресурсы в «одном окне» и строить гибридные и мультиоблачные решения
• Возместить НДС из бюджета РФ

Если вы хотите оплачивать AWS через Selectel, оставьте заявку в панели или на странице «Мультиоблачная среда».

selectel.ru/services/cloud/multi-cloud/

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

DDoS-атаки (от англ. Distributed Denial of Service, распределенная атака типа «отказ в обслуживании») от недобросовестных конкурентов, криминальных структур или хулиганов — широко распространенная причина недоступности веб-ресурсов.

Количество атак постоянно растет, как и их разнообразие. По исследованиям Лаборатории Касперского, в сентябре 2018 года количество атак выросло в 5 раз по сравнению с сентябрем 2017 года.

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

Специалисты Selectel постоянно исследуют технологии защиты от кибератак с целью предложить клиентам лучшие решения. Мы уже не раз писали о защите от DDoS и даже объясняли, как она работает на примере симуляции атаки. В данной статье мы расскажем об оптимальных вариантах защиты для разных типов бизнеса.


Выбор метода защиты от DDoS
Большинство компаний не обладают специальными техническими средствами и экспертизой для самостоятельной защиты от DDoS-атак и используют решения профессиональных вендоров.

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

Линейка решений Selectel
Совместно с компаниями DDoS-Guard, Qrator и Incapsula, представляющими услуги защиты от DDoS-атак, мы предлагаем своим клиентам три варианта надежной защиты от DDoS-атак.

Базовая защита от DDoS
Услуга «Базовая защита» обеспечивает защиту от атак уровня L2 и L3, рассчитанных на перегрузку интернет-канала сайта, а также от атак уровня L7 при подключении услуги «Базовая защита приложения».
kb.selectel.ru/34539079.html
kb.selectel.ru/34539086.html

Важно помнить, что в случае подключения защиты L7 на сайт, использующий протокол HTTPS (от англ. HyperText Transfer Protocol Secure), возникает необходимость в передаче SSL-сертификата провайдеру услуг по защите от DDoS. Без клиентского SSL-сертификата невозможно фильтровать зашифрованный трафик.

Универсальная защита Qrator
«Универсальная защита Qrator» подходит для работы под постоянным воздействием значительного количества атак и обеспечивает защиту от большинства типов DDoS-атак, за исключением мультивекторных (изменяющихся с уровня L3 на уровень L7) и длительных (состоящих из множества маленьких, следующих непрерывно друг за другом) атак.
kb.selectel.ru/24383782.html

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

Комплексная защита Incapsula
«Комплексная защита Incapsula» также подходит для работы под большим количеством атак и предоставляет защиту от всех типов атак.
kb.selectel.ru/42085020.html

Использование решения Incapsula предотвращает взлом веб-сайтов и фильтрует спам в комментариях. Помимо этого, в решение Incapsula входят дополнительные функции:

• WAF — защитный экран для приложений, осуществляющих передачу данных через специальные протоколы НТТP/HTTPS, обеспечивающие взаимодействие сети и пользователя
• Защита доступа к административной панели сайта и корпоративным интернет-порталам компании, даже в случае, когда пароль администратора был украден, перехвачен или изменен злоумышленниками
• Глобальный CDN, который по умолчанию входит в состав услуги
• Поддержка широкого спектра методов распределения трафика, снижающая нагрузку на серверы, как в одном дата-центре, так и между разными дата-центрами

Подробнее blog.selectel.ru/zashhita-ot-ddos-ot-bazovoj-k-kompleksnoj/

selectel.ru/promo/wallarm-qrator/

В январе 2018 года количество бизнес-клиентов G Suite превысило 4 миллиона. В этой статье, сравнив возможности бесплатного Google Account и платного сервиса G Suite, попытаемся понять, почему компании от мала до велика переходят на платный набор офисных приложений в облаке от Google.

Запуск корпоративной почты занимает буквально 15 минут
Директор по контролю производства GoDaddy (второй в мире регистратор доменных имен) считает, что клиенты чаще работают с компаниями, у которых почтовый адрес выглядит корпоративно. При этом 80% представителей малого бизнеса используют в адресе домены типа @gmail.com.

Чтобы подключить корпоративный email в бесплатном аккаунте, нужны сторонние почтовые сервисы. В G Suite можно создать ящик вида [отдел]@[компания].com, при этом не придется покупать и настраивать специальные почтовые серверы.



Если компания использует домены помимо основного, они подключаются в G Suite:

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

Возможности бесплатных сервисов расширены — работать вместе стало еще удобнее
Существует три тарифа G Suite: Basic, Business, Enterprise — они отличаются набором функций и стоимостью от 400 до 2,000 рублей. Во все тарифные планы входят бесплатные облачные приложения Google (такие как документы, чаты, календари, диск) и инструменты управления аккаунтами через администратора G Suite. В тарифы Business и Enterprise входят платные сервисы «Сейф» и Cloud Search.

По сравнению с бесплатным аккаунтом, в G Suite становится проще работать вместе:



Более подробно рассказано тут blog.selectel.ru/zachem-platit-za-g-suite-esli-est-besplatnyj-google-account/

//
от редакции
Верстка не очень, копировать долго, информация не особо ценная для Истории рынка