Русский
Русский
English
Статистика
Реклама

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

Как ELK помогает инженерам по ИБ бороться с атаками на сайты и спать спокойно

22.10.2020 14:22:35 | Автор: admin
Наш центр киберзащиты отвечает за безопасность веб-инфраструктуры клиентов и отбивает атаки на клиентские сайты. Для защиты от атак мы используем файрволы веб-приложений FortiWeb (WAF). Но даже самый крутой WAF не панацея и не защищает из коробки от целевых атак.

Поэтому в дополнение к WAF мы используем ELK. Он помогает собирать все события в одном месте, копит статистику, визуализирует ее и позволяет нам вовремя видеть направленную атаку.

Сегодня расскажу подробнее, как мы скрестили ёлку с WAF и что из этого получилось.




История одной атаки: как все работало до перехода на ELK

В нашем облаке у заказчика развернуто приложение, которое стоит за нашим WAF. В день к сайту подключались от 10 000 до 100 000 пользователей, количество подключений доходило до 20 млн. в день. Из них 3-5 пользователей были злоумышленниками и пытались взломать сайт.

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

Куда сложнее бороться с медленными атаками, когда злоумышленники действуют не спеша и маскируются под обычных клиентов. Они используют много уникальных IP-адресов. Такая активность не выглядела для WAF как массовый брутфорс, отследить ее автоматически было сложнее. А еще был риск заблокировать нормальных пользователей. Мы искали другие признаки атаки и настраивали политику автоматической блокировки IP-адресов по этому признаку. Например, у многих нелегитимных сессий обнаруживались общие поля в заголовках http-запроса. Искать такие поля часто приходилось вручную в журналах событий FortiWeb.

Получалось долго и неудобно. В стандартной функциональности FortiWeb события записываются текстом в 3 разных журнала: обнаруженные атаки, информация о запросах и системные сообщения о работе WAF. За минуту могут приходить десятки, а то и сотни событий об атаках.

Не так уж и много, но приходится вручную лазить по нескольким журналам и перебирать много строк:


В журнале атак видим адреса пользователей и характер активности.

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


Выделенные поля помогают обнаружить медленную атаку. Источник: скрин с сайта Fortinet.

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

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

Из чего выбирали


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

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

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

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

Вот так мы и пришли к опенсорсу в лице ELK.

Почему выбрали ELK


ELK это комплекс программ с открытым кодом:

  • Elasticsearch база данных временных рядов, которая как раз создавалась для работы с большими объемами текста;
  • Logstash механизм сбора данных, который может конвертировать журналы в нужный формат;
  • Kibana хороший визуализатор, а также достаточно дружелюбный интерфейс для управления Elasticsearch. Можно с его помощью построить графики, за которыми могут наблюдать дежурные инженеры по ночам.

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

Как собрали это все в единую систему


Сформировали индексы и оставили только нужную информацию. Мы загрузили все три журнала FortiWEB в ELK на выходе получились индексы. Это файлы со всеми собранными журналами за период, например, сутки. Если бы мы сразу их визуализировали, то увидели бы только динамику атак. За подробностями нужно проваливаться в каждую атаку и смотреть конкретные поля.



Мы поняли, что для начала нужно настроить разбор неструктурированной информации. Взяли длинные поля в виде строк, например, Message и URL, и распарсили их, чтобы получить больше информации для принятия решений.
Например, с помощью парсинга мы вынесли отдельно местоположение пользователя. Это помогло сразу выделить атаки из-за рубежа на сайты для российских пользователей. Блокируя все подключения из других стран, мы уменьшили количество атак в 2 раза и могли спокойно разбираться с атаками внутри России.

После парсинга стали искать, какую информацию хранить и визуализировать. Оставлять в журнале все было нецелесообразно: размер одного индекса был большим 7 Гб. ELK требовалось много времени для обработки файла. При этом не вся информация была полезной. Что-то дублировалось и занимало лишнее место нужно было оптимизировать.

Сначала мы просто просматривали индекс и удаляли ненужные события. Это оказалось еще неудобнее и дольше, чем работа с журналами на самом FortiWeb. Единственный плюс от ёлки на этом этапе мы смогли визуализировать большой промежуток времени на одном экране.

Мы не отчаивались, продолжали есть кактус изучать ELK и верили, что сумеем вытянуть необходимую информацию. После очистки индексов начали визуализировать что есть. Так мы пришли к большим дашбордам. Понатыкали виджетов наглядно и нарядно, настоящая ЁLKа!



Зафиксировали момент атаки. Теперь нужно было понять, как на графике выглядит начало атаки. Для ее обнаружения мы смотрели на ответы сервера пользователю (return codes). Нас интересовали ответы сервера с такими кодами (rc):

Код (rc)
Название
Описание
0
DROP
Запрос к серверу блокируется
200
Ok
Запрос успешно обработан
400
Bad Request
Ошибочный запрос
403
Forbidden
Отказ авторизации
500
Internal Server Error
Сервис недоступен


Если кто-то начинал атаковать сайт, менялось соотношение кодов:

  • Если ошибочных запросов с кодом 400 становилось больше, а нормальных запросов с кодом 200 оставалось столько же, значит кто-то пытался взломать сайт.
  • Если при этом запросы с кодом 0 тоже росли, значит политики FortiWeb тоже видели атаку и применяли к ней блокировки.
  • Если увеличивалось количество сообщений с кодом 500, значит сайт недоступен для этих IP-адресов тоже своего рода блокировка.

К третьему месяцу мы настроили дашборд для отслеживания такой активности.



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

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

На мониторинге мы следили, как меняются графики разных цветов. Всплеск красного цвета показывал, что атака началась, а оранжевый и синий графики демонстрировали реакцию FortiWeb:


Тут все хорошо: был всплеск красной активности, но FortiWeb справился и график атаки сошел на нет.

Также мы нарисовали для себя пример графика, который требует вмешательства:


Здесь мы видим, что FortiWeb повысил активность, но красный график атаки не снизился. Нужно поменять настройки WAF.

Расследовать ночные инциденты тоже стало проще. На графике сразу видно момент, когда пора прийти на защиту сайта.


Вот что иногда происходит ночью. Красный график началась атака. Синий активность FortiWeb. Атака заблокировалась не до конца, пришлось вмешаться.

Куда стремимся


Сейчас мы обучаем дежурных администраторов работать с ELK. Дежурные учатся оценивать ситуацию на дашборде и принимают решение: пора эскалировать на специалиста по FortiWeb, или политик на WAF хватит для автоматического отражения атаки. Так мы снижаем нагрузку на инженеров ИБ по ночам и делим роли в поддержке на уровне систем. Доступ к FortiWeb остается только у центра киберзащиты, и только они вносят изменения в настройки WAF при острой необходимости.

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

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

Вот такие сценарии использования ёлки у нас накопились за последнее время. Делитесь своими идеями на этот счет и не забывайте правильно все настраивать, чтобы избежать утечек из баз данных.
Подробнее..

Перевод Мой восьмилетний квест по оцифровке 45 видеокассет. Часть 1

23.10.2020 12:08:13 | Автор: admin
За последние восемь лет я перевозил эту коробку с видеокассетами в четыре разные квартиры и один дом. Семейные видеозаписи из моего детства.



Спустя более 600 часов работы я, наконец, оцифровал и нормально их организовал, так что кассеты можно выбросить.

Вот как сейчас выглядит отснятый материал:




Все семейные видео оцифрованы и доступны для просмотра с приватного медиасервера

Получилось 513 отдельных видеоклипа. У каждого название, описание, дата записи, теги для всех участников с указанием возраста на момент записи. Всё лежит на приватном медиасервере, доступ к которому есть только у членов семьи, а хостинг стоит меньше 1 доллара в месяц.

Эта статья рассказывает обо всём, что я сделал, почему для этого понадобилось восемь лет и как добиться аналогичного результата гораздо проще и быстрее.

Первая наивная попытка


Примерно в 2010 году моя мама купила какой-то конвертер VHS в DVD и прогнала через него все наши домашние видео.


Оригинальные DVD, которые записала мама (не знаю, что случилось с пропавшими буквами)

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

В 2012 году сестра подарила мне эти DVD-диски. Я скопировал видеофайлы и выложил всё в облачное хранилище. Проблема решена!


DVD-рипы семейных видео в хранилище Google Cloud

Через несколько недель я спросил, смотрел ли кто эти записи. Оказалось, что никто не смотрел. Даже я не смотрел. В эпоху YouTube глупо скачивать трёхчасовые файлы неизвестного содержания в поисках интересных кадров.

Только моя мама обрадовалась: Отлично, сказала она, теперь можно, наконец, выбросить все эти кассеты?

Ой-ёй. Это страшный вопрос. А если мы пропустили какие-то записи? Что, если кассеты можно оцифровать с более высоким качеством? Что, если на этикетках важная информация?

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

Я даже не подозревал, во что ввязываюсь.

Звучит не так уж и сложно


Если вы не понимаете, почему это заняло у меня восемь лет и сотни часов, я вас не виню. Я тоже думал, что всё будет легко.

Вот как выглядит процесс оцифровки от начала до конца:



Точнее, так он выглядит в теории. Вот как получилось на практике:



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

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

Шаг 1. Захват видео


Ладно, вернёмся в 2012 год. Маме очень хотелось выбросить кассеты, которые она хранила двадцать лет, поэтому при первой встрече она сразу вручила мне огромную картонную коробку. Так начался мой квест по оцифровке.

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

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

Спойлер: это оказалось действительно трудно.

Первая попытка захвата видео


У отца всё ещё хранился старый семейный видеомагнитофон, поэтому я попросил к следующему семейному ужину откопать его из подвала. Я купил дешёвый адаптер RCA-USB на Amazon и приступил к делу.


Устройство захвата видео TOTMC, первое из множества устройств A/V, которые я купил во время многолетнего квеста

Для обработки видео с устройства захвата USB я использовал программу VirtualDub, версия 2012 года немного устарела, но не критично.


Кадры в программе VirtualDub, как я в возрасте четырёх лет читаю книгу своему отцу

Напасть с искажением звука


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

Через десять минут он снова рассинхронизировался. Разве я мало сдвинул его в первый раз?

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


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

Представляете, как трудно отличить звук на 10 миллисекунд раньше или на 10 миллисекунд позже? Это действительно трудно! Судить сами.

На этом видео я играю со своим бедным, терпеливым котёнком, которого звали Black Magic. Звук немного не синхронизирован. Определите, он опережает картинку или идёт с опозданием?


Пример видеоклипа с рассинхроном звука и картинки

В этом месте Black Magic прыгает, фрагмент с замедлением в пять раз:


Рассинхрон звука и картинки, замедление в пять раз

Ответ: звук идёт с опозданием в несколько миллисекунд.

Может, потратить лишнюю сотню долларов вместо сотен часов личного времени?


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


Моя вторая попытка приобрести устройство для видеозахвата

Даже с новым устройством рассинхрон никуда не исчез.

Видеомагнитофон с приставкой супер


Может, проблема в видеомагнитофоне. На форумах по оцифровке говорили, что рассинхрона не будет на видеомагнитофоне с корректором времени (time-based corrector, TBC), эта функция есть на всех видеомагнитофонах Super VHS (S-VHS).

Ну конечно! Зачем я возился с дурацким обычным видеомагнитофоном, когда есть супер-VCR, который решает проблему?

Никто уже не производит видеомагнитофоны S-VHS, но они по-прежнему доступны на eBay. За 179 долларов я купил модель JVC SR-V10U, которая вроде хорошо подходит для оцифровки VHS:


Винтажный видеомагнитофон JVC SR-V10U, который я купил на eBay за 179 долларов

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

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

Утомительный поиск, устранение неисправностей и многолетняя борьба


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

Вот мне попался случайный пост на форуме от 2008 года, где говорится об установке какого-то странного китайского драйвера без подписи Это ужасная идея, но я в отчаянии. Впрочем, он не помог.

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

Я неизменно сдавался, всё отключал и прятал оборудование в шкаф ещё на несколько месяцев.

Сдаёмся и отдаём кассеты профессионалам


Наступил 2018 год. Я перетаскал видеокассеты и тонны оборудования по четырём разных квартирам и собирался переехать из Нью-Йорка в Массачусетс. Я не мог найти силы снова их везти, потому что уже понял, что самостоятельно никогда не закончу этот проект.

Я спросил семью, можно ли отдать кассеты в фирму по оцифровке. К счастью, никто не возражал всем хотелось снова увидеть записи.

Я: Но это значит, что какая-то компания получит доступ ко всем нашим домашним видео. Тебя это устраивает?
Сестра: Да мне по барабану. Тебя одного это беспокоит. Погоди, так ты с самого начала мог просто заплатить кому-то?
Я: Э-э-э...

Оцифровка всех 45-ти кассет стоит $750. Кажется дорого, но к тому моменту я бы заплатил сколько угодно, лишь бы больше не разбираться с этим оборудованием.

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

Вот видео со сравнением профессиональной оцифровки и моих доморощенных попыток:


Сравнение профессиональной и самодельной оцифровки в видеоролике, где мама снимает мою первую попытку программирования

Шаг 2. Редактирование


В домашних съёмках около 90% материала скучны, 8% интересны, а 2% потрясающие. После оцифровки у вас ещё много работы.

Редактирование в Adobe Premiere


На кассете VHS длинный поток видеоклипов перемежается пустыми участками. Чтобы отредактировать ленту, вы должны определить, где начинается и заканчивается каждый клип.

Для редактирования я использовал Adobe Premiere Elements, которая стоит меньше $100 за пожизненную лицензию. Его важнейшая фича масштабируемая временная шкала. Она позволяет быстро найти границы сцены, а затем увеличить масштаб, чтобы найти точный видеокадр, где начинается или заканчивается клип.


Важнейшая временная шкала с масштабированием в Adobe Premiere Elements

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

  1. Открыть сырой файл, который содержит 30-120 минут видео.
  2. Отметить границы отдельного клипа.
  3. Экспортировать клип.
  4. Подождать 2-15 минут, пока завершится экспорт.
  5. Повторять шаги 2-4, пока не закончится лента.

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

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

Автоматизация редактирования


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

Я экспериментировал с инструментом под названием pyscenedetect, который анализирует видеофайлы и выдаёт временные метки, где происходят изменения сцены:

 $ docker run \    --volume "/videos:/opt" \    handflucht/pyscenedetect \    --input /opt/test.mp4 \    --output /opt \    detect-content --threshold 80 \    list-scenes[PySceneDetect] Output directory set:  /opt[PySceneDetect] Loaded 1 video, framerate: 29.97 FPS, resolution: 720 x 480[PySceneDetect] Downscale factor set to 3, effective resolution: 240 x 160[PySceneDetect] Scene list CSV file name format:  $VIDEO_NAME-Scenes.csv[PySceneDetect] Detecting scenes...[PySceneDetect] Processed 55135 frames in 117.6 seconds (average 468.96 FPS).[PySceneDetect] Detected 33 scenes, average shot length 55.7 seconds.[PySceneDetect] Writing scene list to CSV file:  /opt/test-Scenes.csv[PySceneDetect] Scene List:----------------------------------------------------------------------- | Scene # | Start Frame |  Start Time  |  End Frame  |   End Time   |----------------------------------------------------------------------- |      1  |           0 | 00:00:00.000 |        1011 | 00:00:33.734 | |      2  |        1011 | 00:00:33.734 |        1292 | 00:00:43.110 | |      3  |        1292 | 00:00:43.110 |        1878 | 00:01:02.663 | |      4  |        1878 | 00:01:02.663 |        2027 | 00:01:07.634 | ...

Инструмент действительно показал точность около 80%, но проверка его работы заняла больше времени, чем он сэкономил. Тем не менее, pyscenedetect сделал одно из самых важных открытий для всего проекта: определение границ сцены и экспорт клипов это отдельные задачи.

Я вспомнил, что я программист


До этого момента я считал редактированием всё, что делал в Adobe Premiere. Вырезание клипов из необработанных кадров казалось неразрывно связанным с поиском границ клипа, потому что именно так Premiere представлял эту задачу. Когда pyscenedetect распечатал таблицу метаданных, это заставило меня понять, что я могу отделить поиск сцен от экспорта видео. Это был прорыв.

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

Более того, электронные таблицы значительно расширили объём метаданных. Изначально я впихивал метаданные в название файла, но это их ограничивает. Наличие целой электронной таблицы позволило каталогизировать гораздо больше сведений о клипе, например, кто в нём присутствует, когда он записан и любые другие данные, которые я хочу показать во время демонстрации видео.


Гигантская электронная таблица с метаданными о моих домашних видео

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


Функциональность электронных таблиц позволяет записывать метаданные, которые дают больше информации о клипах и облегчают их просмотр

Успех автоматизированного решения


Имея электронные таблицы, я написал скрипт, который нарезал сырое видео на клипы на основе данных в CSV.

Вот запись как это выглядит в действии:



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

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

Часть 2


Оцифровка и редактирование видеоматериалов только половина дела. Нам ещё нужно найти удобный вариант публикации в интернете, чтобы все родственники смотрели семейное видео в удобном формате со стримингом как на YouTube.

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

P.S. От переводчика: Вторая часть выйдет сегодня во второй половине дня.



Подробнее..

Перевод Этапы внедрения CICD

28.10.2020 06:04:03 | Автор: admin


Jason Dorfman, MIT CSAIL


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


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


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


Непрерывная интеграция и непрерывная доставка охватывают культуру, набор эксплуатационных методов, а также объединенные принципы, помогающих ускорить процесс разработки ПО. Эта реализация также известна как конвейер CI/CD и считается передовым методом для команд DevOps.


Отраслевые эксперты говорят, что все больше компаний внедряют у себя CI/CD, поскольку ищут способы улучшения проектирования, разработки и поставки ПО, используемого для клиентов, или внутренних целей.


Мы определенно видим рост использования CI/CD. Я лично все время получаю вопросы насчет непрерывной разработки, тестирования и выпуска ПО. Последний опрос Gartner Agile in the Enterprise показал, что все больше команд переходят на гибкую разработку, поскольку гибкие команды имеют значительно более высокий уровень реализации непрерывной интеграции, автоматической приемки тестирования и DevOps. Я думаю, что CI самая главная точка отсчета для создания автоматических конвейеров, с нее команды обычно начинают работать. Более значимыми аспектами CD являются потребности в автоматическом тестировании и перепроектировании приложений, так что мелкие фрагменты функционала могут быть протестированы и выпущены по отдельности.
Sean Kenefick, вице-президент и аналитик в исследовательской компании Gartner

Практически все новые программные проекты, в которых участвует консалтинговая компания ServerCentral Turing Group, в той или иной степени используют CI/CD. Основными движущими силами при этом являются следующие вещи: отсутствие серверов в инфраструктуре требует интеграции CI/CD; требования безопасности нуждаются в ограничении доступа разработчиков к производственной инфраструктуре; гибкие методы требуют высокой скорости циклов развертывания и тестирования.
Josh Quint, старший директор по облачным решениям

CI/CD становится основной стратегией для многих компаний, связанных с разработкой.


Такие технические достижения, как непрерывная интеграция, комплексное автоматическое тестирование и непрерывная доставка, ранее освоенные модными стартапами, теперь успешно применяются и обычными предприятиями.
Hasan Yasar, технический директор в Software Engineering Institure при Carnegie Mellon University

Ниже перечислю несколько рекомендуемых методов реализации и обслуживания стратегии CI/CD.


Привлечение ключевых персон к CI/CD на ранних этапах


Желательно вовлечь в проект как можно раньше всех заинтересованных сотрудников. Основным преимуществом их участия будет быстрое и верное принятие решения о разработке проекта. Это должно происходить с участием всех заинтересованных сторон, чтобы основные решения могли приниматься с учетом мнения всех экспертов. Такая практика значительно снижает технический долг, накапливаемый на протяжении жизненного цикла проекта.
Hasan Yasar

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


Выбор и внедрение правильной системы CI/CD


Системы CI/CD, доступные на рынке, могут дать ощутимую ценность для компаний, а их применение в компании, занимающейся разработкой и выпуском ПО, свидетельствует о здоровье компании. Если сборка, тестирование и поставка новых функций становится тривиальной задачей способность компании реагировать на изменения значительно улучшается. Если нужно несколько недель или даже месяцев, чтобы сделать что-то для ваших клиентов придет кто-то другой, кто сможет сделать это лучше.
Josh Komoroske, старший инженер DevOps в StackRox, поставщике технологий безопасности контейнеров

Однако производителям нужно провести достаточно исследований, чтобы вникнуть в ПО, с которым можно построить процессы CI/CD.


Попросите ответственного за техническое направление, жизненный цикл и хорошее состояние продукта, выделить немного времени на исследование экосистемы и доступных решений. Запросите обратную связь от разработчиков этого продукта. Ведь они и есть основной заказчик системы CI/CD, поскольку работают с ней ежедневно.
Josh Komoroske

Как только компания выбрала какую-либо систему, нужно избежать проблемы неиспользования.


Большинство таких решений предлагают бесплатный ознакомительный период, могут внедряться вместе с другими платформами, например GitHub. Настройте совместную работу и начинайте что-нибудь собирать. Автоматизируйте сборку, тесты, поставку. Когда люди увидят. что такие системы дают ценности их рабочим процессам, они сразу же начнут переносить свои задачи в них.
Josh Komoroske

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


Непрерывная поставка основана на четырех главных частях:
  • Перепроектирование для разделения
  • Автоматизация тестирования
  • Создание автоматического конвейера для процесса
  • Автоматизация создания и настройки окружений
    Эти четыре компонента общие для всех, но есть много индивидуальных методов их реализации.
    Sean Kenefick

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


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

Удостоверьтесь, что есть ручные подтверждения на критических точках процесса поставки. Шаги с ручным подтверждением не будут давать непротестированному и неподтвержденному коду попасть в промышленное использование, либо в последующие тестовые окружения. Кроме того, у вас появляется возможность управления попадания кода в ключевые окружения.
Josh Quint

Отслеживание параметров обеспечения успешности работы CI/CD


CI/CD не работает в режиме поставил и забыл, который актуален для большинства других технологий и процессов.


Узнайте продолжительность и уровень стабильности циклов сборка/тестирование/поставка. Определите области и возможности для оптимизации. Быстро лучше, чем медленно, но надежность и правильность важнее скорости. Процессы CI/CD и связанные с ними инструменты следует рассматривать как усилители, позволяющие сократить время на разработку и тестирование, а также время вывода на рынок (TtM).
Josh Komoroske

Компании могут достичь ощутимых улучшений в разработке и проектировании при внедрении CI/CD, им следует измерять эти улучшения и делать сравнение производительности время от времени.


DevOps построен на обещании непрерывного обучения и улучшения, но этот момент упускает большинство команд на ранних этапах внедрения CI/CD. Необходимо анализировать данные, получаемые от инструментов CI/CD, чтобы определить ключевые показатели эффективности, цели производительности и аналитику, измеряемую на протяжении всего процесса DevOps.
Farid Roshan, глава Altimetrik, поставщика ПО для проектирования и совместной работы

Понимание движущих сил бизнеса для внедрения CI/CD, мысли о будущих потребностях


Важно понимать, почему действительно нужно внедрять CI/CD. Только в этом случае они смогут позволить своим командам разработчиков получить нужные навыки для достижения ключевых целей.


Если все сделано правильно, то CI/CD может улучшить продуктивность разработчиков, провести оптимизацию фреймворка для поставки, эксплуатационную эффективность и гибкую трансформацию. Первое поколение платформ CI/CD разработано в качестве сервиса оркестровки, соединяющего процессы жизненного цикла продукта для увеличения продуктивности. Однако такая платформа может и не дать высокого ROI, зависящего от времени, требуемого для написания кода. Современные возможности CI/CD добавили модульную архитектуру, с которой возможно реализовать подключение моделей на лету, а также настраиваемость конвейеров для поддержки различных фреймворков поставки.
Farid Roshan

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


Развивайте возможности CI/CD для целей вашего бизнеса. Внедрение DevOps CI/CD в отрыве от основы текущих процессов приведет к фрагментарному внедрению инструмента, отсутствию стандартизации, а также минимальному ROI при обеспечении гибкости доставки. Эта ошибка будет лавинной для бизнеса.
Farid Roshan

Автоматизация везде, где это возможно


Компании должны автоматизировать все, что можно автоматизировать в качестве части CI/CD, а также четко обозначить те вещи, которые не будут автоматизированы. Автоматизация один из столпов DevOps, наиболее ценная вещь, получаемая от реализации DevOps, делающая возможным CI/CD.
Hasan Yasar

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


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

От редакции: О внедрении CI/CD, приемах работы с Gitlab CI и лучших практиках построения пайплайна спикеры Слёрма говорят в практическом видеокурсе CI/CD на примере Gitlab CI. До 3 декабря 2020 курс доступен по цене предзаказа. Присоединяйтесь!

Подробнее..

Найди все сам как подбирать музыку для работы и отдыха без помощи рекомендательных систем

11.10.2020 16:06:58 | Автор: admin

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

Фотография: Edu Grande. Источник: Unsplash.comФотография: Edu Grande. Источник: Unsplash.com

Digital-выставки

На днях в одном из наших дайджестов мы прошлись по импровизированной онлайн-выставке аудиотехники: рассказали о новинках и интервью с разработчиками. Но в этом году на дистанционке почти все музыкальные фестивали. Весной в таком режиме провели SXSW и даже выложили плейлист из 747 композиций его участников на YouTube. Подборка новой музыки с феста на Spotify оказалась почти в два раза объемнее на 1359 песен, есть и версия плейлиста для Apple Music.

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

Кстати, в марте 2021 года SXSW мероприятие вновь пройдет в онлайне. [Если вы захотите узнать больше об истории фестиваля и его IT-составляющей, на Хабре есть отдельный пост.]

Лейблы и продюсеры

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

Фотография: Andreas Forsberg. Источник: Unsplash.comФотография: Andreas Forsberg. Источник: Unsplash.com

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

Близкая ниша для анализа участники ремикс-контекстов, которые часто проводят известные коллективы например, Клейтон Алберт (Klayton Albert), представляющий такие проекты как CelldwellerиScandroid.Он устраивает регулярные конкурсы для музыкантов на своем лейбле FiXT Music. Вот пример плейлиста с 70-ю треками участников одного из подобных контестов.

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

Карты микрожанров

Их преимущество в быстром переходе к изучению новых жанров. Если вам было бы интересно познакомиться с проектами из этой области, взгляните на Every Noise At Once. Достаточно определиться с выбором с помощью текстового поиска по странице (или вывести микрожанры в виде списка), послушать сэмпл и поискать что-то похожее в привычном стриминговом сервисе.

Изображение: DarTar. Источник: WikimediaИзображение: DarTar. Источник: Wikimedia

Еще один проект из этой области Music Map. [Пример карты исполнителей близких к Yelawolfу.]

Но его разработчик специализируется на поисковых и dicovery-задачах не только в музыкальной тематике. Похожей механикой обладает его второе детище Product Chart. Проект позволяет анализировать и сравнивать ноутбуки, смартфоны и разнообразное компьютерное железо. Еще автор этого музыкального навигатора предложил занимательную методику для тайм-трекинга.


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


Что еще у нас есть на Хабре:


Подробнее..

Непрошеные рекомендации зачем учиться искать музыку без помощи стриминговых сервисов

18.10.2020 12:20:24 | Автор: admin

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

Фотография: John Hult. Источник: Unsplash.comФотография: John Hult. Источник: Unsplash.com

Что-то пошло не так

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

На этом дело не ограничивается. Месяц назад в колонке для The New Yorker Алекс Росс (Alex Ross), известный критик и лауреат многочисленных премий в области музыкальной журналистики, сделал отсылку к книге Кайла Дивайна (Kyle Devine) под названием Decomposed. Она рассказывает о влиянии музыкальной индустрии, в том числе и стриминговых сервисов, на экологию и объясняет, как онлайн дистрибуция и многократное (повторное) скачивание треков наносит все более существенный ущерб окружающей среде, несравнимый даже с отходами от изданий на виниле и других носителях.

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

Фотография: Annie Spratt. Источник: Unsplash.comФотография: Annie Spratt. Источник: Unsplash.com

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

Старый, но хрестоматийный пример не самого удачного PRа в контексте этой статьи рассказ директора одной из таких компаний о наиболее востребованных треках в ванной комнате.

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

Последние зачастую не видят новые треки только потому, что те не попадают в нужную категорию. Известные примеры таких ситуаций кейсы легендарной Old Town Road и музыки Нью-Мексико.

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

Фотография: Brett Jordan. Источник: Unsplash.comФотография: Brett Jordan. Источник: Unsplash.com

Сам себе куратор

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

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

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

Может ли стриминговый сервис знать ваши музыкальные предпочтения лучше чем друг? Многим казалось, что эту задачу уже решили десять лет назад, но стоит признать, что сегодня вопрос вновь открыт. Пока это так, стоит самостоятельно пользоваться всеми доступными средствами.

Фотография: Artificial Photography. Источник: Unsplash.comФотография: Artificial Photography. Источник: Unsplash.com

Почему это важно

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

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

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


Что еще мы разбираем на Хабре:


Подробнее..

Как устроен Kubernetes as a Service на платформе Mail.ru Cloud Solutions

28.10.2020 14:12:50 | Автор: admin

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

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). Сегодня я расскажу, что под капотом у нашего Kubernetes aaS, как обеспечивается его надёжность и какие у него есть интересные функциональности, которыми любят пользоваться наши клиенты. Это автомасштабирование, интеграция с другими PaaS нашей платформы и многое другое.

Главные фичи Kubernetes на платформе MCS


Наш Kubernetes aaS включает:

  • Интерфейс управления для создания кластера в несколько кликов, масштабирования и настройки.
  • Автоматическое масштабирование узлов кластера в большую или меньшую сторону, то есть добавление или удаление нод (Cluster Autoscaler).
  • Встроенный мониторинг на основе Prometheus Operator и Grafana. Многие наши пользователи начинают с базовых инсталляций, где запускается приложение. Когда оно выходит в продуктив, это позволяет им мониторить сервисы и сам кластер.
  • Свой Terraform-провайдер для Kubernetes. Он полностью поддерживает API MCS.
  • Интеграция с Docker Registry для хранения и управления образами.
  • Автоматизированное развёртывание федеративных кластеров Kubernetes на базе AWS и Mail.ru Cloud Solutions (о чём мы писали тут).
  • Возможность сделать Start/Stop для кластера целиком экономия для тестовых сред. Вы можете выключить кластер одним кликом в интерфейсе и платить только за диски в случае остановленных кластеров.
  • Поддержка создания Node Pools, пулов виртуальных машин разных размеров: можно запускать тяжелые задачи на больших машинах, веб-приложения на маленьких. Масштабировать группы можно независимо и размещать их в разных регионах либо зонах доступности (для большей надежности и доступности).
  • Persistent Volumes интегрированы с системой хранения OpenStack.
  • Поддержка приватных кластеров, доступных только через VPN-соединение.
  • Поддерживается Cluster Policy: Local, которая позволяет получать реальные IP пользователей внутри кластеров.
  • Создание и масштабирование кластеров Kubernetes с помощью UI или API MCS, управление сущностями через Kubernetes dashboard и kubectl.
  • Плавное обновление (rolling update) в один клик без простоя как для минорных, так и для мажорных версий. Обновления кластеров до 1.16.
  • На момент написания статьи мы поддерживаем Kubernetes вплоть до версии 1.17.




Создание кластера Kubernetes в несколько кликов

Дальнейшее развитие сервиса:

  • CI/CD aaS, интегрированный с Kubernetes и другими сервисами платформы: дополнительные сервисы, которые обеспечивают CI/CD, на базе наших собственных доработок OpenStack.
  • Логирование aaS для приложений приложений, которые работают в нашем Kubernetes. Логирование будет реализовано на базе нескольких решений OpenStack.
  • Service mesh: у нас появятся плагины для Kubernetes, которые в рамках реализации service mesh будут выполнять шифрование, бэкапирование и другие функции.

Сертификация дистрибутива в Cloud Native Computing Foundation


Mail.ru Cloud Solutions входит в CNCF (Cloud Native Computing Foundation). Дистрибутив Kubernetes от MCS получил сертификат Certified Kubernetes Hosted. Его проверили на надежность и соответствие стандартам, он отвечает всем функциональным требованиям сообщества и совместим со стандартным Kubernetes API. MCS пока единственный в России облачный провайдер, получивший такую сертификацию.

Место Kubernetes в инфраструктуре облачной платформы


Самый нижний слой типовые физические серверы (compute nodes). Сейчас их несколько тысяч, они используются под вычисления и хранение. Для хранения мы предоставляем файловые и блочные хранилища на базе Ceph и S3-совместимые объектные хранилища. Серверы распределены по дата-центрам, между которыми проложена сеть 40 Gbps.

Поверх уровня серверов работает OpenStack, который обеспечивает виртуализацию для пользовательских окружений. А уже поверх виртуальных машин, сетей и балансировщиков работают PaaS-решения: Kubernetes, базы данных, DWH на базе ClickHouse, Hadoop, Spark и другие.

Аналогичную схему мы строим и в приватных инсталляциях Kubernetes как сервиса в дата-центрах наших заказчиков в формате частного облака.



Архитектура облачной платформы

Интеграция Kubernetes с облаком не односторонняя. Kubernetes не просто развертывается на виртуальных машинах, он полностью интегрируется с IaaS OpenStack.

На основе провайдера Cloud Provider OpenStack мы сделали Cloud Provider для MCS, который в рамках вашего проекта (тенанта) OpenStack соединяется с API MCS и создает, конфигурирует, удаляет диски, балансеры, внешние IP-адреса, подключает их к нодам Kubernetes, конфигурирует security-группы (фактически виртуальный firewall). Без Cloud Provider создание тех же Persistent Volumes головная боль для всех, кто запускает Kubernetes on-premise, на железе либо просто в облаке.



Интеграция Kubernetes с IaaS OpenStack

Какие инструменты мы используем


  1. Операционная система. Сначала мы использовали CoreOS, которая работает на хостах, сейчас у нас Fedora Atomic (1.14-1.15) и CentOS (1.16).
  2. Сеть Calico. Сети Kubernetes зависят от облачной сети, которая обеспечивается SDN всего облака. В основе нашей SDN изначально был OpenStack Neutron. Но год назад мы начали разработку модуля Sprut нашего собственного SDN-решения, которое поддерживает API Neutron, но работает по другим принципам. Подход Sprut решил наши проблемы масштабируемости, возникающие из-за десятков тысяч сетевых сущностей (портов) у нас в облаке, когда при падении сетевых нод в сети такого размера начинался процесс полной синхронизации (fullsync). Сейчас Sprut мы задействуем для тех клиентов, для которых в силу особенностей нагрузки на сеть использовать его целесообразнее, чем Calico, в перспективе мы его откроем для всех.
  3. Кластерный DNS на базе CoreDNS, со всеми его Service Discovery, метриками Prometheus и другими стандартными фичами.
  4. Ingress Controller. Сейчас это Nginx, но мы также планируем добавить Envoy, как дополнительный Ingress Controller. Наши тесты показывают, что Envoy часто быстрее. Ingress Controller интегрирован с облачным балансировщиком нагрузки на базе OpenStack Octavia и поддерживает Proxy Protocol.
  5. Мониторинг на базе Prometheus Operator. Раньше использовали просто Prometheus, но сейчас все хотят автоматизацию и сервис-мониторы, поэтому мы уже несколько месяцев предлагаем Prometheus Operator + Grafana, в рамках которой можно добавлять сервис-мониторы и выполнять мониторинг кластеров.
  6. Аддоны (опциональные расширения). В один клик можно установить Docker registry, интегрированный с нашим S3-хранилищем, ingress controller, различные системы мониторинга (Heapster, Prometheus).

Multi Master и сетевая топология


Kubernetes от Mail.ru поддерживает деплой в формате Multi Master, при этом каждая пользовательская группа нод уже находится в конкретной зоне доступности.


Multi Master в облаке

В Multi Master etcd работает в кластерном режиме, так что если что-то случается с одним из мастеров, другие продолжают работать. Под каждый etcd выделен отдельный SSD-диск, что обеспечивает хороший latency и быструю работу API-сервера, т.к. в etcd находится служебная информация о всех ресурсах кластера Kubernetes.

Для доступа извне используется балансировщик нагрузки API сервера Kubernetes, который имеет внешний IP-адрес. При этом все ноды и мастера, и миньоны находятся в приватной сети (фактически в виртуальном частном облаке) и не имеют публичных адресов.

Доступ к кластеру Kubernetes из публичной сети: запуск трафика и балансировка нагрузки


В общем случае способы доступа к сервисам внутри кластера перечислены здесь. Подробности нашей реализации:

NodePort открывает публичный порт на ноде. Однако есть ограничение: в целях безопасности по умолчанию публичные IP-адреса не установлены ни на мастера, ни на миньоны, кластеры создаются без белых IP-адресов. Пользователь может их сам установить.

Load Balancer. Наш Kubernetes интегрирован с облачной платформой MCS, так что платформа предоставляет Load Balancer как сервис и может сама создавать балансировщики. Для сравнения, если пользователь настраивает Kubernetes (например, в он премисе), нужно самостоятельно поднимать и настраивать софтверные балансеры. На платформе MCS балансировщики поднимаются сразу в отказоустойчивом режиме active-standby. Когда поднимается основной балансер (на HAProxy), у него всегда есть standby, спящий балансер. Между ними настроен VRRP. Если основной балансер отказывает, весь трафик мгновенно переключается на standby, при этом IP-адрес не меняется.



Отказоустойчивый Load Balancer как сервис на платформе MCS. Kubernetes создаёт nodeport на каждой ноде и балансировщик

В настройке балансировки для Kubernetes помогает наш Cloud Provider. Нужно создать манифест, в котором пользователь указывает тип манифеста сервис и тип сервиса Load Balancer. После деплоя этого манифеста Kubernetes (точнее, Cloud Provider, который работает в Kubernetes) обращается к OpenStack API, создаёт балансировщик и внешний IP-адрес, если это необходимо. Если внешний адрес не нужен, нужно поставить аннотацию, что требуется внутренний балансировщик, и можно пускать трафик на кластер, не открывая публичный IP-адрес на каждой ноде.

apiVersion: v1kind: Servicemetadata:name: nginxlabels:  k8s-app: nginx-backend annotations:  service.beta.kubernetes.io/openstack-internal-load-balancer:"true"spec: type: LoadBalancer externalTrafficPolicy: Cluster selector:  k8-app: nginx-backend ports: -port: 80  name: http  targetPort: http -port: 443  name: https  targetPort: httpn

Сервисный манифест для создания балансировщика нагрузки с помощью Cloud Provider

Не всегда удобно создавать по балансеру на каждый сервис, 10 сервисов есть 10 балансировщиков, 50 сервисов 50 балансировщиков. Ими потом также приходится управлять, это тяжелые сущности. Эту проблему решает Ingress.

Ingress. Чтобы можно было не создавать много балансировщиков, мы добавили поддержку Ingress Controller. Ingress Controller интегрирован с балансировщиком OpenStack. То есть в декларации сервиса конкретного Ingress Controller указан тип Load Balancer. Для кластера создается один балансировщик, по которому Ingress Controller работает и дальше распределяет трафик по сервисам. Ingress Controller балансирует по DNS-именам.



Схема работы Ingress

Для некоторых клиентов было важно, чтобы в подах было видно IP-адреса клиентов, получающих доступ в кластер. При балансировке теряются заголовки IP-пакетов: приложение не получает реальный IP-адрес клиента. Балансировщик OpenStack ещё видит заголовок X-Forwarded-For, но Ingress Controller и под его уже не получают. Это не позволяет настроить доступ пользователей по White Lists, не работают сервисы типа GeoIP или anti-DDoS, которым нужно видеть реальные IP-адреса клиентов.



IP-адрес клиента не доходит до пода

И здесь у нас оказалось два решения:

Сделать режим proxy-протокола как в Amazon. Ради этой возможности мы перешли на балансировщик OpenStack Octavia, так как в стандартном балансировщике OpenStack нет такой опции. В итоге мы сделали новый балансировщик, который поддерживал как TCP-балансировку, так и HTTP с терминацией SSL.

При этом поддержку proxy-протокола нужно включать как на самом балансировщике (HAproxy), так и на Nginx Ingress Controller, который выступает таким приемником. Иначе схема пропускания трафика ломается. Также важно, что SSL-терминация, если у вас стандартный веб-трафик, должна проходить на Ingress:



Терминация SSL на балансировщике. Здесь на балансер приходит HTTPS, он расшифровывается, и в кластер идет HTTP. Если всё это сделать и активировать в сервисе ExternalTrafficPolicy: Local, вы будете видеть заголовки IP-пакетов:



Storage и Kubernetes


Если разворачивать Kubernetes локально или в облаке просто на виртуальных машинах, то по умолчанию в нем нет нормальной работы с постоянными дисками. Можно использовать Host Path, Local volume (no-provisioner), либо прямо в кластере Kubernetes разворачивать экзотические программно-определяемые системы хранения типа Linstor или OpenEBS. Но что произойдет с данными или очередью данных, которая размещается в кластере, если умрет нода или под?

При самостоятельном подключении блочных устройств к кластеру есть проблемы: CSI-драйверы не идеальны для многих типов стораджей, и автоматическое перемонтирование может не произойти. Мы сделали работу с блочными устройствами автоматизированной. Чтобы при отключении пода блочное устройство переподключалось к новому поду само.

Мы используем Ceph. Главное, что они работают через OpenStack, который предоставляет специальные модули, абстрагирующие Kubernetes (или любые виртуальные машины, работающие в облаке), на конкретных драйверах OpenStack Cinder.

У нас несколько разных storage-классов, которые работают в Kubernetes: SSD Ceph, HDD Ceph, геораспределенные Ceph между нашими ЦОДами. Есть storage-класс, отвечающий за блочные диски: фактически это дисковые шкафы с SSD, они подключаются к хост-машинам по iSCSI.



Несколько Storage-классов в MCS

При необходимости мы используем NFS, когда клиенты не могут переписать приложения в микросервисную архитектуру. У нас есть аналог сервиса EFS от Amazon файловое хранилище с NFS-протоколом, доступное как сервис. Оно подходит, если у вас legacy-приложение, которое вы переводите в Kubernetes.

Кроме того, у нас есть локальные SSD, но здесь сложно гарантировать их доступность и переезд данных, поскольку они доступны только с физических серверов, к которым подключены.

Всё это подключается через единый модуль OpenStack OpenStack Cinder, к каждой ноде Kubernetes и обеспечивает возможность переезда стораджа в случае падения ноды. А также когда повышается нагрузка чтения/записи и Kubernetes решает перевозить неважные поды на другие ноды тогда он автоматически переводит монтирование этого диска к другим Kubernetes-нодам.



Так происходит автоматическое перемонтирование

Можно использовать storage class, написав декларации PersistentVolumeClaim. На примере, который изображён ниже, Cloud Provider выделит в заданной зоне доступности новый Persistent Volume, размером 30 ГБ с типом диска SSD, подключит его к ноде и примонтирует к подам. Также он будет следить, чтобы этот диск переезжал между нодами в случае переезда подов:

kind: PersistentVolumeClaimapiVersion: v1metadata: name: nginx-pvc-ssdspec: accessModes: -ReadWriteOnce storageClassName: dp1-ssdresources: requests:  storage: 30Gi


Автоматическое масштабирование


В MCS есть Cluster Autoscaler. Это не просто автоскейлинг подов внутри кластера, а автоскейлинг самого кластера по необходимости: новые ноды добавляются, когда нагрузка выросла, и удаляются, если нагрузка упала. Масштабирование происходит автоматически до 100 узлов и обратно за несколько минут.

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

Cluster Autoscaler лучше настраивать совместно с Horizontal Pod Autoscaler. Различие использования двух вариантов Autoscaler:

  • Cluster Autoscaler позволяет расширять сами выделенные для кластера ресурсы. По сути он может автоматически арендовать дополнительные ресурсы или сократить их использование через Cloud Provider.
  • Horizontal Pod Autoscaler позволяет расширять ресурсы подов в рамках существующих выделенных ресурсов кластера, чтобы оптимально их использовать.




Настройка автоскейлинга

Функциональности


Совместимость со стандартными инструментами Kubernetes


Так как наш Kubernetes aaS полностью совместим со стандартным Kubernetes API, вы можете свободно пользоваться всеми возможностями экосистемы Kubernetes.

  • Хранение и обработка serverless-функций в контейнерах: OpenFaaS, OpenWhisk, Kubeless.
  • Инструменты Service Mesh: Istio, Consul, Linkerd.
  • Мониторинг, аналитика, логирование: Prometheus, Fluentd, Jaeger, OpenTracing.
  • CI/CD: Gitlab, CircleCI, Travis CI.
  • IaC (описание приложений): Terraform, Helm.

И многие другие инструменты.

Про Terraform отдельно стоит сказать, что стандартный провайдер OpenStack не был полностью совместим с API платформы MCS, так что мы сделали собственный Terraform-провайдер, который полностью совместим с последней версией API MCS. Поддержка API включает:

  • листинг ресурсов MCS (cluster, cluster template, node group)
  • поддержку managed node groups
  • поддержку действий через API: создание/удаление, горизонтальное и вертикальное масштабирование, включение/выключение кластера, обновление версии.


Безопасность


  • Kubernetes использует аутентификацию по сертификатам.
  • Систему безопасности кластеров можно интегрировать с LDAP/Active Directory для аутентификации пользователей. При этом ролевую модель безопасности в Kubernetes можно настроить на проверку прав доступа на основе принадлежности пользователя к группам в LDAP-каталоге.
  • Для сетевой безопасности можно применять Calico Network Policy.
  • В наш Kubernetes aaS интегрирован Docker Registry, защищённый SSL.
  • Планируем реализовать SSO (single sign-on) в интеграции с нашим IAM (identity and access management) на уровне OpenStack.

Резервное копирование и миграция


  • Мы поддерживаем интеграцию с Velero. Velero выполняет резервное копирование, которое позволяет бэкапить манифесты etcd и Persistent Volumes, вот гайд по тому, как это сделать.
  • Также с помощью Velero можно мигрировать кластеры on-premises и других провайдеров на наш Kubernetes.
  • Или запросите миграцию на наш Kubernetes под ключ. Поможем.

Работа с большими данными


Kubernetes по сути можно использовать для любых микросервисных приложений, работающих с данными. Чем Kubernetes на платформе MCS интересен для data scientistов:

  • Автомасштабирование позволяет выдерживать большие вычислительные нагрузки.
  • Можно создавать событийные (event-triggered) обработчики данных.
  • Приложения на Kubernetes легко интегрировать с другими нашими PaaS для Big Data, машинного обучения, в рамках одной сети.
  • Если хочется поэкспериментировать, то для ускорения обучения к очереди событий или событийному обработчику на базе Kubernetes можно напрямую подключить GPU.

Ещё о нашем Kubernetes aaS


  1. Попробовать бесплатно наш Kubernetes aaS можно тут.
  2. В этих двух Telegram-каналах вас ждут новости нашего Kubernetes aaS и анонсы мероприятий @Kubernetes meetup.
Подробнее..

Развертывание офисных рабочих мест ZextrasZimbra в Яндекс.Облако

08.10.2020 16:23:54 | Автор: admin
Введение

Оптимизация офисной инфраструктуры и развертывание новых рабочих мест серьезная проблема для компаний всех типов и размеров. Оптимальным вариантом для нового проекта является аренда ресурсов в облаке и приобретение лицензий, которые можно использовать как у провайдера, так и в собственном ЦОД. Одним из решений для такого сценария является Zextras Suite, который позволяет создать платформу для совместной работы и корпоративных коммуникаций предприятия как в облачной среде, так и на своей инфраструктуре.



Решение рассчитано на офисы любого размера и имеет два основных сценария развёртывания: при наличии до 3000 тысяч почтовых ящиков и отсутствии высоких требований к отказоустойчивости, можно использовать установку в варианте single-server, а вариант установки multi-server поддерживает надежную и отзывчивую работу десятков и сотен тысяч почтовых ящиков. Во всех случаях пользователь получает доступ к почте, документам и сообщениям через единый веб-интерфейс с рабочего места с любой ОС без установки и настройки дополнительного ПО, или через мобильные приложения для iOS и Android. Возможно использование привычных клиентов Outlook и Thunderbird.

Для развертывания проекта партнер Zextras SVZ выбрал Яндекс.Облако, т.к. его архитектура аналогична AWS и имеется поддержка S3 совместимого хранилища, что позволит удешевить стоимость хранения большого объема почты, сообщений и документов и повысит отказоустойчивость решения.

В среде Яндекс.Облако для установки single-server используются базовые средства управления виртуальными машинами Compute Cloud и возможности управления виртуальными сетями Virtual Private Cloud. Для multi-server инсталляции в дополнение к указанным средствам необходимо использовать технологии Групп размещения, при необходимости (в зависимости от масштаба системы) также и Instance Groups, и сетевой балансировщик Yandex Load Balancer.

S3-совместимое объектное хранилище Yandex Object Storage может использоваться в обоих вариантах инсталляции, а также может быть подключено к системам, развёрнутым on-premise для экономного и отказоустойчивого хранения данных почтового сервера в Яндекс.Облаке.

Для single-server инсталляции, в зависимости от количества пользователей и/или почтовых ящиков, требуется: для основного сервера 4-12 vCPU, 8-64 GB vRAM (конкретные значения vCPU и vRAM зависят от количества почтовых ящиков и фактической нагрузки), не менее 80 GB диска для операционной системы и приложений, а также дополнительное дисковое пространство для хранения почты, индексов, логов и т.п., зависящее от количества и среднего размера почтовых ящиков и которое может динамически изменяться во время эксплуатации системы; для вспомогательных серверов Docs: 2-4 vCPU, 2-16 GB vRAM, 16 GB дискового пространства (конкретные значения ресурсов и количество серверов зависят от фактической нагрузки); дополнительно может потребоваться сервер TURN/STUN (его необходимость как отдельного сервера и ресурсы зависят от фактической нагрузки). Для multi-server инсталляций количество и назначение ролевых виртуальных машин и выделяемые им ресурсы определяются индивидуально в зависимости от требований пользователя.

Цель статьи

Описание развертывания в среде Яндекс.Облако продуктов Zextras Suite на базе почтового сервера Zimbra в варианте установки single-server. Полученная инсталляция может быть использована в продуктивной среде (опытные пользователи могут сделать необходимые настройки и добавить ресурсы).

В состав системы Zextras Suite/Zimbra входят:
Zimbra- корпоративная электронная почта с возможностью делиться почтовыми ящиками, календарями и списками контактов (адресными книгами).
Zextras Docs- встроенный офисный пакет на базе LibreOffice online для создания и совместной работы с документами, таблицами, презентациями.
Zextras Drive индивидуальное файловое хранилище, позволяющее редактировать, хранить и делиться с другими пользователями файлами и папками.
Zextras Team мессенджер с поддержкой аудио- и видеоконференций. Доступны версии Team Basic, позволяющая только коммуникации 1:1, и Team Pro, поддерживающая многопользовательские конференции, каналы, возможность демонстрации экрана, обмена файлами и другие функции.
Zextras Mobile поддержка мобильных устройств через Exchange ActiveSync для синхронизации почты с мобильными устройствами с функциями управления MDM (Mobile Device Management). Позволяет использовать Microsoft Outlook в качестве почтового клиента.
Zextras Admin реализация мультитенантного администрирования системы с делегированием администраторов для управления группами клиентов и классами сервисов.
Zextras Backup-резервирование и восстановление данных полного цикла в режиме реального времени
Zextras Powerstore- иерархическое хранилище объектов почтовой системы с поддержкой классов обработки данных, с возможностью хранения данных локально или в облачных хранилищах архитектуры S3, включая Yandex Object Storage.

По окончании установки пользователь получает работающую в среде Яндекс.Облако систему.

Условия и ограничения

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

2) Для упрощения установки не рассматривается использование управляемого администратором DNS сервера для разрешения внутренних (непубличных) доменных имён, используется стандартный DNS-сервер Яндекс.Облака. При использовании в продуктивной среде рекомендуется использовать DNS-сервер, возможно уже есть в корпоративной инфраструктуре.

3) Предполагается, что используется учётная запись в Яндекс.Облако с настройками по умолчанию (в частности, при входе в Консоль сервиса существует только каталог (в списке Доступные облака под именем default). Пользователи, знакомые с работой в Яндекс.Облако, могут по своему усмотрению, создать отдельный каталог для тестового стенда, или использовать существующий.

4) У пользователя должна быть публичная зона DNS, к которой у него должен быть административный доступ.

5) У пользователя должен быть доступ к каталогу в Консоли Яндекс.Облако по крайней мере с ролью editor (у Владельца облака все необходимые права есть по умолчанию, для предоставления доступа другим пользователям к облаку есть руководства:
https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy, https://cloud.yandex.ru/docs/resource-manager/operations/folder/set-access-bindings, https://cloud.yandex.ru/docs/iam/concepts/access-control/roles)

6) В данной статье не описывается установка пользовательских X.509 сертификатов, используемых для защиты сетевых коммуникаций посредством механизмов TLS. По окончании установки будут использованы самоподписанные сертификаты, что позволяет использовать браузеры для доступа к установленной системе. Они как правило выводят уведомление об отсутствии у сервера верифицируемого сертификата, но позволяют продолжить работу. До установки верифицируемых клиентскими устройствами сертификатов (подписанных публичными и/или корпоративными удостоверяющими центрами) с установленной системой могут не работать приложения для мобильных устройств. Поэтому установка указанных сертификатов в продуктивной среде необходима, и производится после завершения теста в соответствии с корпоративными политиками безопасности.

Описание процесса инсталляции системы Zextras/Zimbra в варианте single-server

1. Предварительная подготовка

Перед началом установки необходимо обеспечить:
а) Внесение изменений в публичную DNS зону (создание A-записи для сервера Zimbra и MX-записи для обслуживаемого почтового домена).
б) Настройку виртуальной сетевой инфраструктуры в Яндекс.Облако.

При этом, после внесения изменений в зону DNS, необходимо некоторое время на распространение этих изменений, но, с другой стороны, нельзя создать A-запись, не зная IP-адреса, с ней связанного.

Поэтому действия производятся в следующей последовательности:

1. Зарезервировать публичный IP-адрес в Яндекс.Облако
1.1 В Консоли Яндекс.Облака (при необходимости выбрав каталок в доступные облака) зайти в раздел Virtual Private Cloud, подраздел IP-адреса, после чего нажать кнопку Зарезервировать адрес, выбрать предпочитаемую зону доступности (или согласиться с предлагаемым значением; эта зона доступности впоследствии должна использоваться для всех описываемых в дальнейшем действий в Яндекс.Облако, если на соответствующих формах есть возможность выбора зоны доступности), в открывшемся диалоговом окне, при желании можно, но не обязательно, выбрать опцию Защита от DDoS, и нажать кнопку Зарезервировать (см. также документацию).



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



1.2 В прямой зоне DNS сделать A-запись для сервера Zimbra, указывающую на выделенный ранее IP-адрес, A-запись для сервера TURN, указывающую на тот же самый IP-адрес, и MX-запись для обслуживаемого почтового домена. В нашем примере это будут mail.testmail.svzcloud.ru (сервер Zimbra), turn.testmail.svzcloud.ru (сервер TURN), и testmail.svzcloud.ru (почтовый домен) соответственно.

1.3 В Яндекс.Облако в выбранной зоне доступности для подсети, которая будет использоваться для развёртывания виртуальных машин, включить NAT в Интернет.
Для этого в разделе Virtual Private Cloud, подраздел Облачные сети, выбрать соответствующую облачную сеть (по умолчанию там доступна только сеть default), в ней выбрать соответствующую зону доступности и в её настройка выбрать пункт Включить NAT в интернет.



Статус изменится в списке подсетей:



Подробнее см. в документации https://cloud.yandex.ru/docs/vpc/quickstart и https://cloud.yandex.ru/docs/vpc/concepts/network.

2. Создание виртуальных машин
2.1. Создание виртуальной машины для Zimbra
Последовательность действий:
2.1.1 В Консоли Яндекс.Облака зайти в раздел Compute Cloud, подраздел Виртуальные машины, нажать кнопку Создать ВМ (подробнее о создании ВМ см. документацию).



2.1.2 Там необходимо задать:
  • Имя произвольно (в соответствии с поддерживаемым Яндекс.Облаком форматом)
  • Зона доступности должна соответствовать ранее выбранной для виртуальной сети.
  • В Публичные образы выбрать Ubuntu 18.04 lts
  • В дисках установить загрузочный диск размером не менее 80ГБ. Для тестовых целей достаточно типа HDD (и также для продуктивного использования при условии вынесения некоторых типов данных на диски типа SSD). При необходимости дополнительные диски можно будет добавить после создания ВМ.

В вычислительных ресурсах задать:
  • vCPU: не менее 4-х.
  • Гарантированная доля vCPU: на время выполнения описываемых в статье действий не менее 50%, после окончания установки, при необходимости, можно будет уменьшить.
  • RAM: рекомендуется 8ГБ.
  • Подсеть: выбрать подсеть, для которой на этапе предварительной подготовки был включен NAT в Интернет.
  • Публичный адрес: выбрать из списка IP-адрес, ранее использованных для создания A-записи в DNS.
  • Пользователь: по своему усмотрению, но отличный от пользователя root и от системных учётных записей Linux.
  • Обязательно надо задать публичный (открытый) SSH-ключ.

Подробнее об использовании SSH см. https://cloud.yandex.ru/docs/compute/operations/vm-connect/ssh
См. также Приложение 1. Создание ключей SSH в openssh и putty и конвертация ключей из формата putty в openssh.
2.1.3 По окончании настройки нажать Создать ВМ.

2.2. Создание виртуальной машины для Zextras Docs
Последовательность действий:
2.2.1 В Консоли Яндекс.Облака зайти в раздел Compute Cloud, подраздел Виртуальные машины, нажать кнопку Создать ВМ (подробнее о создании ВМ см. https://cloud.yandex.ru/docs/compute/quickstart/quick-create-linux).



2.2.2 Там необходимо задать:
  • Имя произвольно (в соответствии с поддерживаемым Яндекс.Облаком форматом)
  • Зона доступности должна соответствовать ранее выбранной для виртуальной сети.
  • В Публичные образы выбрать Ubuntu 18.04 lts
  • В дисках установить загрузочный диск размером не менее 80ГБ. Для тестовых целей достаточно типа HDD (и также для продуктивного использования при условии вынесения некоторых типов данных на диски типа SSD). При необходимости дополнительные диски можно будет добавить после создания ВМ.

В вычислительных ресурсах задать:
  • vCPU: не менее 2-х.
  • Гарантированная доля vCPU: на время выполнения описываемых в статье действий не менее 50%, после окончания установки, при необходимости, можно будет уменьшить.
  • RAM: не менее 2ГБ.
  • Подсеть: выбрать подсеть, для которой на этапе предварительной подготовки был включен NAT в Интернет.
  • Публичный адрес: без адреса (к данной машине не требуется доступ из Интернета, только исходящий доступ с этой машины в Интернет, который обеспечивается опцией NAT в Интернет используемой подсети).
  • Пользователь: по своему усмотрению, но отличный от пользователя root и от системных учётных записей Linux.
  • Обязательно надо задать публичный (открытый) SSH-ключ, можно тот же самый, что и для сервера Zimbra, можно сгенерировать отдельную ключевую пару, т. к. закрытый ключ для сервера Zextras Docs потребуется поместить на диск сервера Zimbra.

См. также Приложение 1. Создание ключей SSH в openssh и putty и конвертация ключей из формата putty в openssh.
2.2.3 По окончании настройки нажать Создать ВМ.

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



3. Подготовка сервера Zimbra к инсталляции
3.1 Установка обновлений
Необходимо зайти на сервер Zimbra по его публичному IP-адресу посредством предпочитаемого вами ssh-клиента с использованием закрытого (частного, приватного) ключа ssh и используя имя пользователя, заданного при создании виртуальной машины.
После входа выполнить команды:
sudo apt update
sudo apt upgrade

(при выполнении последней команды ответить y на вопрос о том, уверены ли вы в установке предлагаемого списка обновлений)
После установки обновлений можно (но не обязательно) выполнить команду:
sudo apt autoremove
И в завершении шага выполнить команду
sudo shutdown r now

3.2 Доустановка приложений
Необходимо установить NTP-клиент для синхронизации системного времени и приложение screen следующей командой:
sudo apt install ntp screen
(при выполнении последней команды ответить y на вопрос о том, уверены ли вы в установке прилагаемого списка пакетов)
Также можно установить дополнительные утилиты для удобства администратора. Например, Midnight Commander может быть установлен командой:
sudo apt install mc

3.3. Изменение системной конфигурации

3.3.1 В файле /etc/cloud/cloud.cfg.d/95-yandex-cloud.cfg изменить значение параметра manage_etc_hosts c true на false.
Примечание: редактор для изменения этого файла надо запускать с правами пользователя root, например, sudo vi /etc/cloud/cloud.cfg.d/95-yandex-cloud.cfg или, если установлен пакет mc, можно использовать команду sudo mcedit /etc/cloud/cloud.cfg.d/95-yandex-cloud.cfg

3.3.2 Отредактировать /etc/hosts следующим образом, заменив в строке, определяющей FQDN хоста, адрес с 127.0.0.1 на внутренний IP-адрес этого сервера, а имя с полного имени в зоне .internal на публичное имя сервера, указанное ранее в A-записи зоны DNS, и соответствующим образом изменив короткое имя хоста (если оно отличается от короткого имени хоста из A-записи публичного DNS).
Например, в нашем случае файл hosts имел вид:



После редактирования он принял вид:



Примечание: редактор для изменения этого файла надо запускать с правами пользователя root, например, sudo vi /etc/hosts или, если установлен пакет mc, можно использовать команду sudo mcedit /etc/hosts

3.4 Задать пароль пользователя
Это необходимо в связи с тем, что в дальнейшем будет производиться настройка файрвола, и в случае возникновения каких-либо проблем с ним, при наличии у пользователя пароля, можно будет зайти на виртуальную машину с использованием сериальной консоли из веб-консоли Яндекс.Облако и отключить файрвол и/или исправить ошибку. При создании виртуальной машины пользователь не имеет пароля, и поэтому доступ возможен только по SSH с использованием аутентификации по ключам.
Для задания пароля необходимо выполнить команду:
sudo passwd <имя пользователя>
Например, в нашем случае это будет команда sudo passwd user.

4. Инсталляция Zimbra и Zextras Suite
4.1. Скачивание дистрибутивов Zimbra и Zextras Suite
4.1.1 Скачивание дистрибутива Zimbra
Последовательность действий:
1) Зайти браузером по URL www.zextras.com/download-zimbra-9
и заполните форму. Вам придет письмо со ссылками на загрузку Zimbra для разных ОС.
2) Выбрать актуальную версию дистрибутива для платформы Ubuntu 18.04 LTS и скопировать ссылку
3) Скачать дистрибутив Zimbra на сервер Zimbra и распаковать его
Для этого в ssh-сеансе на сервере zimbra выполнить команды
cd ~
mkdir zimbra
cd zimbra
wget <url, скопированный на предыдущем шаге>
tar zxf <имя скачанного файла>

(в нашем примере это tar zxf zcs-9.0.0_OSE_UBUNTU18_latest-zextras.tgz)

4.1.2 Скачивание дистрибутива Zextras Suite
Последовательность действий:
1) Зайти браузером по URL https://www.zextras.com/download/
2) Заполнить форму, введя необходимые данные, и нажать кнопку DOWNLOAD NOW



3) Откроется страница для скачивания



На ней есть два интересующих нас URL: один вверху страницы для самого Zextras Suite, который будет необходим нам сейчас, а другой внизу в блоке Docs Server для Ubuntu 18.04 LTS, который понадобится позже для установки Zextras Docs на ВМ для Docs.

4) Скачать дистрибутив Zextras Suite на сервер Zimbra и распаковать его
Для этого в ssh-сеансе на сервере zimbra выполнить команды
cd ~
mkdir zimbra
cd zimbra

(если после предыдущего шага не изменялась текущая директория команды выше можно не выполнять)
wget download.zextras.com/zextras_suite-latest.tgz
tar zxf zextras_suite-latest.tgz


4.2. Инсталляция Zimbra
Последовательность действий
1) Перейти в директорию, в которую распаковались файлы на шаге 4.1.1 (можно просмотреть командой ls, находясь в директории ~/zimbra).
В нашем примере это будет:
cd ~/zimbra/zcs-9.0.0_OSE_UBUNTU18_latest-zextras/zimbra-installer

2) Запустить инсталляцию Zimbra командой
sudo ./install.sh

3) Отвечаем на вопросы инсталлятора
На вопросы инсталлятора можно отвечать y (сответствует да), n (соответствует нет) или оставить предложение инсталлятора без изменений (он предлагает варианты, отображая их в квадратных скобках, например, [Y] или [N].
Do you agree with the terms of the software license agreement? да.
Use Zimbras package repository? по умолчанию (да).
Install zimbra-ldap?, Install zimbra-logger?, Install zimbra-mta? по умолчанию (да).
Install zimbra-dnscache? нет (в операционной системе по умолчанию включен свой кэширующий DNS сервер, поэтому у этого пакета будет с ним конфликт из-за используемых портов).
Install zimbra-snmp? по желанию, можно оставить вариант по умолчанию (да), можно не устанавливать этот пакет. В нашем примере оставлен вариант по умолчанию.
Install zimbra-store?, Install zimbra-apache?, Install zimbra-spell?, Install zimbra-memcached?, Install zimbra-proxy? по умолчанию (да).
Install zimbra-snmp? нет (пакет фактически не поддерживается и функционально заменяется Zextras Drive).
Install zimbra-imapd? по умолчанию (нет).
Install zimbra-chat? нет (функционально заменяется Zextras Team)
После чего инсталлятор спросит, продолжать ли установку?



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

4.) Отвечаем на вопросы первичного конфигуратора
4.1) Поскольку в нашем примере различаются DNS-имя почтового сервера (имя A-записи) и имя обслуживаемого почтового домена (имя MX-записи), конфигуратор выводит предупреждение и предлагает задать имя обслуживаемого почтового домена. Соглашаемся с его предложением и вводим имя MX-записи. В нашем примере это выглядит следующим образом:



Примечание: задать обслуживаемого почтового домена отличным от имени сервера можно и в том случае, если для имени сервера есть одноимённая MX-запись.

4.2) Конфигуратор отображает основное меню.



Нам необходимо задать пароль администратора Zimbra (пункт меню 6 в нашем примере), без которого невозможно продолжение инсталляции, и изменить настройку zimbra-proxy (пункт меню 8 в нашем примере; при необходимости эту настройку можно изменить и после инсталляции).

4.3) Изменение настроек zimbra-store
В приглашение конфигуратора вводим номер пункта меню и нажимаем Enter.
Попадаем в меню настройки хранилища:



где в приглашении конфигуратора вводим номер пункта меню Admin Password (в нашем примере 4), нажимаем Enter, после чего конфигуратор предлагает случайно сгенерированный пароль, с которым можно согласиться (запомнив его) либо ввести свой. В обоих случаях в конце надо нажать Enter, после чего с пункта Admin Password будет снят маркер ожидания ввода информации от пользователя:



Возвращаемся в предыдущее меню (соглашаемся с предложением конфигуратора).

4.4) Изменение настроек zimbra-proxy
По аналогии с предыдущим шагом, в главном меню выбираем номер пункта zimbra-proxy и вводим его в приглашение конфигуратора.



В открывшемся меню Proxy configuration выбираем номер пункта Proxy server mode и вводим его в приглашение конфигуратора.



Конфигуратор предложит выбрать один из режимов, вводим в его приглашение redirect и нажимаем Enter.
После чего возвращаемся в основное меню (соглашаемся с предложением конфигуратора).

4.5) Запуск конфигурации
Для запуска конфигурации вводим a в приглашение конфигуратора. После чего он спросит, сохранить ли введённую конфигурацию в файл (который можно использовать для повторной инсталляции) можно согласиться с предложением по умолчанию, если сохранение будет произведено спросит, в каком файле сохранить конфигурацию (также можно согласиться с предложением по умолчанию или ввести своё имя файла).



На данном этапе еще можно отказаться от продолжения и внести изменения в конфигурацию, согласившись с ответом по умолчанию на вопрос The system will be modified continue?.
Для начала инсталляции на этот вопрос необходимо ответить Yes, после чего конфигуратор будет некоторое время применять введённые ранее настройки.

4.6) Завершение инсталляции Zimbra
Перед завершением инсталлятор спросит, уведомлять ли Zimbra о произведённой инсталляции? Можно как согласиться с предложением по умолчанию, так и отказаться (ответив No) от уведомления.
После чего инсталлятор еще некоторое время будет проделывать завершающие операции и выведет уведомление о завершении конфигурирования системы с предложением нажать любую клавишу для выхода из инсталлятора.



4.3. Инсталляция Zextras Suite
Подробнее об установке Zextras Suite см. https://svzcloud.ru/zextras/Docs/Ustanovka_zextras_suite_-_team-31032020.pdf

Последовательность действий:
1) Перейти в директорию, в которую распаковались файлы на шаге 4.1.2 (можно просмотреть командой ls, находясь в директории ~/zimbra).
В нашем примере это будет:
cd ~/zimbra/zextras_suite

2) Запустить инсталляцию Zextras Suite командой
sudo ./install.sh all

3) Отвечаем на вопросы инсталлятора
Принцип работы инсталлятора аналогичен работе инсталлятора Zimbra, за исключением отсутствия конфигуратора. На вопросы инсталлятора можно отвечать y (соответствует да), n (соответствует нет) или оставить предложение инсталлятора без изменений (он предлагает варианты, отображая их в квадратных скобках, например, [Y] или [N].
Для начала процесса инсталляции необходимо последовательно ответить да на следующие вопросы:
Do you agree with the terms of the software license agreement?
Do you wish for Zextras Suite to automatically download, install and upgrade the ZAL Library?
После чего будет выведено уведомление с предложение нажать Enter для продолжения:



После нажатия на Enter начнётся процесс инсталляции, иногда прерываемый вопросами, на которые, впрочем, отвечаем согласием с предложениями по умолчанию (да), а именно:
Zextras Suite Core will now be installed. Proceed?
Do you wish to stop the Zimbra Web Application (mailbox)?
The Zextras Suite Zimlet will now be installed. Proceed?

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



4.4. Первичный тюнинг настройки и определение параметров конфигурации LDAP
1) Все последующие действия выполняются из-под пользователя zimbra. Для этого необходимо выполнить команду
sudo su zimbra

2) Изменяем настройку DOS фильтра командой
zmprov mcf zimbraHttpDosFilterMaxRequestsPerSec 150

3) Для установки Zextras Docs понадобится информация о некоторых параметрах настройки Zimbra. Для этого можно выполнить команду:
zmlocalconfig s | grep ldap
В нашем примере будет выведена следующая информация:



Для дальнейшего использования понадобятся ldap_url, zimbra_ldap_password (и zimbra_ldap_userdn, хотя инсталлятор Zextras Docs обычно выдаёт правильные предположения об имени пользователя LDAP).

4) Завершить работу под пользователем zimbra, выполнив команду
logout

5. Подготовка сервера Docs к инсталляции
5.1. Загрузка закрытого ключа SSH на сервер Zimbra и вход на сервер Docs
Необходимо поместить на сервер Zimbra закрытый ключ пары SSH ключей, публичный ключ которой был использован на шаге 2.2.2 п.2.2 при создании виртуальной машины Docs. Его можно загрузить на сервер по SSH (например, по sftp) или вставить через буфер обмена (если позволяют возможности используемого SSH-клиента и среды его выполнения).
Считаем, что закрытый ключ помещён в файл ~/.ssh/docs.key и пользователь, используемый для входа на сервер Zimbra является его владельцем (если загрузка/создание этого файла осуществлялись из-под этого пользователя он автоматически стал его владельцем).
Необходимо однократно выполнить команду:
chmod 600 ~/.ssh/docs.key
В дальнейшем для входа на сервер Docs необходимо выполнять следующую последовательность действий:
1) Зайти на сервер Zimbra

2) Выполнить команду
ssh -i ~/.ssh/docs.key user@<внутренний ip-адрес сервера Docs>
Где значение <внутренний ip-адрес сервера Docs> можно узнать в Консоли Яндекс.Облако, например, как это показано в п.2.3.

5.2. Установка обновлений
После входа на сервер Docs выполнить команды аналогично таковым для сервера Zimbra:
sudo apt update
sudo apt upgrade

(при выполнении последней команды ответить y на вопрос о том, уверены ли вы в установке предлагаемого списка обновлений)
После установки обновлений можно (но не обязательно) выполнить команду:
sudo apt autoremove
И в завершении шага выполнить команду
sudo shutdown r now

5.3. Доустановка приложений
Необходимо установить NTP-клиент для синхронизации системного времени и приложение screen, аналогично такому же действию для сервера Zimbra, следующей командой:
sudo apt install ntp screen
(при выполнении последней команды ответить y на вопрос о том, уверены ли вы в установке прилагаемого списка пакетов)
Также можно установить дополнительные утилиты для удобства администратора. Например, Midnight Commander может быть установлен командой:
sudo apt install mc

5.4. Изменение системной конфигурации
5.4.1. В файле /etc/cloud/cloud.cfg.d/95-yandex-cloud.cfg так же, как и для сервера Zimbra, изменить значение параметра manage_etc_hosts c true на false.
Примечание: редактор для изменения этого файла надо запускать с правами пользователя root, например, sudo vi /etc/cloud/cloud.cfg.d/95-yandex-cloud.cfg или, если установлен пакет mc, можно использовать команду sudo mcedit /etc/cloud/cloud.cfg.d/95-yandex-cloud.cfg

5.4.2. Отредактировать /etc/hosts, добавив в него публичный FQDN сервера Zimbra, но с внутренним IP-адресом, назначенным Яндекс.Облако. При наличии управляемого администратором внутреннего DNS-сервера, используемого виртуальными машинами (например, в продуктивной среде), и способного разрешать публичный FQDN сервера Zimbra внутренним IP-адресом при получении запроса из внутренней сети (для запросов из Интернет FQDN сервера Zimbra должно разрешаться публичным IP-адресом, а сервер TURN должен разрешаться публичным IP-адресом всегда, в т.ч. при обращении с внутренних адресов), эта операция не требуется.
Например, в нашем случае файл hosts имел вид:



После редактирования он принял вид:



Примечание: редактор для изменения этого файла надо запускать с правами пользователя root, например, sudo vi /etc/hosts или, если установлен пакет mc, можно использовать команду sudo mcedit /etc/hosts

6. Инсталляция Zextras Docs

6.1. Зайти на сервер Docs
Порядок входа на сервер Docs описан в п.5.1.

6.2. Скачивание дистрибутива Zextras Docs
Последовательность действий:
1) Со страницы, с которой в п. 4.1.2. Скачивание дистрибутива Zextras Suite скачивался дистрибутив Zextras Suite (на шаге 3), скопировать URL для сборки Docs для Ubuntu 18.04 LTS (если он не был скопирован ранее).

2) Скачать дистрибутив Zextras Suite на сервер Zimbra и распаковать его
Для этого в ssh-сеансе на сервере zimbra выполнить команды
cd ~
mkdir zimbra
cd zimbra
wget <URL со страницы скачивания>

(в нашем случае выполняется команда wget download.zextras.com/zextras-docs-installer/latest/zextras-docs-ubuntu18.tgz)
tar zxf <имя скачанного файла>
(в нашем случае выполняется команда tar zxf zextras-docs-ubuntu18.tgz)

6.3. Инсталляция Zextras Docs
Подробнее о установке и настройке Zextras Docs см. docs.zextras.com/zextras-suite-documentation/latest/docs.html
Последовательность действий:
1) Перейти в директорию, в которую распаковались файлы на шаге 4.1.1 (можно просмотреть командой ls, находясь в директории ~/zimbra).
В нашем примере это будет:
cd ~/zimbra/zextras-docs-installer

2) Запустить инсталляцию Zextras Docs командой
sudo ./install.sh

3) Отвечаем на вопросы инсталлятора
На вопросы инсталлятора можно отвечать y (сответствует да), n (соответствует нет) или оставить предложение инсталлятора без изменений (он предлагает варианты, отображая их в квадратных скобках, например, [Y] или [N]).
System will be modified, would you like to proceed? принимаем вариант по умолчанию (да).
После этого начнётся установка зависимостей: инсталлятор будет показывать, какие пакеты он хочет установить и спрашивать подтверждение на их установку. Во всех случаях соглашаемся с предложениями по умолчанию.
Например, он может спрашивать python2.7 not found. Would you like to install it?, python-ldap not found. Would you like to install it? и т.п.
После установки всех необходимых пакетов инсталлятор запрашивает согласие на установку Zextras Docs:
Would you like to install Zextras DOCS? принимаем вариант по умолчанию (да).
После чего некоторое время идёт установка пакетов, собственно, Zextras Docs и переход к вопросам конфигуратора.

4) Отвечаем на вопросы конфигуратора
Конфигуратор по очереди запрашивает конфигурационные параметры, в ответ в вводятся значения, полученные на шаге 3 в п.4.4. Первичный тюнинг настройки и определение параметров конфигурации LDAP.
В нашем примере настройки имеют вид:



5) Завершение инсталляции Zextras Docs
После ответа на вопросы конфигуратора инсталлятор завершает локальную конфигурацию Docs и регистрирует установленный сервис на основном сервере Zimbra, установленном ранее.
Для single-server инсталляции как правило этого достаточно, но в некоторых случаях (если документы не будут открываться в Docs в вебклиенте на вкладке Drive) может понадобится выполнение действия, обязательного для мультисерверной установки в нашем примере на основном сервере Zimbra потребуется выполнение из-под пользователя Zimbra команд /opt/zimbra/libexec/zmproxyconfgen и zmproxyctl restart.

7. Первичная настройка Zimbra и Zextras Suite (кроме Team)
7.1. Первичный вход в консоль администратора
Войти в браузере по URL: https://<FQDN_сервера_Zimbra>:7071
При желании, можно войти в веб-клиент по URL: https://<FQDN_сервера_Zimbra>
При входе браузеры показывают предупреждение о небезопасном подключении в связи с невозможностью проверить сертификат. Необходимо ответить браузеру о согласии перейти на сайт несмотря данное предупреждение. Это связано с тем, что после установки используется самоподписанный X.509 сертификат для TLS-соединений, который впоследствии можно (в продуктивном использовании нужно) заменить на коммерческий сертификат или иной сертификат, признаваемый используемыми браузерами.
В форме для аутентификации ввести имя пользователя в формате admin@<ваш обслуживаемый почтовый домен> и пароль администратора Zimbra, заданный при установке сервера Zimbra на шаге 4.3 в п.4.2.
В нашем примере это выглядит следующим образом:

Консоль администратора:



Веб-клиент:



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

Примечание 2. При входе в веб-клиент браузер может запрашивать разрешение на отображение уведомлений с сайта. Необходимо дать согласие на получение уведомлений с этого сайта.

Примечание 3. После входа в консоль администратора может быть выведено уведомление о наличии сообщений администратору, как правило, являющихся напоминанием о необходимости настроить Zextras Backup и/или о необходимости приобрести лицензию Zextras до окончания срока действия триальной лицензии, установленной по умолчанию. Эти действия можно произвести позднее, а потому имеющиеся на момент входа сообщения можно игнорировать и/или отметить их как прочитанные в меню Zextras: Оповещение Zextras.



Примечание 4. Особо необходимо отметить, что в мониторе состояния сервера статус службы Docs отображается как не доступна даже если Docs в веб клиенте работает корректно:



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

7.2. Развёртывание компонентов Zextras Suite
В меню Zextras: Core необходимо нажать на кнопку Развернуть для всех зимлетов, которые предполагается использовать.



При развёртывании зимлетов выводится диалог с результатом операции следующего вида:



В нашем примере производится развёртывание всех зимлетов Zextras Suite, после чего форма Zextras: Core примет следующий вид:



7.3. Изменение настроек доступа
7.3.1. Изменение глобальных настроек
В меню Настройка: Глобальные настройки, подменю Прокси-сервер, изменить следующие параметры:
Режим веб-прокси: redirect
Включить прокси-сервер консоли администрирование: поставить чекбокс.
После чего в правой верхней части форму нажать на Сохранить.
В нашем примере после внесённых изменений форма имеет следующий вид:



7.3.2. Изменения настроек сервера основного Zimbra
В меню Настройка: Серверы: <имя основного сервера Zimbra>, подменю Прокси-сервер, изменить следующие параметры:
Режим веб-прокси: нажать на кнопку Сбросить на значение по умолчанию (при этом само значение не изменится, т. к. уже было задано при установке).
Включить прокси-сервер консоли администрирование: проверить, что чекбокс стоит (должно было примениться значение по умолчанию, если не применилось можно нажать кнопку Сбросить на значение по умолчанию и/или поставить вручную).
После чего в правой верхней части формы нажать на Сохранить.
В нашем примере после внесённых изменений форма имеет следующий вид:



Примечание: (может потребоваться перезапуск, если не заработает вход по этому порту)

7.4. Новый вход в консоль администратора
Войти в консоль администратора в браузере по URL: https://<FQDN_сервера_Zimbra>:9071
В дальнейшем использовать для входа этот URL
Примечание: для single-server инсталляции как правило достаточно изменения, проделанного на предыдущем шаге, но в некоторых случаях (если при входе по указанному URL не отображается страница сервера) может понадобится выполнение действия, обязательного для мультисерверной установки в нашем примере на основном сервере Zimbra потребуется выполнение из-под пользователя Zimbra команд /opt/zimbra/libexec/zmproxyconfgen и zmproxyctl restart.

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



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



В тестовой среде в этом же классе обслуживания можно включить функции Team Pro, для чего в подменю Team включить чекбокс с одноимённым названием, после чего форма настройки примет следующий вид:



При отключенных функциях Team Pro пользователям будут доступны только функции Team Basic.
Обращаем ваше внимание на то, что Zextras Team Pro лицензируется независимо от Zextras Suite, что позволяет приобрести его на меньшее количество почтовых ящиков, чем собственно Zextras Suite; функции Team Basic включены в лицензию Zextras Suite. Поэтому при использовании в продуктивной среде может потребоваться создание отдельного класса обслуживания для пользователей Team Pro, в котором будут включены соответствующие функции.

7.6. Настройка файрвола
Необходимо для основного сервера Zimbra:
а) Разрешить доступ из Интернета к портам ssh, http/https, imap/imaps, pop3/pop3s, smtp (основной порт и дополнительные порты для использования почтовыми клиентами) и порт консоли администрирования.

б) Разрешить все подключения из внутренней сети (для которой на шаге 1.3 в п.1 был включен NAT в Интернет).

Для сервера Zextras Docs настраивать файрвол не требуется, т.к. к нему отсутствует доступ из Интернета.
Для этого необходимо выполнить следующую последовательность действий:
1) Зайти в текстовую консоль основного сервера Zimbra. При входе по SSH необходимо выполнить команду screen во избежание прерывания выполнения команд при временной потери связи с сервером из-за изменения настроек файрвола.

2) Выполнить команды
sudo ufw allow 22,25,80,110,143,443,465,587,993,995,9071/tcp
sudo ufw allow from <адрес_вашей_сети>/<длина CIDR маски>
sudo ufw enable


В нашем примере это выглядит следующим образом:



7.7. Проверка доступа к веб-клиенту и консоли администратора
Для контроля работоспособности файрвола можно зайти в браузере по следующим URL
Консоль администратора: https://<FQDN_сервера_Zimbra>:9071
Веб-клиент: http://<FQDN_сервера_Zimbra> (произойдёт автоматический редирект на https://<FQDN_сервера_Zimbra>)
При этом по альтернативному URL https://<FQDN_сервера_Zimbra>:7071 консоль администратора не должна открываться.
Веб-клиент в нашем примере выглядит следующим образом:



Примечание. При входе в веб-клиент браузер может запрашивать разрешение на отображение уведомлений с сайта. Необходимо дать согласие на получение уведомлений с этого сайта.

8. Обеспечение работы аудио- и видеоконференций в Zextras Team
8.1. Общие сведения
Выполнение описанных далее действие не требуется, если все клиенты Zextras Team взаимодействуют друг с другом без использования NAT (при этом взаимодействия с самим сервером Zimbra может осуществляться с использованием NAT, т.е. важно отсутствие NAT именно между клиентами), или если используется только текстовый мессенджер.
Для обеспечения взаимодействия клиентов в режиме аудио- и видеоконференцсвязи:
а) Необходимо установить либо использовать существующий сервер TURN.

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

В продуктивной среде из-за потенциально высокой нагрузки рекомендуется выносить сервер TURN на отдельную виртуальную машину. Для тестирования и/или небольшой нагрузки сервер TURN может быть совмещен с основным сервером Zimbra.
В нашем примере рассматривается установка сервера TURN на основной сервер Zimbra. Установка TURN на отдельный сервер аналогична с той разницей, что шаги, относящиеся у установке и конфигурированию программного обеспечения TURN выполняются на сервере TURN, а шаги по настройке сервера Zimbra на использование этого сервера выполняются на основном сервере Zimbra.

8.2. Установка TURN-сервера
Предварительно зайдя по SSH на основной сервер Zimbra выполнить команду
sudo apt install resiprocate-turn-server

8.3. Настройка TURN сервера
Примечание. Редактор для изменения всех указанных далее конфигурационных файлов надо запускать с правами пользователя root, например, sudo vi /etc/reTurn/reTurnServer.config или, если установлен пакет mc, можно использовать команду sudo mcedit /etc/reTurn/reTurnServer.config

Упрощённое создание пользователя
Для упрощения создания и отладки тестового подключения к TURN серверу мы отключим использование хешированных паролей в базе пользователей TURN сервера. В продуктивной среде рекомендуется использовать хэшированные пароли; в этом случае генерацию хешей паролей для них необходимо выполнять в соответствии с инструкциями, содержащимися в файлах /etc/reTurn/reTurnServer.config и /etc/reTurn/users.txt.

Последовательность действий:
1) Отредактировать файл /etc/reTurn/reTurnServer.config
Изменить значение параметра UserDatabaseHashedPasswords с true на false.

2) Отредактировать файл /etc/reTurn/users.txt
Задать в нём имя пользователя, пароль, realm (произвольный, не используется при настройке подключения Zimbra) и установить учётной записи статус AUTHORIZED.
В нашем примере файл изначально имел вид:



После редактирования принял вид:



3) Применение конфигурации
Выполнить команду
sudo systemctl restart resiprocate-turn-server

8.4. Настройка файрвола для сервера TURN
На данном этапе устанавливаются дополнительные правила файрвола, необходимые для работы сервера TURN. Необходимо разрешить доступ к основному порту, на котором сервер принимает запросы, и к динамическому диапазону портов, используемых сервером для организации медиапотоков.
Порты указаны в файле /etc/reTurn/reTurnServer.config, в нашем случае это:



и



Для установки правил файрвола необходимо выполнить команды
sudo ufw allow 3478,49152:65535/udp
sudo ufw allow 3478,49152:65535/tcp


8.5. Настройка использования сервера TURN в Zimbra
Для настройки используется FQDN сервера сервер TURN, созданное на шаге 1.2 п.1, и которое должно DNS-серверами разрешаться одним и тем же публичным IP-адресом как для запросов из Интернет, так и для запросов с внутренних адресов.
Просмотреть текущую настройку подключения zxsuite team iceServer get, выполняемой из-под пользователя zimbra.
Подробнее о настройке использования сервера TURN см. раздел Установка Zextras Team для использования TURN сервера в документации.

Для настройки необходимо выполнить следующие команды на сервере Zimbra:

sudo su zimbra
zxsuite team iceServer add stun:<FQDN вашего сервера TURN>:3478?transport=udp
zxsuite team iceServer add turn:<FQDN вашего сервера TURN>:3478?transport=udp credential <пароль> username <имя пользователя>
zxsuite team iceServer add stun:<FQDN вашего сервера TURN>:3478?transport=tcp
zxsuite team iceServer add turn:<FQDN вашего сервера TURN>:3478?transport=tcp credential <пароль> username <имя пользователя>
zxsuite team iceServer add stun:<FQDN вашего сервера TURN>:3478
logout


В качестве <имя пользователя> и <пароль> используются значения имени пользователя и пароля соответственно, заданные на шаге 2 в п.8.3.

В нашем примере это выглядит следующим образом:



9. Разрешение прохождения почты по протоколу SMTP
В соответствии с документацией, в Яндекс.Облаке всегда блокируется исходящий трафик на TCP-порт 25 в Интернет и на виртуальные машины Yandex Compute Cloud, при обращении через публичный IP-адрес. Это не помешает проверить приём почты на обслуживаемый почтовый домен, отправленной с иного почтового сервера, но помешает отправить почту за пределы сервера Zimbra.

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

Приложение

Создание ключей SSH в openssh и putty и конвертация ключей из формата putty в openssh

1. Создание ключевых пар для SSH

В Windows с использованием putty: запустить команду puttygen.exe и нажать кнопку Generate

В Linux: выполнить команду
ssh-keygen

2. Конвертация ключей из формата putty в openssh

В Windows:
Последовательность действий:
1) Запустить программу puttygen.exe.
2) Загрузить закрытый ключ в формате ppk, для чего воспользоваться пунктом меню File Load private key.
3) Ввести код (passphrase), если он требуется для данного ключа.
4) Публичный ключ формате OpenSSH отображается в puttygen с надписью Public key for pasting into OpenSSH authorized_keys file field
5) Для экспорта закрытого ключа в формат OpenSSH выбрать в главном меню Conversions Export OpenSSH key
6) Сохранить закрытый ключ в новый файл.

В Linux
1. Установить пакет инструментов PuTTY:
в Ubuntu: sudo apt-get install putty-tools
в Debian-подобных дистрибутивах: apt-get install putty-tools
в RPM-based дистрибутивах на основе yum (CentOS и др.): yum install putty

2. Для конвертации закрытого ключа выполнить команду:
puttygen <key.ppk> -O private-openssh -o <key_openssh>

3. Для генерации открытого ключа (если необходимо):
puttygen <key.ppk> -O public-openssh -o <key_openssh.pub>

Результат

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

По всем вопросам, связанными c Zextras Suite вы можете обратиться к Представителю компании Zextras Екатерине Триандафилиди по электронной почте katerina@zextras.com
Подробнее..

Особенности применения управляемых и неуправляемых коммутаторов

27.10.2020 12:09:43 | Автор: admin


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


Примечание. В этой статье мы говорим о сетях семейства Ethernet, в том числе: Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet. Для экономии времени все эти сети для краткости мы будем называть термином Ethernet.


Для чего нужны неуправляемые коммутаторы


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


Преимущества неуправляемых коммутаторов


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


Ещё один несомненный плюс неуправляемые коммутаторы стоят дешевле.


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


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


Из практики. Сетевые инфраструктуры только из неуправляемых коммутаторов без применения другого сетевого оборудования (за исключением Интернет-шлюза) редко переходят за порог 254 устройства. Такие LAN часто оформляются в виде одной подсети класса С. На это есть свои причины если слишком много устройств находится в одном широковещательном домене, то служебный Ethernet трафик достигает существенной величины и начинает мешать передаче информации. Это связано с тем, что каждое устройство обязано принять и обработать широковещательные кадры, а это, в свою очередь создает ненужную нагрузку и засоряет канал связи. Чем больше устройств, тем больше широковещательных посылок время от времени проходит по сети, которые принимают все эти же устройства. В свою очередь маска подсети класса С 255.255.255.0 и префикс 192.168.xxx.xxx популярные значения, а предел в 254 устройства для сетей этого класса является, помимо всего прочего, своего рода психологической отметкой, когда приходит понимание, что c разросшейся сетью надо что-то делать.


Ещё одна сфера применения неуправляемых коммутаторов удешевление сетевой инфраструктуры. Строить развернутую сеть на базе только управляемых коммутаторов достаточно дорогое удовольствие. На практике возникают случаи, когда большое число однотипных устройств находятся в одной подсети и расположены относительно недалеко. В качестве примера можно привести пользователей тонких клиентов в опенспейсе, которым назначен отдельный изолированный VLAN. В таких простых случаях функции управления на коммутаторе уровня доступа не так уж и востребовано. За вопросы безопасности и перенаправления трафика отвечает уровень распределения (агрегации) и далее ядро сети.


Ещё один классический пример: специально выделенная сеть для управления оборудованием, куда подключены, интерфейсы IPMI для управления серверами, IP-KVM и так далее.


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


Некоторые мифы и заблуждения


Миф 1. Неуправляемые коммутаторы это отсталое старьё, рассчитанное на небольшие скорости (до 1 Гбит/сек. максимум), сейчас все новые современные коммутаторы управляемые.


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



Рисунок 1. Zyxel XGS1010-12 12-портовый неуправляемый мультигигабитный коммутатор с 2 портами 2.5G и 2 портами 10G SFP+


Миф 2. Сейчас неуправляемые коммутаторы это для не корпоративных сетей. Они не выпускаются в формфакторе 19 дюймовых стоек и содержат не больше 16-ти портов.


Это тоже не соответствует действительности стоечные неуправляемые коммутаторы выпускаются и находят свое место в том числе в корпоративных сетях. В качестве примера можно привести Zyxel GS1100-24 24-портовый гигабитный неуправляемый коммутатор с гигабитным Uplink.



Рисунок 2. Zyxel GS1100-24 24-портовый гигабитный неуправляемый коммутатор в стоечном исполнении.


Миф 3. С PoE бывают только управляемые коммутаторы. Аналогичное заблуждение: с PoE только неуправляемые.


На самом деле и управляемые, и неуправляемые коммутаторы бывают как с PoE, так и без. Все зависит от конкретной модели и линейки оборудования. Для более подробного ознакомления рекомендуем статью IP-камеры PoE, особые требования и бесперебойная работа сводим всё воедино.



Рисунок 3. Zyxel GS1300-26HP 24-портовый гигабитный (+2 Uplink) неуправляемый коммутатор для систем видеонаблюдения с расширенной поддержкой PoE.


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


Ограничение неуправляемых коммутаторов


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


Управляемые коммутаторы


В отличие от их более простых собратьев, которые выше канального уровня (2-й уровень модели OSI) не поднимались, управляемые коммутаторы выпускаются уровней L2, L2+, L3 и даже L3+.


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


Функции управления в коммутаторах L2


Управляемые коммутаторы L2 вещь довольно распространенная. Например, их удобно использовать на уровне доступа, чтобы гибко управлять клиентским трафиком.


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


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


Возможность удаленной перезагрузки или выключения


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


Port UP/Down


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


Пример: неиспользуемые розетки в переговорной. Изредка они нужны, когда необходимо подключить дополнительное оборудование, например, для видеоконференций, а также ПК, МФУ и другие устройства. Однако при собеседовании кандидатов для приема на работу такие свободные порты могут оказаться брешью в безопасности, которую лучше прикрыть.


Разумеется, можно постоянно бегать в серверную и отключать-подключать порты вручную, выдергивая патчкорды из коммутатора или патчпанели. Но такой подход чреват не только необходимостью постоянно держать поблизости человека, способного это проделать, но и быстрым выходом разъемов из строя. Поэтому возможности менять состояние Up-Down для каждого порта рано или поздно окупится.


Защита от петель


Ошибки в виде двойного подключения приводят к созданию петель в сетях Ethernet и лишают сеть работоспособности.


Для их защиты придуманы специальные средства в первую очередь мы говорим о семействе протоколов STP (Spanning Tree Protocol), который, кроме защиты от петель, предотвращает возникновение широковещательного шторма в сетях. Протоколы семейства STP работают на 2 уровне модели OSI (L2).


Агрегирование каналов


Позволяет объединить два или несколько портов (обычно применяется число, кратное 2) в один канал передачи данных. Один из известных проколов для агрегации LACP (Link Aggregation Control Protocol), поддерживаемый большинством Unix-like операционных систем. LACP работает в режиме Active-Active и, благодаря ему, помимо повышения отказоустойчивости увеличивается и скорость передачи данных


Поддержка VLAN


VLAN (Virtual Local Area Network) группа устройств, обменивающихся трафиком на канальном уровне (2 уровень сетевой модели OSI), хотя физически они могут быть подключены к разным коммутаторам.


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


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


Например, если всей бухгалтерии, находящейся на 2-м, 3-м и 5-м этажах необходимо дать доступ к серверу 1С, но при этом запретить доступ к сети вычислительного кластера для инженерных расчетов, то разумнее всего сделать дополнительный VLAN, настроить общие ограничения, после чего приписать к нему порты всех бухгалтерских компьютеров.


QoS


Под QoS (Quality of Service) обычно подразумевают способность сети обеспечить необходимый уровень сервиса заданному сетевому трафику.


Например, в сети, при работе оборудования для видеоконференций, трафик между источником и приемником видеотрансляции будет более приоритетным, чем, например, копирование документов для инженеров техподдержки.


Существует множество различных инструментов, облегчающие подобные задачи, в том числе создание аппаратных очередей, flow-control и так далее.


Безопасность


Под безопасностью можно понимать самые разнообразные функции, например, те же VLAN.


Также среди наиболее известных: Port Security, фильтрация Layer 3 IP, фильтрация Layer 4 TCP/UDP.


Например, вот список функций безопасности для коммутаторов L2 серии GS2220:


  • Port security
  • Фильтрация Layer 2 MAC
  • Фильтрация Layer 3 IP
  • Фильтрация Layer 4 TCP/UDP
  • Static MAC forwarding
  • Несколько серверов RADIUS
  • Несколько серверов TACACS+
  • 802.1x VLAN and 802.1p assignment by RADIUS
  • Аутентификация RADIUS
  • Аутентификация TACACS+
  • TACACS+ аккаунтинг
  • RADIUS аккаунтинг
  • Авторизация RADIUS
  • Авторизация TACACS+
  • SSH v2
  • SSL
  • MAC freeze
  • DHCP snooping IPv4
  • DHCP snooping IPv6
  • ARP inspection
  • Static IP-MAC-Port binding
  • Policy-based security filtering
  • Port isolation
  • IP source guard (IPv4/IPv6)
  • MAC search
  • Guest VLAN
  • ACL packet filtering (IPv4/IPv6)
  • CPU protection
  • Interface related trap enable disable (by port)
  • MAC-based authentication per VLAN

Как видим, есть довольно много возможностей, которые востребованы в тех или иных обстоятельствах.



Рисунок 4. GS2220-50HP 48-портовый гигабитный PoE коммутатор L2 c 2 Uplink SFP GBE.


Управление


Возможности управления и контроля могут быть самые различные. Например, через веб-интерфейс, CLI (интерфейс командной строки), настройка через консольный порт RS-232, сохранение, извлечение и клонирование конфигурации, расписание включения PoE (для коммутаторов с PoE).


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


Старый добрый SNMP протокол тоже играет немаловажную роль, как в плане опроса и управления по протоколам SNMP v1/2c/3, так и оповещения с использованием механизма SNMP Trap.


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


Что в итоге


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


Полезные ссылки


  1. Telegram chat Zyxel
  2. Форум по оборудованию Zyxel
  3. Много полезного видео на канале Youtube
  4. IP-камеры PoE, особые требования и бесперебойная работа сводим всё воедино
  5. 12-портовый неуправляемый многогигабитный коммутатор с 2 портами 2.5G и 2 портами 10G SFP+
  6. Специализированный коммутатор для систем видеонаблюдения GS1300 Series
  7. 8/16/24-портовые гигабитные неуправляемые коммутаторы серии GS1100
  8. Управляемые 10/28/50-портовые гигабитные коммутаторы L2 серии
Подробнее..

Из песочницы Как выбрать инструмент для бизнес-анализа

08.10.2020 18:22:32 | Автор: admin

Какой у Вас выбор?


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

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

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

Приведенные особенности BI-систем заставляют задуматься о подборе альтернативы. Далее я предлагаю сравнить решение стандартного набора задач при подготовке отчетности с помощью Power BI и Excel.

Power BI или Excel?


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

А как решается эта задача с помощью Power BI?

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

Какие преимущества применения Power BI по сравнению с традиционным подходом можно заметить в приведенном примере?

1 Автоматизация процедуры получения данных и подготовка их к анализу.
2 Построение бизнес-модели.
3 Невероятная визуализация.
4 Разграниченный доступ к отчетам.

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

1 Для подготовки данных к построению отчета, нужно единожды определить процедуру, выполняющую подключение к данным и их обработку и каждый раз, когда понадобится получить отчет за другой период, Power BI будет пропускать данные через созданную процедуру. Таким образом автоматизируется большая часть работы по подготовки данных к анализу. Но дело в том, что Power BI осуществляет процедуру подготовки данных с помощью инструмента, который доступен в классической версии Excel, и называется он Power Query. Он позволяет выполнить поставленную задачу в Excel абсолютно тем же способом.

2 Здесь та же ситуация. Инструмент Power BI для построения бизнес-модели имеется и в Excel это Power Pivot.

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

4 Остается разобраться с доступом к отчетам. Тут не так все радужно. Дело в том, что Power BI это облачный сервис, доступ к которому осуществляется через персональную учетную запись. Администратор сервиса распределяет пользователей по группам и задает для этих групп различный уровень доступа к отчетам. Этим достигается разграничение прав доступа между сотрудниками компании. Таким образом, аналитики, менеджеры и директора заходя на одну и туже страницу видят отчет в доступном для них представлении. Может быть ограничен доступ к определенному набору данных, либо к отчету целиком. Однако, если отчет находится в файле формата Excel, то усилиями системного администратора можно попытаться решить задачу с доступом, но это будет уже не то. Я еще вернусь к рассмотрению этой задачи, когда буду описывать особенности корпоративного портала.

Стоит отметить, что, как правило, потребность компании в сложных и красивых дашбордах не велика и часто, для анализа данных в Excel, после построения бизнес-модели не прибегают к возможностям Power View, а пользуются сводными таблицами. Они предоставляют OLAP-функциональность, которой вполне достаточно чтобы решить большинство бизнес-аналитических задач.

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

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

ETL и DWH


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

С их помощью осуществляется выгрузка данных из источников (Extract), их преобразование (Transform), что подразумевает очистку и сопоставление, и загрузка в хранилище данных (Load). Хранилище данных (DWH Data Warehouse) это, как правило, реляционная база данных, расположенная на сервере. Эта база содержит данные, пригодные для анализа. По расписанию запускается ETL-процесс, который обновляет данные хранилища до актуальных. Кстати говоря, всю эту кухню прекрасно обслуживает Integration Services, входящие в состав MS SQL Server.

Далее, как и раньше для построения бизнес-модели данных и визуализации можно воспользоваться Excel, Power BI, либо другими аналитическими инструментами, такими как Tableau или Qlik Sense. Но прежде, мне бы хотелось обратить Ваше внимание еще на одну возможность, о которой Вы могли не знать, несмотря на то, что она Вам давно доступна. Речь идет о построении бизнес-моделей с помощью аналитических служб MS SQL Server, а именно Analysis Services.

Модели данных в MS Analysis Services


Этот раздел статьи будет более интересен тем, кто уже использует MS SQL Server в своей компании.

На данный момент службы Analysis Services предоставляют два вида моделей данных это многомерная и табличная модели. Кроме того, что данные в этих моделях связаны, значения показателей модели предварительно агрегируются и хранятся в ячейках OLAP кубов, доступ к которым осуществляется MDX, либо DAX запросами. За счет такой архитектуры хранения данных, запрос, который охватывает миллионы записей, возвращается за секунды. Такой способ доступа к данным необходим компаниям, таблицы транзакций которых содержат от миллиона записей (верхний придел не ограничен).

Excel, Power BI и многие другие солидные инструменты умеют подключаться к таким моделям и визуализировать данные их структур.

Если Вы пошли продвинутым путем: автоматизировали процесс ETL и построили бизнес-модели при помощи служб MS SQL Server, то Вы достойны иметь свой собственный корпоративный портал.

Корпоративный портал


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

Однако, пока не понятно, как будет организовано отображение отчетов на странице портала. Чтобы ответить на этот вопрос, сначала нужно определиться с технологией, на основе которой будет строиться портал. Я предлагаю взять за основу один из фреймворков: ASP.NET MVC/Web Forms/Core, либо Microsoft SharePoint. Если в Вашей компании имеется хотя бы один .NET разработчик, то выбор не составит труда. Теперь можно подбирать встраиваемый в приложение OLAP-клиент, способный подключаться к многомерным или табличным моделям служб Analysis Services.

Выбор OLAP-клиента для визуализации


Сравним несколько инструментов по уровню сложности встраивания, функциональности и цене: Power BI, компоненты Telerik UI for ASP.NET MVC и компоненты RadarCube ASP.NET MVC.

Power BI


Чтобы организовать доступ сотрудников компании к отчетам Power BI на странице своего портала, нужно воспользоваться функцией Power BI Embedded.

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

Сначала отчет, сформированный в Power BI Desktop, публикуется на портале Power BI и потом, с помощью не простой настройки, встраивается в страницу web-приложения.

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

Компоненты Telerik и RadarCube


Для встраивания компонентов Telerik и RadarCube достаточно владеть программными технологиями на базовом уровне. Поэтому профессиональных навыков одного программиста из IT-отдела будет вполне достаточно. Все что нужно, это разместить компонент на web-странице и настроить их под свои нужды.

Компонент PivotGrid из набора Telerik UI for ASP.NET MVC встраивается на страницу в изящной манере Razor и предоставляет самые необходимые OLAP-функции. Однако, если требуется более гибкие настройки интерфейса и развитый функционал, то лучше использовать компоненты RadarCube ASP.NET MVC. Большое количество настроек, богатый функционал с возможностями его переопределения и расширения, позволят создать OLAP-отчет любой сложности.

Ниже приведу таблицу сравнения характеристик рассматриваемых инструментов по шкале Низкий-Средний-Высокий.

Power BI Telerik UI for ASP.NET MVC RadarCube ASP.NET MVC
Визуализация Высокий Низкий Средний
Набор OLAP-функций Высокий Низкий Высокий
Гибкость настройки Высокий Высокий Высокий
Возможность переопределения функций - - +
Программная кастомизация - - +
Уровень сложности встраивания и настройки Высокий Низкий Средний
Минимальная стоимость Power BI Premium EM3

190 000 руб./месяц
Лицензия на одного разработчика

90 000 руб.

Лицензия на одного разработчика

25 000 руб.


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

Условия выбора Power BI


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

Условия выбора компонентов Telerik


  • Нужен простой OLAP-клиент для Ad hock анализа.
  • В штате компании имеется .NET разработчик начального уровня.
  • Небольшой бюджет на разовую покупку лицензии и дальнейшее ее продление со скидкой менее 20%.

Условия выбора компонентов RadarCube


  • Необходим многофункциональный OLAP-клиент с возможностью кастомизации интерфейса, а также поддерживающий встраивание собственных функций.
  • В штате компании имеется .NET разработчик среднего уровня. Если такого нет, то разработчики компонента любезно предоставят свои услуги, но за дополнительную плату, не превышающую уровня оплаты труда штатного программиста.
  • Небольшой бюджет на разовую покупку лицензии и дальнейшее ее продление со скидкой 60%.

Заключение


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

Перевод Новые метрики объектных хранилищ

12.10.2020 18:16:09 | Автор: admin
Flying Fortress by Nele-Diel

Команда объектного S3-хранилища Mail.ru Cloud Storage перевела статью о том, какие критерии важны при выборе объектного хранилища. Далее текст от лица автора.

Когда заходит речь об объектном хранилище, как правило, люди думают только об одной характеристике цене за ТБ/ГБ. Конечно, эта метрика важна, но она делает подход однобоким и приравнивает объектное хранилище к инструменту для хранения архивов. Плюс такой подход уменьшает важность объектного хранилища для технологического стека предприятия.

Выбирая объектное хранилище, стоит обращать внимание на пять характеристик:

  • производительность;
  • масштабируемость;
  • совместимость с S3;
  • реакция на сбои;
  • целостность.

Эти пять характеристик новые метрики объектного хранилища, наравне со стоимостью. Рассмотрим их все.

Производительность


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

Скорость различных хранилищ приближается к Hadoop или даже превосходит ее. Современные требования к скорости чтения и записи: от 10 ГБ/с для жестких дисков, до 35 ГБ/с для NVMe.

Такой пропускной способности достаточно для Spark, Presto, Tensorflow, Teradata, Vertica, Splunk и других современных вычислительных фреймворков в стеке аналитики. Тот факт, что MPP-базы данных настраивают на объектные хранилища, говорит о том, что оно всё чаще используется как основное хранилище.

Если ваша система хранения не обеспечивает нужную скорость, вы не можете использовать данные и извлекать из них значения. Даже если вы извлекаете данные из объектного хранилища в структуру обработки в памяти, всё равно потребуется пропускная способность для передачи данных в память и из нее. У устаревших объектных хранилищ ее недостаточно.

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

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

Масштабируемость


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

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

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

У мультиклиентности множество характеристик. Хотя параметр говорит о том, как организации предоставляют доступ к данным и приложениям, он также относится и к самим приложениям, и к логике их изоляции друг от друга.

Характеристики современного подхода к мультиклиентности:

  • За короткое время количество клиентов может вырасти с нескольких сотен до нескольких миллионов.
  • Клиенты полностью изолированы друг от друга. Это позволяет им запускать разные версии одного и того же ПО и хранить объекты с различными конфигурациями, разрешениями, функциями, уровнями безопасности и обслуживания. Это необходимо, когда масштабируются новые серверы, обновления и географические регионы.
  • Хранилище эластично масштабируется, ресурсы предоставляются по запросу.
  • Каждая операция управляется API и автоматизируется без участия человека.
  • ПО можно разместить в контейнерах и использовать стандартные системы оркестрации, например Kubernetes.

Совместимость с S3


Amazon S3 API фактически стандарт для объектных хранилищ. Каждый поставщик ПО для объектного хранилища заявляет о совместимости с ним. Совместимость с S3 двоичная: либо она реализована в полном объеме, либо ее нет.

На практике возможны сотни и тысячи пограничных сценариев, когда при использовании объектного хранилища что-то идет не так. Особенно у поставщиков проприетарного ПО и услуг. Его основные сценарии использования прямое архивирование или резервное копирование, поэтому причин для вызова API немного, варианты использования однородны.

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

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

Открытый исходный код означает: приложения не привязаны к поставщику и более прозрачны. Это обеспечивает долгий жизненный цикл приложения.

И еще несколько замечаний насчет открытого исходного кода и S3.

Если вы запускаете приложение для работы с большими данными, S3 SELECT на порядок повышает производительность и эффективность. Это происходит за счет использования SQL для извлечения из хранилища только тех объектов, которые вам необходимы.

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

Наконец, реализация S3 должна поддерживать Amazon S3 API-интерфейсы шифрования на стороне сервера: SSE-C, SSE-S3, SSE-KMS. Еще лучше, если S3 поддерживает защиту от несанкционированного доступа, которая действительно безопасна.

Реакция на сбои


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

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

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

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

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

Отказ редко проверяется под нагрузкой, но такая проверка обязательна. Моделирование сбоя под нагрузкой покажет совокупные затраты, понесенные после сбоя.

Консистентность


Показатель консистентности в 100% также называют строгой консистентностью. Консистентность ключевой компонент любой системы хранения, но строгая консистентность встречается довольно редко. Например, Amazon S3 ListObject не является строго консистентным, он консистентен только в конце.

Что подразумевается под строгой консистентностью? Для всех операций после подтвержденной операции PUT должно выполняться следующее:

  • Обновленное значение видно при чтении с любого узла.
  • Обновление защищено резервированием от сбоя узла.

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

Заключение


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

Об объектном хранилище Mail.ru Cloud Solutions: Архитектура S3. 3 года эволюции Mail.ru Cloud Storage.

Что еще почитать:

  1. Пример event-driven приложения на основе вебхуков в объектном S3-хранилище Mail.ru Cloud Solutions.
  2. Больше чем Ceph: блочное хранилище облака MCS
  3. Работа с объектным S3-хранилищем Mail.ru Cloud Solutions как с файловой системой.
  4. Наш канал в Телеграме с новостями об обновлениях S3-хранилища и других продуктов.
Подробнее..

Конструкторы сайтов в 2020 году что выбрать для бизнеса?

21.10.2020 12:13:27 | Автор: admin


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

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

Ukit




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

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



Плюсы

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

Минусы

  • Большинство сайтов Ukit несколько похожи по структуре друг на друга. Плохого в этом ничего нет, но все же

Стоимость: Цена от $4 в месяц до $12. Пакеты отличаются друг от друга возможностью получить доступ к расширенной статистике, шаблонам, корзинам, настройке интернет-магазина и т.п.

Wix




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



У Wix есть приятная особенность возможность добавления собственного кода JavaScript на сайт Wix и работать с интерфейсами API, чтобы добавить пользовательские функции и взаимодействия на сайт. Для этого Правда, это не кодинг, а, скорее, составление скриптов. Как и в предыдущем случае, у конструктора множество шаблонов. В итоге можно сделать сервис по поиску и продаже авиабилетов, бронирования номеров, продажи музыки и т.п. Страницы можно достаточно глубоко кастомизировать.

Плюсы

  • Функциональный редактор, который дает возможность разрабатывать отличные сайты.
  • Большое количество приложений, для расширения функциональности.
  • Шаблоны, много шаблонов как же без них.
  • Дополнительные инструменты для организации коммуникациями с клиентами и маркетинга.
  • Есть и возможность продажи цифровых товаров, с привязкой к разным сервисам.

Минусы

  • Практически нет, если мы говорим, конечно, об обычном конструкторе сайтов.
  • Есть неочевидные функции (например, расширение пространства макета), которые не прописаны в технической документации, но это не очень большая проблема.

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

Что касается бизнеса, то здесь тарифы другие, от 400 до 1000 рублей в месяц. В последнем случае предоставляется 50 ГБ дискового пространства, предоставляются инструменты веб-аналитики, рекламы в Google Analytics, Google Ads, Яндекс.Директ.

Ucraft




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

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

Плюсы

  • Пользовательские шаблоны.
  • Возможность кастомизации.
  • Есть интерфейс для работы командой.
  • Широкие возможности для интегрирования сторонних продуктов.
  • На домене можно создать разные бесплатные сайты.

Минусы

  • Движок достаточно медленный.
  • Модуль коммерции сторонних разработчиков.
  • Мало шаблонов.

Стоимость: от 670 до 2600 рублей в месяц. В последнем случае в интернет-магазин добавляется возможность продажи товаров на Yandex, eBay, Facebook.

Nethouse




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

У Nethouse есть визуальный редактор, что может понравиться многим пользователям.

Конечный продукт можно интегрировать с Google/Yandex, amoCRM, Travelpayouts и рядом других сервисов. А еще разработчики добавили мобильные приложения для управления сайтов.

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



Плюсы

  • Интуитивно понятный интерфейс.
  • Отличные шаблоны.
  • Большое количество различных функций.
  • Дополнительные возможности.

Минусы

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

Стоимость: два тарифных плана, для сайта и для магазина. В первом случае нужно заплатить 225 рублей в месяц, во втором 488 рублей в месяц. Пользователь получает каталог из 1000+ товаров, нет ограничений на количество фотографий, появляется доступ ко встроенной CRM.

Sitebox




Это относительно новый конструктор сайта от Mail.ru (запущен в 2019 году), предназначен он для малого и среднего бизнеса, когда возникает необходимость быстро и с минимальными усилиями создать сайт или интернет-магазин. Конструктор предоставляет пользователю четыре готовых модели: интернет-магазин, страница продукта или компании, корпоративный сайт и блог. Созданный сайт оптимизирован для работы на мобильных устройствах. Количество шаблонов 350 штук.

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

Для пользователя доступны системы аналитики для отслеживания посещаемости и сбора информации о поведении пользователей, SEO-инструменты и системы оплаты PayPal и Wallet One.



Благодаря тому, что конструктор Sitebox является частью платформы Mail.ru для бизнеса, пользователю конструктора доступны почта для домена, сервисы опросов и рассылок, облачное хранилище и технологии компьютерного зрения.

Плюсы:

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

Минусы:

  • Практически нет

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

Подробнее..

Перевод Почему бессерверная революция зашла в тупик

19.10.2020 22:04:09 | Автор: admin

Ключевые моменты


  • Вот уже несколько лет нам обещают, что бессерверные вычисления (serverless) откроют новую эпоху без конкретной ОС для выполнения приложений. Нам говорили, что такая структура решит множество проблем масштабируемости. На самом деле всё иначе.
  • Хотя многие рассматривают бессерверную технологию как новую идею, её корни можно проследить вплоть до 2006 года, когда появились Zimki PaaS и Google App Engine в обоих случаях используется бессерверная архитектура.
  • Есть четыре причины, по которым бессерверная революция зашла в тупик: от ограниченной поддержки языков программирования до проблем с производительностью.
  • Бессерверные вычисления не так уж бесполезны. Отнюдь нет. Однако их не следует рассматривать как прямую замену серверов. Для некоторых приложений они могут быть удобным инструментом.

Сервер мёртв, да здравствует сервер!


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

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

Некоторые из обещаний для бессерверных моделей, несомненно, были реализованы, но не все. Далеко не все.

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

Что обещали адепты бессерверных вычислений


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

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

  1. Бессерверные модели не требуют, чтобы пользователи поддерживали собственные операционные системы или даже создавали приложения, совместимые с определёнными ОС. Вместо этого разработчики создают общий код, загружают его в бессерверную платформу и наблюдают за его выполнением.
  2. Ресурсы в бессерверных фреймворках обычно оплачиваются по минутам (или даже секундам). Это означает, что клиенты платят только за то время, когда они фактически выполняют код. Это выгодно отличается от традиционной облачной VM, где машина большую часть времени простаивает, но за неё приходится платить.
  3. Проблема масштабируемости также решалась. Ресурсы в бессерверных фреймворках назначаются динамически, так что система легко справляется с внезапными всплесками спроса.

Короче говоря, бессерверные модели обеспечивают гибкие, дешёвые, масштабируемые решения. Удивительно, что мы не додумались до этой идеи раньше.

Это действительно новая идея?


На самом деле идея не нова. Концепция, позволяющая пользователям платить только за то время, когда код фактически запускается, существует с тех пор, как она была введена в рамках Zimki PaaS в 2006 году, и примерно в то же время Google App Engine предложил очень похожее решение.

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

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

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

Проблемы бессерверных моделей


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

Вот почему.

Ограниченная поддержка языков программирования


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

Считается, что бессерверные платформы поддерживают большинство основных языков. AWS Lambda и Azure Functions также предоставляют оболочку для запуска приложений и функций на неподдерживаемых языках, хотя это часто сопряжено с затратами на производительность. Так что для большинства организаций обычно это ограничение не имеет большого значения. Но вот в чём дело. Предполагается, что одно из преимуществ бессерверных моделей в том, что малоизвестные, редко используемые программы можно использовать дешевле, поскольку вы платите только за время их выполнения. А малоизвестные, редко используемые программы часто пишутся на малоизвестных, редко используемых языках программирования.

Это подрывает одно из ключевых преимуществ бессерверной модели.

Привязка к вендору


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

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

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

Производительность


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

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

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

Другой подход заключается в том, чтобы обеспечить регулярное выполнение критически важных для производительности программ, чтобы они оставались свежими. Этот второй подход, конечно, немного противоречит утверждению, что бессерверные платформы более экономичны, потому что вы платите только за время работы ваших программ. Облачные провайдеры внедрили новые способы сокращения холодных запусков, но многие из них требуют масштабирования до одного (scale to one), что подрывает первоначальную ценность FaaS.

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

Вы не можете запускать целые приложения


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

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

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

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

Да здравствует революция?


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

Перевод Ускоряем разработку для Cloud Run с помощью Cloud Code

13.10.2020 10:19:44 | Автор: admin

При разработке сервисов для полностью управляемой контейнерной платформы Cloud Run, вы, скорее всего, быстро устанете постоянно переключаться между редактором кода, терминалом и Google Cloud Console. Мало того, вам ещё придется по много раз, при каждом развертывании, выполнять одни и те же команды. Cloud Code это набор инструментов, включающий все необходимое для написания, отладки и развертывания облачных приложений. Он повышает эффективность разработки в Google Cloud за счет использования плагинов для популярных сред разработки, таких как VS Code и IntelliJ. С его помощью вы сможете легко заниматься разработкой в Cloud Run. Подробнее под катом.


Интеграция Cloud Run и Cloud Code упрощает создание новых сервисов Cloud Run в привычной для вас среде разработки. Вы сможете запустить сервисы на локальном компьютере, быстро выполнить их итерацию и отладку, а затем развернуть в Cloud Run, легко управлять ими и обновлять их.


Примечание от автора. На виртуальной конференции Google Cloud Next 2020 OnAir мы анонсировали несколько новых функций и сервисов, призванных ускорить процесс доставки и разработки приложений, а также платформу Cloud для модернизации приложений (Cloud Application Modernization Platform или CAMP).

Создание новых сервисов Cloud Run


На первый взгляд контейнеризация и бессерверные сервисы могут казаться чересчур сложными. Если вы только начинаете знакомиться с Cloud Run, обратите внимание на обновленный список примеров Cloud Run в Cloud Code. Примеры доступны на языках Java, NodeJS, Python, Go и .NET. Опираясь на них, вы сможете сразу приступить к написанию собственного кода с учетом всех рекомендаций.
Все примеры включают файл Dockerfile, чтобы вам не пришлось тратить время, разбираясь в конфигурациях контейнеров. Если вы переносите в Cloud Run существующий сервис, то, возможно, вы ещё не работали с файлами Dockerfile. Ничего страшного! В сервисе Cloud Code есть поддержка объектов Google Cloud Buildpack, позволяющих контейнеризовать сервис прямо в коде. Файл Dockerfile при этом не требуется. Cloud Code содержит все необходимое для развертывания вашего сервиса в Cloud Run.



Разработка и отладка сервисов Cloud Run в локальной среде


Прежде чем развернуть сервис в Google Cloud, вы, скорее всего, захотите попробовать его на своем компьютере, чтобы посмотреть, как он работает, внести необходимые правки и отладить ошибки. При разработке сервисы Cloud Run необходимо постоянно собирать и развертывать в облаке, чтобы тестировать изменения в репрезентативной среде Cloud Run. Отладить код можно и локально, подключив отладчик, однако, поскольку это осуществляется не на уровне всего контейнера, вам придется устанавливать инструменты локально. Запустить контейнер в локальной среде можно с помощью Docker, но команда, необходимая для этого, слишком длинна и не отражает особенности производственной среды.


В Cloud Code имеется эмулятор Cloud Run, позволяющий разрабатывать и отлаживать сервисы Cloud Run локально. Согласно исследованию, проведенному DevOps Research and Assessment (DORA), у команд, показавших высокую эффективность поставки ПО, сбои при внесении изменений случались в 7 раз реже, чем у менее эффективных команд. Благодаря возможности быстро выполнять итерацию кода локально и отлаживать его в репрезентативной среде, вы можете оперативно находить ошибки на ранних этапах разработки, а не во время непрерывной интеграции или, того хуже, в продакшене.


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


Первый запуск Cloud Run Emulator:

Отладка сервисов Cloud Run с помощью Cloud Code осуществляется так же, как в привычной вам среде разработки. Выполните команду "Debug on Cloud Run Emulator" в среде VS Code (или выберите конфигурацию "Cloud Run: Run Locally" и выполните команду "Debug" в среде IntelliJ) и просто установите точки останова кода. Как только точка останова будет активирована в вашем контейнере, вы сможете переключаться между командами, наводить курсор на свойства переменных и проверять журналы из контейнера.


Отладка сервиса Cloud Run с помощью Cloud Code в VS Code и IntelliJ idea:


Развертывание сервиса в Cloud Run


После того как вы протестируете в локальной среде все изменения, внесенные в код для сервиса Cloud Run, останется создать контейнер и развернуть его в Cloud Run.


Развернуть сервис из среды разработки не составит никакого труда. Мы добавили все параметры, необходимые для настройки сервиса перед развертыванием. Когда вы нажмете "Развернуть", Cloud Code выполнит все требуемые команды, чтобы создать образ контейнера, развернуть его в Cloud Run и передать URL-адрес сервису.


Развертывание сервиса в Cloud Run:

Управление сервисами Cloud Run


Благодаря Cloud Code в VS Code можно просматривать журналы версий и сервисов одним нажатием. Эта функция была перенесена из Cloud Console в среду разработки, чтобы вам не приходилось постоянно переключаться. На странице просмотра отображаются именно те журналы, которые имеют отношение к версиям и сервисам, выбранным в проводнике Cloud Run.



Кроме того, в проводнике Cloud Run можно быстро найти и просмотреть сведения обо всех управляемых сервисах Cloud Run и сервисах Cloud Run для Anthos в нужном проекте. Там же можно легко узнать, какой процент трафика перенаправляется и сколько выделено ресурсов ЦП.


Cloud Run explorer в VS Code и IntelliJ


Нажав на версию правой кнопкой мыши, можно посмотреть URL-адрес сервиса. В Cloud Console можно проверить трафик или настроить его перенаправление между сервисами.


Начало работы


Приглашаем вас поработать с Cloud Code в Cloud Run, чтобы оптимизировать процессы развертывания сервисов и ведения журналов. Дополнительные сведения можно найти в документации по Cloud Run для сред разработки Visual Studio Code и JetBrains. Если вы ещё не работали с этими средами, для начала установите Visual Studio Code или IntelliJ.


Присоединяйтесь к Google Cloud Next OnAir


Также хотелось бы напомнить нашим читателям, что прямо сейчас проходит онлайн конференция Google Cloud Next OnAir EMEA для которой мы подготовили контент как для разработчиков, так и для архитекторов решений и руководителей.


Более подробно узнать о сессиях, спикерах и получить доступ к контенту можно бесплатно зарегистрировавшись на странице Next OnAir EMEA. Вместе с уникальным контентом, который будет представлен для Next OnAir EMEA вы также получите полный доступ к более чем 250 сессиям с глобальной части Google Cloud Next 20: OnAir.

Подробнее..

Публичные облака в российских реалиях. Часть 1. IaaS

24.10.2020 12:06:33 | Автор: admin


Облачные технологии, инфраструктура как сервис и платформенные сервисы из нишевых решений давно перешли в стандарт де-факто для размещения приложений не только стартапов, но и крупных финансовых компаний, госкомпаний, автомобильных гигантов и популярных игровых сервисов. Компании Netflix и Spotify, Dropbox и Instagram начинали свой путь на облачных ресурсах, не инвестируя в собственную инфраструктуру. Совокупная выручка мировых поставщиков облачных услуг в 2019 году превысила бюджет Российской Федерации. В этой статье мы рассмотрим рынок облачных услуг в России. Мы сравним его с мировыми трендами и определим опережаем мы или отстаём от мировых лидеров в развитии облачных услуг и насколько.

Как все начиналось


Публичные облака в РФ появились как эволюционное развитие собственной инфраструктуры виртуализации. Следуя за трендами в корпоративном сегменте, они были основаны на привычных крупным заказчикам технических решениях, таких как Microsoft Hyper-V и VMware vSphere, c установкой портала самообслуживания (Windows Azure Pack или vCloud Director for SP). Клиенты получали понятный им функционал: знакомые инструменты управления, мониторинга и резервного копирования всё, с чем клиенты работали каждый день.

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

Инфраструктура, обеспечивающая ресурсы платформы виртуализации, должна быть в списке совместимой и поддерживаемой. Для этого чаще всего используются серверы именитых производителей (Dell EMC, HPE, Lenovo, Huawei и др.) и выделенные СХД, подключаемые как блочные устройства по протоколу FС. Приобретение и поддержка такой инфраструктуры это основная статья затрат в эксплуатации облачной платформы. Функционал и развитие облачной платформы целиком определяется выбранным вендором.

Параллельно стали появляться публичные облака, как эластичная инфраструктура, от нетипичных игроков на рынке из таких индустрий, как retail (Amazon), e-commerce (Alibaba) и интернет (Google).

Используя наработки на базе собственных on-premise технологий, в популярного поставщика облачных услуг превратилась компания Microsoft с их платформой Azure.

Большинство игроков частично использовали решения open-source. Например, Amazon использовал гипервизор Xen, а сейчас переключился на KVM. Кто-то использовал платформу с открытым исходным кодом OpenStack, дорабатывая ее под свои нужды.

Запуск решения на базе готовой платформы с открытым исходным кодом позволяет сократить время выхода на рынок, особенно если нет достаточно зрелых технологий, на базе которых можно построить собственную инфраструктуру. Вокруг популярной платформы обычно довольно зрелая экосистема с необходимым набором утилит для организации DevOps конвейера, мониторинга, автоматизации и оркестрации. Такой платформой можно считать Mail.ru Cloud Solutions (MCS) на базе Openstack.

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

Немного о сравнении


Мы сравним эти два подхода к построению облачной инфраструктуры от компаний Mail.ru Group и Яндекс. Остановимся только на ключевых отличиях и посвятим сравнению цикл статей. В первой статье мы начнем с IaaS, во второй статье планируем остановиться на сетевых сервисах и PaaS, в третьей на SaaS, мониторинге и сервисной поддержке.

Почему здесь только Яндекс.Облако и MCS?
Мы ограничили состав участников сравнения указанными платформами, потому что они соответствуют нашему представлению о современном поставщике облачных услуг, которое заключается в следующих критериях:

  • Разработка платформы производится собственными силами с минимальным использованием корпоративных вендорских решений, например, VMware vCloud Director и др.
  • Наличие единого портала самообслуживания, из которого можно управлять всеми услугами IaaS, PaaS и SaaS, в том числе и производить их оплату.
  • Подключение услуг IaaS, PaaS и SaaS производится клиентом без дополнительного взаимодействия с представителями поставщика.
  • Возможность полноценного управления платформой без графического интерфейса для задач автоматизации управления инфраструктурой и построения конвейера DevOps.
  • Документация по платформе, стоимость и калькулятор услуг опубликованы на сайте поставщика.
  • Наличие современных сервисов таких, как ML, AI, serverless, Big Data и др.


На каждом этапе сравнения будем брать ориентир на облачную платформу Microsoft Azure. Это поможет нам понять, насколько компании Яндекс и Mail.ru Group приблизились в технологическом аспекте к одному из мировых лидеров в области предоставления облачных услуг.

Почему выбрали Azure?
Вместо Microsoft Azure могла быть любая другая платформа из крупных игроков. Мы предпочли ее по двум причинам:

  • Azure зрелая платформа для Enterprise решений. Она сертифицирована на работу с SAP HANA и обладает большим количеством популярных сервисов в корпоративной среде.
  • Azure оперативно внедряет все свежие тренды и технологии (например, Azure Kubernetes (AKS), собственные решения DevOps, собственные решения Azure serverless и др.).


ЦОД


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


Рис. 2. Архитектура ЦОД ближайшего к России региона Azure

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

Важным преимуществом платформ MCS и Яндекс.Облако по сравнению с Microsoft Azure является наличие дата-центов на территории Российской Федерации. Если ваш сервис должен соответствовать требованиям Федерального закона О персональных данных (ФЗ-152), то развертывание его в облаке от зарубежного поставщика потребует внедрения дополнительных технических решений, так как первичная обработка персональных данных (ПДн) должна происходить на территории Российской Федерации и в дальнейшем данные должны передаваться по защищенным каналам связи. Невыполнение требований о защите ПДн может привести к блокировке доступа к сервису Роскомнадзором.


Рис. 3. Архитектура ЦОД платформы MCS

Облачная платформа от Mail.ru Group размещена на территории города Москвы в двух арендованных дата-центрах: DataLine на Коровинском шоссе и DataPro на Авиамоторной улице. Последний имеет сертификацию Uptime Institute. Между дата-центрами организован канал 40 Гбит/с с длиной трассы около 25 км. Это позволяет нам рассматривать оба дата-центра, как площадки для построения высокодоступных (High-Availability) кластеров с узлами в каждом из дата-центров с синхронной репликацией данных между ними, но без так называемой кворум площадки.

Сетевая архитектура облака имеет растянутые L2 сети между площадками. Это дает нам возможность использовать технические средства отказоустойчивости: Keepalived, Veritas Cluster Server, Microsoft Windows Server Failover Cluster и прочие. Такие средства увеличивают наши шансы на миграцию большинства legacy решений в IaaS данного поставщика. При этом мы сохраняем отказоустойчивость архитектуры, которую мы использовали на собственном оборудовании on-premise.

Арендованные ЦОД позволяют MCS предоставить дополнительный сервис для клиентов, когда поставщик облачных услуг предоставляет в аренду различное оборудование для клиента с подключением его к облачной платформе.

Почему это является преимуществом?
При отсуствии официальной сертификации платформы под SAP HANA, компания Mail.ru Group может установить по запросу клиента сертифицированные SAP HANA Appliance и подключить их к клиентскому VPC внутри облака MCS. Это позволит не потерять поддержку на продуктивные среды SAP продуктов и воспользоваться всеми преимуществами облачной инфраструктуры для остальных сред.
Аналогичным примером может быть установка оборудования для организации защищенных каналов связи с помощью национальных стандартов криптографии (например, алгоритмов шифрования ГОСТ Р 34.12-2015).

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

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


Рис. 4. Архитектура ЦОД платформы Яндекс.Облако

Облако от компании Яндекс в свою очередь размещено в трех собственных дата-центрах, расположенных в Московской, Владимирской и Рязанской областях. Каждый ЦОД проектировался и строился самостоятельно. Яндекс эксплуатируют их с соблюдением международных и собственных стандартов. Надо отметить, что опыт в построении дата-центов у Яндекса действительно имеется.

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

Три полноценные площадки позволяют разворачивать любые отказоустойчивые архитектуры. Однако большая удаленность, порядка 200 км друг от друга, не позволяет развернуть кластера высокой доступности (High-Availability) с узлами в каждом из дата-центров с возможностью синхронной репликации данных между ними. Также отсутствие L2 между дата-центрами ограничивает нас в возможности развернуть здесь legacy решения.

Архитектура IaaS платформы


Модель обслуживания Infrastructure-as-a-Service (IaaS), как описано в стандарте NIST, это возможность предоставить клиенту вычислительные, сетевые ресурсы и ресурсы хранения данных, на базе которых клиент сам размещает и управляет операционными системами и приложениями. Современная IaaS платформа включает в себя гипервизор, предоставляющий вычислительные ресурсы, программно-определяемую систему хранения данных software-defined storage (SDS) для размещения данных и программно-определяемую сеть software-defined networking (SDN) как средство организации сетевого доступа к ресурсам IaaS.

Референтная платформа нашего сравнения, Azure от компании Microsoft, начинает свою историю еще в далеком 2003-м году с приобретения компании Connetix и их продукта Virtual PC с целью догнать конкурента VMware и их продукт GSX Server, вышедший двумя годами ранее. Спустя время продукт Virtual PC интегрировали в состав платформы Windows Server. Он появился в версии 2008, но только к версии 2012 были реализованы SDS на базе Scale-Out File Server и Storage Spaces и SDN на базе Hyper-V Network Virtualization. Это позволило построить целиком программно-определяемую платформу IaaS без привязки к аппаратным возможностям СХД или оборудования ЛВС.

Платформа Azure поддерживается большинством современных DevOps утилит как для построения конвейера непрерывного развертывания, так и для автоматизации рутинных задач. У Azure функциональный веб-интерфейс и подробно документированный API. Все крупные игроки по разработке платформ автоматизации и управления облачными платформами поддерживают Azure. Утилита командной строки Azure CLI доступна как расширение PowerShell и как отдельная утилита для платформ Windows, Linux и MacOS X.

Компания Mail.ru Group для своего облака взяла наработки платформы OpenStack. К 2020 году компания перешла на полностью собственный дистрибутив, который не связан с open-source версией платформы. В качестве гипервизора используется функция ядра ОС Linux Kernel-based Virtual Machine (KVM), основным разработчиком которого является компания Red Hat, ныне часть IBM. Объем доработок KVM, которые выполнили разработчики MCS, компания не раскрывает. В части SDS для блочных устройств и сервиса NFS используется решение CEPH его тоже дорабатывала команда MCS. Для объектного хранилища S3 были переиспользованы технологии облачного диска Mail.ru Group. В качестве сетевого решения применяется решение на базе OpenvSwitch, однако механизмы управления Control plane были серьезно переработаны. Это дало жизнь проекту Sprut.

Для управления платформой MCS был реализован отдельный портал, в котором реализованы самые популярные сервисы, а также доступен нативный интерфейс OpenStack Horizon. Для тонкой настройки сервисов предоставляется доступ к OpenStack CLI или OpenStack API. Есть также возможность использовать решение Infrastructure as Code (IaC) которое будет обращаться напрямую к API платформы. Работу с OpenStack поддерживает большинство систем управления конфигурацией, что упрощает встраивание облака MCS в DevOps конвейер и внешние системы управления облачными ресурсами.

Как было у Яндекса? Первую версию своей платформы компания разрабатывала для себя. Яндекс, так же, как и Mail.ru Group ориентировался на архитектуру и компоненты OpenStack. Однако, потом компания отказалась от нее. Было принято решение начать с чистого листа. Яндекс переиспользовал базовые инфраструктурные компоненты, которые у них уже были. К ним компания дополнительно разработала недостающие модули и платформу управления.

В качестве гипервизора компания Яндекс также использует KVM. В его разработку инвестированы большие ресурсы. Решения SDS и SDN были разработаны компанией самостоятельно. SDS основан на собственной СУБД Yandex Database (YDB) для хранения мета-данных о размещении виртуальных машин и Network Block Storage (NBS) как сервиса предоставления блочных устройств виртуальным машинам, также YDB используется и в S3-совместимом решении в составе платформы. Яндекс, в отличии от MCS и Azure, не предлагает сервис NFS в составе услуг, рекомендуя развернуть его на базе виртуальной машины. В качестве SDN используется переработанная платформа OpenContrail. Её разрабатывали Juniper Networks, которая с недавнего времени входит в Linux Foundation, как платформа TungstenFabric.

Использование собственной платформы управления ограничивает возможности по встраиванию ресурсов Яндекс.Облака в конвейер DevOps или внешние системы управления облачными ресурсами. В настоящий момент заявлена поддержка IaC Terraform с помощью разработанного компанией провайдера. Ещё существует неофициальная поддержка работы с Ansible. Однако, среди популярных систем для управления Гибридными Облаками (Cloud Management Platforms) таких как Red Hat CloudForms, Morpheus, Scalr, поддержка отсутствует. Компания также разработала и поддерживает свою собственную утилиту YC CLI для работы с платформой из командной строки с собственным набором команд.

Хранение данных


У MCS есть репликация блочных устройств между зонами доступности, что позволяет запустить виртуальную машину с теми же данными на любой из площадок, а также получить высокопроизводительный локальный диск NVMe или общее СХД по протоколу ISCSI. Azure предлагает репликацию объектных хранилищ как внутри зоны доступности, так и между зонами в пределах географического региона, а также сервис Azure Site Recovery для репликации блочных устройств. Обе платформы предоставляют сервис NFS.

В платформе Яндекс.Облако нет синхронной репликации блочных устройств между зонами доступности. Реплицируются только резервные копии и S3-хранилище. Репликация данных для Яндекс.Облака может быть реализована средствами приложения или СУБД. Отсутствие репликации блочных устройств связано с тем, что ЦОДы располагаются достаточно далеко и синхронная репликация будет вносить значительные задержки в дисковый ввод-вывод. Сервис NFS платформой Яндекс.Облако не предоставляется.

Образы виртуальных машин


В отличие от Azure, в MCS отсутствует возможность развернуть ВМ с использованием enterprise-level дистрибутива ОС Linux (RHEL, SLES, OEL). Платформа Яндекс.Облако позволяет развернуть ВМ с ОС RHEL версии 7.8, но подписку клиент должен оформлять самостоятельно через стороннюю организацию.

Оба провайдера поддерживают загрузку собственных образов ОС. Яндекс поддерживает форматы qcow (qemu), vhd (Microsoft Hyper-V/Azure) и vmdk (VMware ESXi), но отсутствует возможность импорта ova/ovf формата. MCS поддерживает загрузку формата RAW, для которого требуется конвертация с помощью стандартной утилиты из пакета Qemu. Ещё он поддерживает конвертацию на лету при загрузке через веб-интерфейс портала. Azure позволяет загружать собственные образы в формате VHD (формат Hyper-V).

SLA


Уровни SLA отличаются между платформами. MCS и Azure предоставляют SLA в рамках доступности на каждый из облачных сервисов, а также на отдельные параметры внутри сервиса например, на IOPS для блочных устройств. Яндекс же оперирует только доступностью сервиса, не включая характеристики отдельных компонент. Все провайдеры компенсируют часть счета на услуги в зависимости от времени простоя сервиса. Яндекс отдельно упоминает о возможности полной компенсации платежей в случае потери данных клиента.

IAM


Все платформы предоставляют сервис управления учетными записями и правами Identity and Access Management (IAM).

Яндекс для этого требует наличия учетной записи в сервисе Яндекс.Паспорт или интеграцию с внешним провайдером учетных записей посредством протокола SAML, например, AD FS, и позволяет управлять квотами и правами в контексте облачных услуг.

Компания Mail.ru Group расширила функционал, заложенный в IAM для Openstack в части работы с собственным сервисом S3, и близка по возможностям к сервису платформы Яндекс.Облако.

Обе платформы не предполагают сценариев интеграции IAM для собственных приложений клиента.

Наиболее богатый функционал IAM у Azure. Кроме управления облачной инфраструктурой есть возможность получить Active Directory, как услугу. Есть возможность использовать IAM для интеграции с приложениями в облаке для управления учетными записями клиентов компании. Все платформы поддерживают управление собственными SSH ключами для Linux систем.

Управляемые сервисы VPN и DNS


Для полноценного использования платформы IaaS нам требуются такие сервисы, как Managed VPN и Managed DNS. Azure позволяет управлять внешними и внутренними DNS зонами, обычными или техническими DNS записями, а также автоматически регистрировать новые DNS записи при создании ВМ. В MCS функционал ограничен созданием внутренней DNS зоны и автоматической регистрацией ВМ в ней, с возможностью создания произвольного имени или же привязки DNS-записи к сетевому порту (IP адресу), но без возможности управления техническими записями. В платформе Яндекс.Облако отсутствует возможность управлять записям DNS.

Если говорить об организации защищенного подключения и пиринга, то наиболее полный функционал у Azure. В нём есть поддержка режимов client-to-site, site-to-site и прямого пиринга по протоколу BGP. Пропускная способность VPN-линка к Azure ограничивается оконечным оборудованием клиента. MCS поддерживает только режим site-to-site для протокола IPSec. Яндекс только технологию прямого соединения (название сервиса Yandex.Cloud Interconnect) по протоколу BGP. Для организации защищенного канала VPN к платформе Яндекс.Облако потребуется развернуть Cisco CSR, Mikrotik CHR или другое VPN решение из маркетплейса.

On-Premise решение для частного облака


Все поставщики облачных услуг предоставляют возможность развертывания своей платформы на оборудовании заказчика (on-premise). Частное облако может быть интегрировано с публичной платформой от данного поставщика для организации гибридного решения с единым порталом управления, репликацией машин и Disaster Recovery площадкой в публичном облаке. Есть отличие предоставления сервиса и вот в чём оно состоит. Microsoft и Яндекс поставляют собственные решения в виде готового к установке в ЦОД оборудования. Компания Mail.ru Group может поставить свое решение на оборудование клиента, совместимого с их платформой.

Итоги сравнения


Подведём итоги сравнения платформ MCS и Яндекс.Облако в части IaaS. Производители данных решений не до конца реализовали весь функционал, необходимый для полноценного перехода инфраструктуры клиента на их сервисы. Отсутствие или недостаточная реализация функционала таких сервисов, как VPN и DNS, требует от клиента наличия своей собственной команды для их поддержки. Это создаёт технический долг, который компании обещают закрыть.

Основные отличия между платформами кратко:


Сравнивая функционал у обоих игроков, оценим его как почти равный. Разве что MCS выглядит более зрелым игроком. На это две причины: разница в возрасте, около полутора лет с момента запуска, и использование наработок из эко системы Openstack. С другой стороны в мире не так много крупных облачных сервисов, построенных на базе Openstack. Если развитие данной платформы будет приостановлено, то компания Mail.ru Group будет вынуждена продолжать разработку в одиночку, будучи скованной архитектурными паттернами родительской платформы Openstack.

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

Непрерывность бизнеса. Решения SAP в Microsoft Azure виртуальное мероприятие

07.10.2020 10:05:19 | Автор: admin


13 октября приглашаем вас принять участие в виртуальном мероприятии Решения SAP в Microsoft Azure. В рамках мероприятия мы предложим вам по-новому посмотреть на размещение решений SAP в облаке Azure. Вы узнаете, почему переход на SAP S/4HANA в Azure идеальный старт для реализации вашей облачной стратегии и как данное решение позволит снизить затраты, повысить гибкость бизнеса и стимулировать инновации.

Регистрация

Под катом немного подробностей.

  • Ускоренное внедрение инноваций при помощи SAP S/4HANA.
  • Трансформация среды SAP с применением Azure.
  • История успеха: каким образом Microsoft и SAP использовали SAP S/4HANA в Azure для трансформации собственных бизнес-процессов.
  • Выступление специальных гостей: выгода от переноса своих систем и приложений SAP в Azure.
  • Microsoft Azure на базе новейших технологий Intel, созданных для SAP S/4HANA.

13 октября 2020
Начало в 10:00 (по Московскому времени)

Будем рады вас видеть на виртуальном мероприятии Решения SAP в Microsoft Azure!

Регистрация
Подробнее..

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

28.10.2020 12:04:04 | Автор: admin

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

Когда в начале 2020 года разразилась пандемия COVID-19, организациям здравоохранения пришлось менять или ускорять свои планы по обслуживанию пациентов. Американская Commonwealth Care Alliance (CCA) использовала облачную аналитику данных, чтобы связать врачей и специалистов по медицинскому обслуживанию с участниками из группы риска. Вице-президент Валмик Кудесиа CCA, ответственный за клиническую информатику и передовую аналитику CCA, делится их историей.

CCA это медицинская организация, признанная на национальном уровне лидером в предоставлении и координации дорогостоящего ухода за нуждающимися людьми, которые имеют право на программы Medicaid и Medicare. CCA выполняет обязанности плательщика медицинских услуг, управления медицинским обслуживанием и непосредственно поставщика этих услуг пациентам. Подопечные CCA живут с проблемами со здоровьем, поведением и социализацией. У многих из них сложные жизненные условия, они уязвимы и маргинализированы. Когда зимой в США пришла новость о COVID-19 в организации быстро осознали, что этой категории людей понадобится особенно много заботы и внимания. Сотрудникам CCA необходимо было продолжать выполнять свои обязанности, учитывая множество новых, постоянно меняющихся факторов.

Нам требовались надёжные данные, которые можно было быстро получить, и которые были бы интегрированы в их рабочие процессы. CCA заранее создала облачную платформу расширенной аналитики с BigQuery и Looker. Спустя шесть месяцев, убедившись в надёжности и работоспособности решения, мы продолжаем предоставлять клиницистам более целостное представление о потребностях нуждающихся людей. CCA развивает ориентированное на человека использование данных и аналитики, чтобы справиться с предстоящим сезонным комбо сочетанию COVID-19 и гриппа.

Данные, необходимые для более быстрого принятия решений

Облачная платформа была создана для ситуаций, когда пользователи должны двигаться быстро и в разных направлениях, а также менять параметры запрашиваемой информации. Это означало, что когда пришёл COVID-19, CCA не пришлось многое менять в своих процессах.

Группа по анализу данных использовала Looker и BigQuery в сочетании с другими технологиями, чтобы выполнять разработку и развёртывание операций обработки данных в сочетании с возможностями машинного обучения. Облачные сервисы соответствовали требованиями HIPAA (своего рода аналог нашего ФЗ-152, но с медицинским уклоном прим. переводчика), а BigQuery был (и остаётся) эластичным и доступен как услуга. Это позволило небольшой команде по анализу данных сосредоточиться на работе с данными и быстро развивать проект, сохраняя его совместимость и обеспечивая отличную производительность платформы.

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

Сотрудники CCA могли двигаться вместе с клиницистами, формируя данные и прогнозы с помощью общих панелей мониторинга и панелей мониторинга для конкретных задач, называемых Action boards. Эти доски не просто информируют пользователей, они предлагают информацию, необходимую для принятия решения о том, какие что врач будет делать дальше.

Использование ежедневных и даже почасовых данных, поступающих из разных источников, было необходимо для того, чтобы слабо защищённые слои населения могли получить то, что им нужно еду на дом, лекарства или другие услуги. В некоторых случаях у нас уже имелись все необходимые данные. Например, менее чем за 30 минут удалось внедрить определение высокого риска осложнений COVID-19, разработанное CDC, в LookML (слой абстракции запросов Looker) и связать понятие осложнения COVID-19 с высоким риском с нашей информационной моделью.

Также в течение рабочего дня мы создали наши основные информационные панели мониторинга COVID-19 и внедрили соответствующие данные о пандемии в другие клинические дашборды и Action boards. Гибкость решения, достигаемая за счёт абстракции и быстрой доставки данных, позволила нам быстро идентифицировать каждого человека с высоким риском неблагоприятного исхода COVID-19 и предоставить эти знания врачам CCA.

Некоторые из нужных данных получить было непросто. Например, в начале эпидемии не было репозиториев данных COVID-19 или сервисов передачи этих данных. Было важно собирать все возможные данные для обслуживания нуждающихся групп людей. И во многих случаях мы собирали использовали эти данные самостоятельно. Например, на ранних стадиях пандемии COVID-19 в Массачусетсе постепенно начали закрываться дневные центры здоровья для взрослых (ADH), общественные центры, которые предоставляют важные услуги для пожилых людей, а затем внезапно это приняло массовый характер. Но мы наловчились передавать эти знания каждому человеку, посещавшему эти учреждения, буквально спустя несколько минут после того, как узнавали про очередной закрытый ADH. Чуть позднее в CCA стали поступать данные Департамента общественного здравоохранения Массачусетса о положительных тестах, что позволило получить представление о концентрации людей из группы риска, проживающих в районах с высокой или растущей заражаемостью COVID-19.

Путь от просто данных к важнейшему элементу для лечения и поддержки

Поскольку пандемия COVID-19 продолжается, мы используем самую свежую доступную информацию, чтобы обновлять и менять стратегии поддержки и ухода за подопечными. Сотрудникам CCA стало намного удобнее работать с данными благодаря облаку. Обычно у нас более 450 активных пользователей в неделю, и сведения запрашиваются чуть ли не ежесекундно в течение рабочего дня. Благодаря большой собранной базе можно заметить, как часть данных соответствует общей картине или не вписывается в неё. Вместо того, чтобы использовать данные как отдельные кусочки мозаики, мы используем их комплексно. То есть благодаря построенному на облачной платформе решению мы используем данные в интересах пациентов, встроили новую технологию в свою повседневную жизнь.

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

Ретроспектива решений на основе данных

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

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

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


Что ещё интересного есть в блогеCloud4Y

Найдено давно утерянное руководство к самому старому компьютеру в мире

Пограничный патруль США планирует 75 лет хранить данные из гаджетов путешественников

Определённо не Windows 95: какие операционные системы поддерживают работу в космосе?

Рассказываем про государственные защищенные сервисы и сети

Внутри центра обработки данных Bell Labs, 1960-е

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

Подробнее..

Как технологии помогают медикам укреплять отношения с пациентами

14.10.2020 10:20:11 | Автор: admin

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


Цифровые инструменты использовались в здравоохранении и раньше, нопандемия показала необходимость резко ускорить их широкое внедрение.Многие врачи перешли на виртуальные телеконсультации по некритичным вопросам, а также для оценки пациентов с симптомами COVID-19 на безопасном расстоянии. Новые технологии, такие как искусственный интеллект (ИИ) и автоматизация роботизированных процессов (RPA), в нынешних условиях приобретают еще большее значение, учитывая их способность взять на себя многие административные и подготовительные задачи для обеспечения высокого стандарта оказания медицинской помощи. Исследованияпоказали уверенность врачей в том, что основанные на ИИ решения могут оказать им существенную поддержку в выполнении их основных обязанностей по диагностике, лечению, направлению пациента к нужному специалисту или уходу за больными. Медики также готовы принять более широкую автоматизированную поддержку и в выполнении других административных задач, таких как определение очередности оказания помощи и обработка результатов тестов.

Польская телемедицинская компанияTelemedicoдемонстрирует этот потенциал в действии, предоставляя пациентам возможность связаться с врачами в режиме персонального видеозвонка или конфиденциального чата для обсуждения вопросов здоровья. Хотя компания Telemedico работала еще до начала пандемии, в марте количество онлайн-консультаций утроилось, достигнув 100 000 обращений. Чтобы помочь удовлетворить возросший спрос, более 500 врачей повысили свою квалификацию, получив навыки управления виртуальной клиникой, и смогли улучшить свое взаимодействие с пациентами в онлайн-режиме с начала пандемии COVID-19.

Этот сервис позволяет врачам еженедельно поддерживать связь с пациентами либо с помощью быстрых сообщений в чате, либо с помощью звонка. Для пациентов, страдающих тяжелыми заболеваниями, это особенно актуально.
Моника Любекка, главный операционный директор Telemedico.

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

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

В отличие от Telemedico, для которой телемедицина всегда являлась основой бизнеса, румынская сеть здравоохраненияREGINA MARIAбыла более традиционной и только в марте 2020 года в ответ на пандемию запустила своювиртуальную службу оказания медицинской помощи. Всего за десять дней клиника разработала и внедрила решение, которое идеально интегрируется с существующими системами и использует Microsoft Teams для проведения виртуальных приемов. Этот сервис позволил клинике быстро обеспечить непрерывность оказания медицинской помощи и постоянный уход за своими пациентами.


В течение трех недель более 500 специалистов, которые обучились навыкам работы в Microsoft Teams и Microsoft 365, осматривали пациентов в режиме онлайн. На сегодняшний день в виртуальной клинике проведено почти 60 000 приемов и обследовано более 25 000 пациентов.

Опыт работы с виртуальной клиникой оказался положительным, и большинство врачей намерены продолжить оказание некоторых консультативных услуг, таких как, например, интерпретация результатов тестов, дистанционно. Возможность выполнять часть своей работы, не выходя из дома, также существенно улучшила баланс между работой и личной жизнью.
Габи Хербей, директор по информационным технологиям, REGINA MARIA.

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

Автоматизация роботизированных процессов (RPA) это технология, которая использует программные роботы для автоматизации большого количества повторяющихся задач. Она берет на себя выполнение рутинных административных процессов, тем самым позволяя медицинским работникам больше времени проводить с пациентами. Примером такой оптимизации является Mater Hospital, один из центральных хабов обработки тестов COVID-19 в Ирландии. В этой организации использование RPA позволяет медсестрам сократить время выполнения административных задач до трех часов в день, что дает возможность посвятить это время уходу за больными.

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

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

Оценивая, как эта технологияможет облегчить нагрузку, лежащую на медсестрах Mater Hospital, Джинси Джерри, помощник директора по вопросам сестринского дела, профилактики инфекций и контроля, отметила, что благодаря этому решению им удалось сэкономить значительное количество времени. Данная технология помогает медперсоналу среднего звена собирать данные для более эффективной обработки случаев заболевания COVID-19.

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

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

Перевод Otonomo это App Store для автомобильных данных

23.10.2020 20:07:00 | Автор: admin
image

Otonomo это израильский стартап, который собирает данные с более чем 22 миллионов транспортных средств по всему миру. На этой неделе они развернули облачную платформу, открывающую доступ к данным для клиентов через API.

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

Компания Otonomo, которая собрала 82 миллиона долларов, ожидает, что сотни разработчиков приложений и сервисов создадут большую экосистему на основе ее платформы с автомобильными данными.

image

Эгиль Юлиуссен, автомобильный аналитик EE Times сказал следующее: Подумайте о том, что Otonomo распространяет автомобильные данные по модели App Store.

Идея монетизации автомобильных данных не нова. OEM-производители (такие как General Motors и Ford) уже разрабатывают сервисы, связанные с их собственными телематическими блоками управления. Технологические компании, включая Waymo, Tesla и Mobileye, также занимаются сбором данных, генерируемых транспортными средствами (или их собственными датчиками) для разработки различных технологий и сервисов.

Тесслер отметил, что разница заключается в том, что многие OEM-производители и технологические компании жестко закрывают свои платформы. В свою очередь, Otonomo работает с 22 миллионами автомобилей, которые ездят практически везде. В настоящее время компания собирает данные от 12 OEM-производителей, включая BMW, Peugeot, FCA, Mercedes, Mitsubishi. Также мы внедряем данные от других автомобильных OEM-производителей, добавил Тесслер. Впрочем, их компания пока раскрыть не может.

Но зачем автомобильным OEM-производителям сотрудничать с Otonomo, если они могут создавать свои собственные приложения и сервисы?

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

Кроме того, Otonomo обладает опытом анонимизации данных; автопроизводители понимают, что услуги фильтрации данных от Otonomo могут помочь им лучше соблюдать правила в области конфиденциальности данных.

image

Насколько уникальна Otonomo?


Юлиуссен сказал, что несколько лет назад он изучал рынок автомобильных данных и отметил, что компании Harman (финансируемая Samsung), CloudCar, Mojio, Octo Telematics, Verisk и Xevo также занимаются монетизацией автомобильных данных.

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

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

Платформа Otonomo предоставляет два типа данных: обобщенные данные и идентифицируемые данные, распространяемые после получения явного согласия владельца автомобиля.

Также Otonomo предоставляет инструменты для динамической фильтрации и агрегирования данных, что позволяет пользователям находить именно те данные, которые им нужны. Представители компании утверждают, что сейчас их платформа ежедневно собирает 4 миллиарда единиц данных с более чем 22 миллионов подключенных транспортных средств. Пользователи могут платить за те данные, которыми пользуются, либо подключить индивидуальный тарифный план. По данным компании, при оплате по факту использования пользователи платят 60 долларов за миллион единиц данных (или 60 долларов за 20 000 поездок). Otonomo также предлагает 30-дневную пробную версию.





image

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

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

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

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



О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

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

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

Подробнее..

Ликбез по типам поддержки, задачам саппорта и вариантам автоматизации

13.10.2020 16:15:52 | Автор: admin

На российском рынке представлен большой выбор help desk систем, которые позволяют автоматизировать процессы постпродажного обслуживания. С одной стороны, это хорошо, так как у каждой компании есть возможность подобрать решение для своего бизнеса и под свои задачи. С другой стороны, возникает путаница в том, для чего предназначен тот или иной helpdesk. Какой выбрать? В попытке протестировать все системы, который выдал поисковик, уходит много времени и сил, а на выходе результат не всегда получается даже удовлетворительным.

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

Зачем вообще нужны Help Desk системы? Есть ли результат?

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

По данным Teleperformance Customer Experience Lab, клиенты на 13% будут лояльнее к компании, если у них будет позитивный опыт взаимодействия с ее техподдержкой. Если негативный опыт, есть вероятность, что лояльность клиентов снизится на 27%.

Согласно всероссийскому отраслевому исследованию, проведенного Okdesk в этом году, почти 60% компаний утверждают, что их клиенты отказываются от продолжения сотрудничества из-за некачественного сервиса. При этом у 69,7% компаний доля выручки от сервисного обслуживания составляет от 10% до 25%.

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

Типы поддержки и разница в задачах, подходах и автоматизации

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

На верхнем уровне можно выделить два вида поддержки:

  1. Внутренняя.

  2. Внешняя.

При этом внешнюю поддержку можно условно разделить на:

  • работу в сегменте B2С (с "анонимусами");

  • взаимодействие с B2B-клиентами.

Специфика "внутренних" пользователей или ИТ-поддержка

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

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

Внутренняя поддержка зародилась в ИТ-департаментах. Именно по этой причине в организации процессов сервисного управления во всем мире используют подход ITSM(Information Technology Service Management). Он основан на базе передового опыта сервисного обслуживания внутри предприятия (Information Technology Infrastructure Library, ITIL).

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

Однако автоматизация внутренней поддержки по канонам (с CMDB, ресурсно-сервисной моделью и т.д.) актуальна и, главное, даёт результат на больших масштабах, то есть, только для крупных компаний (более 1000 сотрудников). Системы, которые соответствуют процессам ITIL, для среднего и малого бизнеса не подойдут: излишне функциональны, дорогие и требуют серьезных организационных изменений.При этом ничего не мешает использовать Help Desk системы для внутренней автоматизации более гуманные по ценнику и решающие бОльший пласт задач небольших организаций.

Если вы представляете крупную компанию, тогда советую вам ограничить выбор среди таких решений, как Omnitracker, HP Service Manager, BMC Remedy ITSM, Naumen Service Desk. Более дешевые варианты: OTRS, ITSM 365 и 1С:ITIL.

Внешняя B2С поддержка или Customer Service

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

Основные задачи поддержки B2С-клиентов можно сформулировать так:

  • фиксировать заявки по всем возможным каналам, включая соцсети и мессенджеры;

  • иметь инструменты, которые позволят автоматизировать решение типовых и простых вопросов;

  • отслеживать клиентскую лояльность.

Именно по этой причине Help Desk системы автоматизации Customer Service созданы для регистрации заявок из всех возможных каналов обращений (соцсети, мессенджеры и т. д.) и быстрой выдачи шаблонных ответов. Для последнего используют чат-ботов с типовыми сценариями вопросов-ответов и/или базу знаний.

Предлагаю обратить внимание на лидеров этого сегмента: Zendesk, Freshdesk, Kayako, Help Scout и Omnidesk.

Внешняя B2B поддержка и обслуживание клиентской инфраструктуры

В поддержке B2B-клиентов всё сложнее: нужно вести базу заказчиков, привязывать к ним все их заявки. Также необходимо учитывать договоры с клиентами, обслуживаемые объекты (в зависимости от бизнеса это может быть точка продаж, сайт, офис или даже транспортное средство), оборудование и ПО.

Почти каждая клиентская заявка не типовая и потому её выполнение имеет более сложный цикл. Бывает, что для решения проблемы компания привлекает подрядчика по сервисному обслуживанию. Тот в свою очередь может привлечь субподрядчика или самого производителя или разработчика. К тому же возникают ситуации, когда какие-то работы нужно оказывать за рамками договора и это биллингуется отдельно. А еще нужно планировать загрузку специалистов. При этом в случае выездного обслуживания (field service management) распределять заявки на ближайшего.

Именно поэтому в системах автоматизации B2B-поддержки критическое значение имеют:

  • встроенные и готовые отчеты по множеству метрик работы бизнеса;

  • блок учета платных работ, выходящих за рамки абонентского или договорного обслуживания;

  • более проработанный блок отслеживания обязательств и договоренностей по контрактам (SLA) в привязке к клиенту, объекту или с более сложной логикой;

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

  • настраиваемые чек-листы по сложным, но повторяющимся заявкам;

  • развитое API для реализации специализированных интеграций.

Поддержку B2B-клиентов можно разделить на удаленную и выездную. Удаленную поддержку оказывают вендоры своим клиентам и партнерам, сервисные компании, которые обслуживают ПО (например, франчайзи 1С).

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

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

Для удаленной и выездной B2B-поддержки обратите внимание на Jobber, Mhelpdesk и Service Fusion. Из отечественных на лидирующее решение Okdesk.

Вместо заключения

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

Подробнее..

AWS Cloud Core Concepts

24.10.2020 16:23:59 | Автор: admin

Предисловие


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


Cloud это место, где вы храните свои данные/приложения/процессы и получаете к ним доступ в любое время через Интернет.



The Five Pillar



image

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


  • Operational Excellence
  • Security
  • Reliability
  • Performance Efficiency
  • Cost Optimization


Разберем эти практики и Shared responsibility model в этом подкате.




Operation Excellence



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


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


Две концепции:
  • Infrastructure as a Code (ex. CloudFormation. CDK)
  • Observability (Analytics, Metrics, Actions)

Infrastructure as a Code позволяет писать код через yaml/json(CloudFormation) файлы или на любимом вами языке(Cloud Development Kit). Один раз пишете много раз используете, ну разве не рай для DevOps?


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


Пример плохой ситуации: Вы развернули большой сервис по доставке еды. Протестировали, всё работает идеально, приложение наберает популярность, ваш cloud engineer горизонтально масштабирует ваш сервис до 100 экземпляров, и в какой-то момент половина экземпляров приходит в не действие (предположим, что кто-то не правильно прикурил сигарету на ночном перекуре в датацентре AWS). И половина пользователей начинает жаловатся на на доступность доставки еды. А что делать ночью без еды?


Что же мы делали до того как узнали про operation excellence: звоним cloud engineer, он летит в офис к своему ПК, в трэморе начинает разворачивать экземпляры в другом датацентре. И ура, к утру все сервисы востановлены. Но клиенты уже потеряны, они нашли себе другую доставку. You lose!


Что же мы делаем полсе того как узнани про operation excellence: настраиваем метрику на минимальное количества экземпляров 100, и когда в следующий раз кто-то попробует прикурить мы уже будем готовы и AWS за нас вернёт все не достающие экземпляры сразу же как произойдет проблема. You win!



Security



Фокусируется на том, как защитить вашу инфраструктуру в облаке. Три важные концепции, связанные с безопасностью в облаке:


  • Identity and Access Management (IAM)
  • Network Security
  • Data Encryption

IAM ключевой сервис AWS, который позволяет создавать пользователей, роли, группы, политики.



image

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



Reliability



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



Две концепции для создания отказоустойчивых систем:
  • Fault Isolation(Resource, Availability Zone, Region)
  • Limits(soft and hard)


Fault Isolation говорит о том что стоит изолировать ваши сервисы от сбоев, чем меньше частей вашей системы выйдет из строя тем лучше, казалось бы всё просто.
Что надо делать чтобы этого достичь? Делать ваши сервисы высокодоступными(high availability) вам поможет размешения ресурсосов в разных датацентрах AWS, в разных регионах и зонах доступности.



image

Вторая концепция настройка ограничений. Самый доступный пример защита от DDoS-атак, Тестируете рабочую пропускную способность своего приложения, ставите ограничение на примём максисум 150% от текущей пропускную способности, и задудосить вас не получится.



Performance Efficiency



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



Две основные концепции:
  • Selection
  • Scaling


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


Scaling позволяет увеличивать перфоманс вашего приложения с помощью нарастания мощностей экземпляра (vertical scaling) или увеличением их количества (horizontal scaling).



image

Cost optimization



Фокусируется на оптимизации затрат помогает достичь бизнес-результатов при минимизации затрат. Pay-as-you-go модель вносит следующие изменения в ваш процесс оптимизации затрат:


  • Pay For Use
  • Cost Optimization Lifecycle


image

Shared responsibility model



Эта модель показывает кто за что несёт ответственось в AWS.
С документации AWS: AWS несет ответственность за защиту инфраструктуры облака AWS, на которой работают все предлагаемые сервисы. Эта инфраструктура состоит из аппаратного и программного обеспечения, сетей и объектов, на базе которых работают облачные сервисы AWS.


Ответственность клиента будет определяться выбранными для использования облачными сервисами AWS. Выбор сервисов определяет объем работ по настройке, которые должен выполнить клиент в рамках своих обязанностей по обеспечению безопасности. Клиенты, которые развертывают инстанс Amazon EC2, отвечают за управление гостевой операционной системой (включая обновления и исправления безопасности), любым прикладным программным обеспечением или сервисными компонентами, установленными на инстансах, и за настройку брандмауэра (группы безопасности), предоставляемого AWS, для каждого инстанса. В случае абстрактных сервисов, таких как Amazon S3 и Amazon DynamoDB, AWS управляет уровнем инфраструктуры, операционной системой и платформой, а клиенты получают доступ к конечным точкам для хранения и извлечения данных. Клиенты отвечают за управление своими данными (включая параметры шифрования), классификацию своих ресурсов и использование инструментов IAM для применения соответствующих разрешений.


О чём это говорит? Если ядерная бомба упадёт на датацентр AWS они берут ответственность за это проишествие на себя. И они будут оправдоваться/возмещать ущерб. Если вы не шифруете данные при передачи с вашего компьютера и данные перехватили и украли это ваша проблема.



Послесловие



Вы прочитали AWS Cloud Core Concepts. В этом статье вы узнали следующее:

  • Пять столпов архитектуры AWS
  • Важные модели, которые представляют собой облачный образ мышления
  • Ключевые концепции в рамках каждого из пяти столпов
  • Shared responsibility model



Источники



aws.amazon.com/ru/getting-started/fundamentals-core-concepts
aws.amazon.com/ru/compliance/shared-responsibility-model
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru