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

Системное администрирование

Перевод Кунг-фу стиля Linux удобная работа с файлами по SSH

26.09.2020 16:11:14 | Автор: admin
Если у вас имеется больше одного Linux-компьютера, то вы, вероятно, постоянно пользуетесь ssh. Это отличный инструмент, но мне всегда казалась в нём странной одна деталь. Несмотря на то, что ssh-соединения позволяют передавать файлы с применением scp и sftp, у нас нет возможности перемещать файлы между локальной и удалённой системой, не запуская программу на локальном хосте, или не подключаясь к локальной машине с удалённой.



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

Я, на самом деле, не вполне достиг этой цели, но подобрался к её достижению очень близко. В этом материале я расскажу вам о скрипте, который позволяет монтировать удалённые директории на локальном компьютере. На локальной машине надо будет установить sshfs, но на удалённой, на которую вы, возможно, не можете устанавливать программы, ничего менять не придётся. Если же потратить на настройку систем некоторое время, и если на клиентском компьютере имеется работающий ssh-сервер, то можно будет ещё и монтировать локальные директории на удалённых системах. При этом не придётся беспокоиться о блокировке IP-адресов или портов. Фактически, если вы способны подключиться к удалённой машине, это означает, что вам удастся и то, о чём я хочу рассказать.

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

Нет ли тут подвоха?


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

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

Пара слов о sshfs


Утилита sshfs даёт возможность работать с файловой системой в пользовательском пространстве (filesystem in userspace, FUSE). То есть, речь идёт о том, что в пользовательском пространстве имеется слой, находящийся поверх базовой файловой системы. В данном случае такой файловой системой является ssh-сервер, поддерживающий sftp. Это позволяет работать с файлами, находящимися на удалённой системе, воспринимая их так, будто они находятся в реальной файловой системе на локальном компьютере. Если вы ещё не пробовали sshfs попробуйте. Работает эта утилита очень хорошо.

Предположим, вы вошли на компьютер myserver и выполнили с локальной машины следующую команду:

sshfs myserver:/home/admin ~/mounts/myserver

Это приведёт к тому, что директория удалённого компьютера /home/admin будет доступна в локальной системе по пути ~/mounts/myserver.

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

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

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


Прежде чем я перейду к описанию скрипта, о котором было упомянуто выше, хочу рассказать о некоторых настройках клиента, которые вы, если хотите, можете доработать под себя. Так, тут я создаю директорию ~/remote, а в ней создаю поддиректории для каждого удалённого компьютера. Например это могут быть директории ~/remote/fileserver и ~/remote/lab.

Скрипт называется sshmount. Он принимает те же аргументы, что и ssh. Для упрощения работы со скриптом сведения об удалённом хосте стоит хранить в файле ~/.ssh/config, что позволит пользоваться простыми и короткими именами хостов. Например, сведения о компьютере lab могут выглядеть так:

Host labHostname lab.wd5gnr-dyn.netPort 444User alwForwardX11 yesForwardX11Trusted yesTCPKeepAlive yesCompression yesControlMaster autoControlPath ~/.ssh/master-%r@%h:%p

На самом деле, острой необходимости в этом нет, но при таком подходе в вашем распоряжении будет приятно выглядящая директория ~/remote/lab, а не сложная конструкция вида ~/remote/alw@lab.wd5gnr-dyn.net:444. Во всех этих параметрах нет ничего таинственного. Единственно, хочу обратить ваше внимание на то, что ControlMaster и ControlPath позволяют организовать более быструю работу с соединениями, что, в нашем случае, очень важно.

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

Скрипт


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

  1. Он проверяет, есть ли в директории ~/remote поддиректория, имя которой совпадает с именем хоста (например lab). Если такой директории нет он выводит сообщение об ошибке и продолжает работу.
  2. Если такая директория существует скрипт просматривает список смонтированных файловых систем на тот случай, если нужная файловая система уже смонтирована. Если это так он продолжает работу.
  3. Если директория не смонтирована он вызывает sshfs и продолжает работу.

Этот скрипт можно найти на GitHub. А вот его код, из которого убраны некоторые комментарии:

#!/bin/bashif [ "$1" == "" ]thenecho Usage: sshmount host [ssh_options] - Mount remote home folder on ~/remote/host and log inecho or: sshunmount host - Remove mount from ~/remote/hostexit 1fi# Если вызван как sshunmount...if [ $(basename "$0") == sshunmount ]thenecho Unmounting... 1>&2fusermount -u "$HOME/remote/$1"exit $?fi# Обычный вызов...if [ -d "$HOME/remote/$1" ] # Существует ли директория?thenif mount | grep "$HOME/remote/$1 " # Файловая система уже смонтирована?thenecho Already mounted 1>&2elsesshfs -o reconnect $1: $HOME/remote/$1 # mountfielseecho No remote directory ~/remote/$1 exists 1>&2fissh $@ # выполнить вход

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

Решаем обратную задачу


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

Но нашу задачу, несмотря на все эти сложности, всё же, можно решить. Её решение состоит из двух частей.

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

sshmount MyServer -R 5555:localhost:22

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

sshfs -p 5555 localhost:/home/me ~/local

Благодаря опции -R на удалённой машине создаётся сокет на порте 5555 (который, естественно, должен быть свободным) и осуществляется его связь с портом 22 локальной машины. Если исходить из предположения о том, что ssh-сервер работает на порте 22, то это позволит серверу подключиться к локальной машине по тому же соединению. Ему не нужно знать наш IP-адрес или иметь открытый порт.

Команда sshfs, которую можно выполнять при запуске системы, связывает локальную директорию /home/me с директорией ~/local удалённого сервера. Если, вдобавок, войти в систему локально, то можно будет взглянуть на переменные окружения, имена которых начинаются с SSH_, и узнать подробности о SSH-соединении. Например, это переменные $SSH_CLIENT и $SSH_TTY.

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

Итоги


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

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

Чем вы пользуетесь для работы с файлами удалённых Linux-систем?



Подробнее..

OSINT или как посмотреть на свою сеть глазами хакера

21.09.2020 10:09:24 | Автор: admin


Добрый день! Сегодня я вам расскажу какую информацию об организации можно обнаружить в открытых источниках и как ей может воспользоваться потенциальный злоумышленник. Многие из вас наверняка слышали об OSINT (Open Source INTelligence, перечень мероприятий, направленный на сбор информации из открытых источников), который чаще всего используется для сбора информации о конкретном человеке. Но также OSINT можно использовать для поиска информации о конкретных организациях для оценки защищенности. Ведь согласитесь, полезно посмотреть, что о вас есть в открытом доступе и как вы выглядите со стороны потенциального злоумышленника.


Популярные ресурсы, где проходит сбор информации


Для проведения активного сканирования необходимо подписание NDA и согласование проведения работ, что естественно требует времени. В связи с этим необходимо использовать только данные, находящиеся в открытых источниках, не сканировать ИТ-инфраструктуру и соответственно не тратить человеко-часы на бюрократию.


Так что же можно найти в свободном доступе?

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


Я же постараюсь выделить из обширного объема информации наиболее интересную для ИБ специалистов. Искать будем:

  • Корпоративные почтовые адреса
  • Факты компрометации почтовых адресов
  • Субдомены, зарегистрированные за компанией
  • IP-адреса и автономные системы компании
  • Открытые порты и сервисы, находящиеся на них, а также подбор уязвимостей и эксплойтов для обнаруженных сервисов
  • Скрытые директории сайтов
  • Конфиденциальные документы

Чем же можно воспользоваться для поиска этой информации?

В интернете существует огромное количество инструментов для поиска почтовых адресов компании по доменам, например:


hunter.io до недавнего времени инструмент был полностью бесплатным, но к сожалению времена меняются.



Расширение браузера Email Finder от Snov.io на данный момент имеет огромный функционал в бесплатной версии и находит огромное количество доменных учетных записей, но надолго ли?..



theHarvester собирает как почтовые адреса, так и субдомены, открытые порты а также данные о виртуальных хоcтах. Предустановлен в Kali Linux.



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

Провести проверку можно на многим известном сервисе haveibeenpwned.com.



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



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

Тут стоит отметить, что инструмент имеет платный API. Без него, конечно, можно проверить все почтовые адреса, но придется подавать их на вход по одному, что займет уйму времени. При покупке API (3,5$ в месяц, чисто символическая плата) получим возможность использовать его в различных скриптах и соответственно существенно ускорить и автоматизировать процесс анализа.

В дальнейшем можно воспользоваться ботом в telegram @mailsearchbot.



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

Следующим этапом необходимо собрать информацию о субдоменах. Инструментов, позволяющих это сделать очень много, например:


theHarvester



dnsdumpster.com умеет рисовать красивые графы взаимосвязей и выгружать результаты в Excel, но имеет ограничение на выдачу только 100 субдоменов.



pentest-tools.com советую познакомиться с сайтом поподробнее, так как тут можно не только субдомены искать. В lite версии имеет ограничение на 2 сканирования в день, но легко обходится TORом)



Тут также имеет смысл комбинировать инструменты для определения наибольшего количества субдоменов. Зачастую в паре с субдоменом идет IP-адрес, который в дальнейшем можно скормить шодану (shodan.io) для получения списка открытых портов и сервисах, торчащих в интернете.



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


cvedetails.com большая пополняемая база CVE по сервисам и их версиям. Тут могут возникнуть некоторые сложности с поиском необходимых сервисов так, как они повторяются (например существуют две разные страницы сервиса Microsoft IIS с разными уязвимостями).



exploit-db.com большая пополняемая база эксплойтов. Тут стоит обратить внимание, что есть подтвержденные администрацией сайта эксплойты и не проверенные.



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


bgp.he.net топорно выглядит, но показывает данные по любым автономным системам.



ididb.ru в большей степени заточен на сбор информации об автономных системах Рунета.



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

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



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

  • Google Dorks
  • DirBuster

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



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



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

Популярные курсы/книги для обучения


  • Курс видеоматериалов для ознакомления с OSINT
  • Сертифицированный курс по OSINT и конкурентной разведке
  • Советую посмотреть в YouTube записи выступлений Масаловича Андрея Игоревича, преподавателя предыдущего курса. Он настоящий профессионал своего дела, расскажет много интересного. Также советую ознакомиться с его сайтом, на котором вы можете найти большое количество видеоматериалов и книг по данной тематике


Топ 5 проблем, которые нам удается обнаружить в рамках OSINT-а


На моей практике удавалось:

  • Получить возможность управлять сайтом от имени администратора поскольку была возможность провалиться в директорию, которая минует авторизацию администратора. Естественно я там ничего трогать не стал, но еслиб это был не я, а потенциальный злоумышленник? Закрывать нужно такие директории.
  • Обнаружить торчащие в интернет базы данных, которые к тому же были очень древние и крайне дырявые. Подбор эксплойта под такие базы задача крайне простая. Не нужно вытаскивать БД наружу.
  • Обнаружить RDP, FTP, SSH и NTP сервисы, доступ к которым из неограниченного пула адресов нежелателен. Тут вырисовывается проблема простых паролей для учетных записей, а brute force никто не отменял. Не нужно выставлять такие сервисы наружу, если нет явной необходимости..
  • Обнаружить конфиденциальные документы. Например документы, относящиеся к организации внутриобъектового режима, находящиеся в открытом доступе не лучшая затея.
  • Подобрать актуальные пароли от почтовых адресов. Я сам не проверяю актуальность обнаруженных паролей, но иногда после ознакомления с отчетом сотрудники компании обращаются с вопросом: что же делать, если пароль действительно актуальный? В таких случаях его естественно нужно менять, а так же менять пароли на всех сайтах, где регистрация проходила от данного почтового ящика и надеяться на лучшее. А вообще меняйте пароли почаще.


Заключение


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

Что делать, если нет возможности провести OSINT самому?


Мы можем провести OSINT для Вашей организации совершенно бесплатно, обращайтесь.
Если данная тематика вам интересна, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Подробнее..

Sysmon теперь может записывать содержимое буфера обмена

21.09.2020 16:09:27 | Автор: admin
О релизе 12 версии Sysmon сообщили 17 сентября на странице Sysinternals. На самом деле в этот день вышли также новые версии Process Monitor и ProcDump. В этой статье я расскажу о ключевом и неоднозначном нововведении 12 версии Sysmon типе событий с Event ID 24, в который логируется работа с буфером обмена.



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

Новое событие содержит следующие поля:

Image: процесс, данные из которого были записаны в буфер обмена.
Session: сеанс, в котором выполнилась запись в буфер обмена. Это может быть system(0)
при работе в интерактивном или удаленном режиме и т.д.
ClientInfo: содержит имя пользователя сеанса, а в случае удаленного сеанса исходное имя хоста и IP-адрес, если эти данные доступны.
Hashes: определяет имя файла, в котором был сохранен скопированный текст (аналогично работе с событиями типа FileDelete).
Archived: статус, был ли сохранен текст из буфера обмена в архивной директории Sysmon.

Пара последних полей вызывают тревогу. Дело в том, что с версии 11 Sysmon может (при соответствующих настройках) сохранять разные данные в свою архивную директорию. Например, Event ID 23 логирует в себя события по удалению файлов и может их сохранять всё в той же архивной директории. К имени файлов, созданных в результате работы с буфером обмена, добавляется тег CLIP. Сами файлы содержат точные данные, которые были скопированы в буфер обмена.

Так выглядит сохраненный файл
image

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

Так выглядит установка Sysmon с соответствующей настройкой архивной директории:
image

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

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

Подведем итог возможностей Sysmon по работе с буфером обмена.

Фиксируются:

  • Текстовая копия вставляемого текста через RDP и локально;
  • Захват данных из буфера обмена различными утилитами/процессами;
  • Копирование/вставка текста с/на локальную виртуальную машину, даже если этот текст ещё не был вставлен.

Не фиксируются:

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


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

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

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

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

А кто это сделал? Автоматизируем аудит информационной безопасности
Подробнее..

Cisco ISE Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2

25.09.2020 10:10:53 | Автор: admin

Приветствую во второй публикации цикла статей, посвященному Cisco ISE. В первой статье были освещены преимущества и отличия Network Access Control (NAC) решений от стандартных ААА, уникальность Cisco ISE, архитектура и процесс установки продукта.

В данной статье мы углубимся в создание учетных записей, добавлению LDAP серверов и интеграцию с Microsoft Active Directory, а также в нюансы при работе с PassiveID. Перед прочтением настоятельно рекомендую ознакомиться с первой частью.

1. Немного терминологии

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

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

User Identity Groups - предустановленные группы пользователей, которые уже имеют определенную информацию и роли. Следующие User Identity Groups существуют по умолчанию, в них можно добавлять пользователей и группы пользователей: Employee (сотрудник), SponsorAllAccount, SponsorGroupAccounts, SponsorOwnAccounts (спонсорские учетки для управления гостевым порталом), Guest (гость), ActivatedGuest (активированный гость).

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

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

2. Создание локальных пользователей

1) В Cisco ISE есть возможность создать локальных пользователей и использовать их в политике доступа или даже дать роль администрирования продуктом. Выберите Administration > Identity Management > Identities > Users > Add.

Рисунок 1. Добавление локального пользователя в Cisco ISEРисунок 1. Добавление локального пользователя в Cisco ISE

2) В появившемся окне создайте локального пользователя, задайте ему пароль и другие понятные параметры.

Рисунок 2. Создание локального пользователя в Cisco ISEРисунок 2. Создание локального пользователя в Cisco ISE

3) Пользователей также можно импортировать. В этой же вкладке Administration > Identity Management > Identities > Users выберите опцию Import и загрузите csv или txt файлик с пользователями. Для того, чтобы получить шаблон выберите Generate a Template, далее следует его заполнить информацией о пользователях в подходящем виде.

Рисунок 3. Импорт пользователей в Cisco ISEРисунок 3. Импорт пользователей в Cisco ISE

3. Добавление LDAP серверов

Напомню, что LDAP - популярный протокол прикладного уровня, позволяющий получать информацию, производить аутентификацию, искать учетные записи в каталогах LDAP серверов, работает по порту 389 или 636 (SS). Яркими примерами LDAP серверов являются Active Directory, Sun Directory, Novell eDirectory и OpenLDAP. Каждая запись в каталоге LDAP определяется DN (Distinguished Name) и для формирования политики доступа встает задача подтягивания (retrieval) учетных записей, пользовательских групп и атрибутов.

В Cisco ISE возможно настроить доступ ко многим LDAP серверам, тем самым реализуя избыточность. В случае, если первичный (primary) LDAP сервер недоступен, то ISE попробует обратиться к вторичному (secondary) и так далее. Дополнительно, если имеется 2 PAN, то то для первичной PAN можно сделать приоритетным один LDAP, а для вторичной PAN - другой LDAP.

ISE поддерживает 2 типа лукапа (lookup) при работе с LDAP серверами: User Lookup и MAC Address Lookup. User Lookup позволяет делать поиск пользователю в базе данных LDAP и получать следующую информацию без аутентификации: пользователи и их атрибуты, группы пользователей. MAC Address Lookup позволяет так же без аутентификации производить поиск по MAC адресу в каталогах LDAP и получать информацию об устройстве, группу устройств по MAC адресам и другие специфичные атрибуты.

В качестве примера интеграции добавим Active Directory в Cisco ISE в качестве LDAP сервера.

1) Зайдите во вкладку Administration > Identity Management > External Identity Sources > LDAP > Add.

Рисунок 4. Добавление LDAP сервераРисунок 4. Добавление LDAP сервера

2) В панели General укажите имя LDAP сервера и схему (в нашем случае Active Directory).

Рисунок 5. Добавление LDAP сервера со схемой Active DirectoryРисунок 5. Добавление LDAP сервера со схемой Active Directory

3) Далее перейдите в Connection вкладку и укажите Hostname/IP address AD сервера, порт (389 - LDAP, 636 - SSL LDAP), учетные данные доменного администратора (Admin DN - полный DN), остальные параметры можно оставить по умолчанию.

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

Рисунок 6. Ввод данных LDAP сервераРисунок 6. Ввод данных LDAP сервера

4) Во вкладке Directory Organization следует указать область каталогов через DN, откуда вытягивать пользователей и группы пользователей.

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

5) Перейдите в окно Groups > Add > Select Groups From Directory для выбора подтягивания групп из LDAP сервера.

Рисунок 8. Добавление групп из LDAP сервераРисунок 8. Добавление групп из LDAP сервера

6) В появившемся окне нажмите Retrieve Groups. Если группы подтянулись, значит предварительные шаги выполнены успешно. В противном случае, попробуйте другого администратора и проверьте доступность ISE c LDAP сервером по LDAP протоколу.

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

7) Во вкладке Attributes можно опционально указать, какие атрибуты из LDAP сервера следует подтянуть, а в окне Advanced Settings включить опцию Enable Password Change, которая заставит пользователей изменить пароль, если он истек или был сброшен. В любом случае нажмите Submit для продолжения.

8) LDAP сервер появился в соответствующий вкладке и в дальнейшем может использоваться для формирования политик доступа.

Рисунок 10. Перечень добавленных LDAP серверовРисунок 10. Перечень добавленных LDAP серверов

4. Интеграция с Active Directory

1) Добавив Microsoft Active Directory сервер в качестве LDAP сервера, мы получили пользователи, группы пользователей, но не логи. Далее предлагаю настроить полноценную интеграцию AD с Cisco ISE. Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > Add.

Примечание: для успешной интеграции с AD ISE должен находиться в домене и иметь полную связность с DNS, NTP и AD серверами, в противном случае ничего не выйдет.

Рисунок 11. Добавление сервера Active DirectoryРисунок 11. Добавление сервера Active Directory

2) В появившемся окне введите данные администратора домена и поставьте галочку Store Credentials. Дополнительно вы можете указать OU (Organizational Unit), если ISE находится в каком-то конкретном OU. Далее придется выбрать ноды Cisco ISE, которые вы хотите соединить с доменом.

Рисунок 12. Ввод учетных данныхРисунок 12. Ввод учетных данных

3) Перед добавлением контроллеров домена убедитесь, что на PSN во вкладке Administration > System > Deployment включена опция Passive Identity Service. PassiveID - опция, которая позволяет транслировать User в IP и наоборот. PassiveID получает информацию из AD через WMI, специальных AD агентов или SPAN порт на коммутаторе (не лучший вариант).

Примечание: для проверки статуса Passive ID введите в консоли ISE show application status ise | include PassiveID.

Рисунок 13. Включение опции PassiveID Рисунок 13. Включение опции PassiveID

4) Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > PassiveID и выберите опцию Add DCs. Далее выберите галочками необходимые контроллеры домена и нажмите OK.

Рисунок 14. Добавление контроллеров доменаРисунок 14. Добавление контроллеров домена

5) Выберите добавленные DC и нажмите кнопку Edit. Укажите FQDN вашего DC, доменные логин и пароль, а также опцию связи WMI или Agent. Выберите WMI и нажмите OK.

Рисунок 15. Ввод данных контроллера доменаРисунок 15. Ввод данных контроллера домена

6) Если WMI не является предпочтительным способом связи с Active Directory, то можно использовать ISE агентов. Агентский способ заключается в том, что вы можете установить на сервера специальные агенты, которые будут отдавать login события. Существует 2 варианта установки: автоматический и ручной. Для автоматической установки агента в той же вкладке PassiveID выберите пункт Add Agent > Deploy New Agent (DC должен иметь доступ в Интернет). Затем заполните обязательные поля (имя агента, FQDN сервера, логин/пароль доменного администратора) и нажмите OK.

Рисунок 16. Автоматическая установка ISE агентаРисунок 16. Автоматическая установка ISE агента

7) Для ручной установки Cisco ISE агента требуется выбрать пункт Register Existing Agent. К слову, скачать агента можно во вкладке Work Centers > PassiveID > Providers > Agents > Download Agent.

Рисунок 17. Скачивание ISE агентаРисунок 17. Скачивание ISE агента

Важно: PassiveID не читает события logoff! Параметр отвечающий за тайм-аут называется user session aging time и равняется 24 часам по умолчанию. Поэтому следует либо делать logoff самому по окончании рабочего дня, либо же писать какой-то скрипт, который будет делать автоматический logoff всем залогиненым пользователям.

Для получения информации logoff используются "Endpoint probes" - оконечные зонды. Endpoint probes в Cisco ISE существует несколько: RADIUS, SNMP Trap, SNMP Query, DHCP, DNS, HTTP, Netflow, NMAP Scan. RADIUS probe с помощью CoA (Change of Authorization) пакетов отдает информацию о смене прав пользователя (для этого требуется внедренный 802.1X), а настроенный на коммутаторах доступа SNMP, даст информацию о подключенных и отключенных устройствах.

Ниже приведен пример, актуальный для конфигурации Cisco ISE + AD без 802.1X и RADIUS: пользователь залогинен на Windows машине, не делая logoff, логиниться с другого ПК по WiFi. В этом случае сессия на первом ПК по-прежнему будет активна, пока не случится тайм-аут или не произойдет принудительный logoff. Тогда если у устройств разные права, то последнее залогиненное устройство будет применять свои права.

8) Дополнительно во вкладке Administration > Identity Management > External Identity Sources > Active Directory > Groups > Add > Select Groups From Directory вы можете выбрать группы из AD, которые хотите подтянуть на ISE (в нашем случае это было сделано в пункте 3 Добавление LDAP сервера). Выберите опцию Retrieve Groups > OK.

Рисунок 18 а). Подтягивание групп пользователей из Active DirectoryРисунок 18 а). Подтягивание групп пользователей из Active Directory

9) Во вкладке Work Centers > PassiveID > Overview > Dashboard вы можете наблюдать количество активных сессий, количество источников данных, агентов и другое.

Рисунок 19. Мониторинг активности доменных пользователейРисунок 19. Мониторинг активности доменных пользователей

10) Во вкладке Live Sessions отображаются текущие сессии. Интеграция с AD настроена.

Рисунок 20. Активные сессии доменных пользователейРисунок 20. Активные сессии доменных пользователей

5. Заключение

В данной статьей были рассмотрены темы создания локальных пользователей в Cisco ISE, добавление LDAP серверов и интеграция с Microsoft Active Directory. В следующей статье будет освещен гостевой доступ в виде избыточного гайда.

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

Следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog, Яндекс.Дзен).

Подробнее..

Анбоксинг Huawei CloudEngine 6865 наш выбор для перехода на 25 Гбитс

18.09.2020 10:20:14 | Автор: admin


С ростом инфраструктуры облака mClouds.ru, нам потребовалось ввести в эксплуатацию новые коммутаторы на 25 Гбит/с на уровне доступа серверов. Расскажем, как мы выбрали Huawei 6865, распакуем оборудование и расскажем наши первые впечатления от эксплуатации.

Формируем требования

Исторически у нас положительный опыт как с Cisco, так и с Huawei. Cisco используем для маршрутизации, а Huawei для коммутации. На данный момент используем CloudEngine 6810. С ним все хорошо оборудование работает исправно и предсказуемо, а стоимость внедрения дешевле, чем аналоги от Cisco и других вендоров. Кстати, про серию 6800 мы уже писали ранее.

Логично продолжить использовать эту связку и далее, но нам нужно более мощное решение расширение сети до 25 Гбит/с на порт, вместо текущих 10 Гбит/с.

Остальные наши требования: аплинки 40/100, неблокируемая коммутация, производительная матрица, поддержка L3, стекирование. Из желаемого на перспективу: поддержка Leaf-Spine, VXLAN, BGP EVPN. Ну и, конечно, цена стоимость эксплуатации влияет на конечную стоимость облака для наших клиентов, поэтому важно выбрать вариант с хорошим соотношением цена-качество.

Выбор и ввод в эксплуатацию

При выборе мы остановились на трех производителях Dell, Cisco и Huawei. Как уже писали выше, мы стараемся использовать уже проверенных временем партнеров, и имеем хорошее представление о том, как ведет себя их оборудование и как работает сервис.

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


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


Сравнили, заказали и наконец получили новые коммутаторы

И вот партия приехала в ЦОД. Открываем и на первый взгляд практически не видим визуальных отличий от используемых нами 6810. Единственное, что заметно у новой версии большее число аплинков и порты другого типа (SFP28 и QSFP28, вместо SFP+ и QSFP+ соответственно), что позволит нам увеличить скорость работы сети до 25 Гбит/с вместо 10 Гбит/с для SFP28 и до 100 Гбит/с вместо 40 Гбит/с для QSFP28.


Устанавливаем коммутаторы в новую стойку

Опыт эксплуатации

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

По нашим ощущениям интерфейс Huawei VRP где то между IOS и Comware. И тут будет проще, если вы работали именно с Comware от HPE, а вот пользователям Cisco, наоборот будет посложнее. Конечно, это не критично, но тоже стоит учесть при выборе оборудования.

Опыт работы с коммутацией Huawei на протяжении уже более 4 лет, не оставляет сомнений в выборе. CloudEngine 6885 не уступает решениям конкурентов в техническом плане, радует своей ценой и позволяет предоставлять нам надежные облачные решения для наших клиентов.

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

Дорожная карта миграции почты IBM NotesDomino в Exchange и Office 365

22.09.2020 08:08:59 | Автор: admin
image


Переход с IBM Notes на Microsoft Exchange или Office 365 дает весомое количество преимуществ для организации, но сам проект миграции выглядит пугающе и не совсем понятно с чего нужно начинать миграцию. Сам Exchange не включает собственные инструменты для полной миграции или установления сосуществования Notes и Exchange. Фактически, выполнение некоторых задач миграции и сосуществования невозможно без сторонних продуктов. В этой статье мы опишем семь ключевых шагов, которые необходимо выполнить в соответствии с лучшими практиками и нашим опытом проведения успешных миграций.

Успешная миграция включает следующие шаги:

  1. Предварительная оценки миграции.
  2. Установление сосуществования Notes и Exchange.
  3. Планирование оптимальной точности миграции.
  4. Обеспечение максимальной эффективности миграции.
  5. Запуск пробной миграции.
  6. Планирование времени миграции, для минимизации влияния на организацию.
  7. Запуск миграции и отслеживание ее прогресса.

В этой статье мы разберем как подготовиться к миграции и выполнить ее при помощи двух решений от Quest Coexistence Manager for Notes и Migrator for Notes to Exchange. Под катом некоторые подробности.

Шаг 1: Предварительная оценка миграции


Проведение инвентаризации текущей среды


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

  • Сколько существуют доменов Notes и серверов Domino?
  • Сколько у вас почтовых ящиков? Сколько из них не используются?
  • Сколько места на дисках занимают файлы основной почты? Сколько в архивах? Сколько в локальных репликах?
  • Где находятся архивы?
  • Сколько пользователей используют шифрование? Зашифрованный контент нужно перенести?
  • Сколько личных папок существует в окружении?
  • Какие пользователи используют ссылки на документы? Сколько пользователей получили ссылки от других пользователей и приложений?
  • Сколько данных вы собираетесь переносить? Например, вы хотите перенести данные только за последние полгода.
  • Будут ли перенесены нативные архивы в персональные архивы Exchange или в файлы *.pst Outlook?
  • Каковы ограничения полосы пропускания? Сколько данных можно перенести в
    определенный промежуток времени?
  • Какой объем хранилища потребуется после миграции?

Как миграция повлияет бизнес и операционную деятельность


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

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

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

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

Прежде чем начать миграцию, нужно определить критерии для измерения успеха. В частности, нужно понимать, что неразумно ожидать 100% переноса данных. Не у каждого типа элемента Notes есть эквивалент в Exchange (Active Mail самый вопиющий пример). Следовательно, реальность такова что не все элементы в Notes будут существовать в Exchange после миграции. Достижимая и измеримая цель 95% элементов перенесено для 95 процентов почтовых ящиков. Измерение и документирование результатов имеют решающее значение для обеспечения успеха миграции, а настоящие результаты возможны только если были определены критерии успешности в самом начале проекта миграции электронной почты.

Шаг 2: установление сосуществования Notes и Exchange


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

Разработка стратегии сосуществования


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

Переход с Notes на Exchange и Office 365 требует планирования миграции почтовых ящиков и приложений одновременно. Должна поддерживаться текущая функциональность приложений Notes для всех пользователей независимо от их текущей почтовой платформы. Как пользователи, перешедшие на Exchange и Office 365, они должны иметь доступ и использовать приложения Notes в рамках существующих рабочих процессов. Эта возможность должна сохраняться до тех пор, пока приложения Notes перенесутся на SharePoint или другую платформу.

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

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

Шаг 3: Планирование оптимальной точности миграции


Планирование перехода с Notes на Exchange или Office 365 требует понимания ряда конкретных различий между платформами.

Адреса электронной почты


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

Структура папки


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

Локальные реплики и архивы


В целях контроля затрат на хранение и лучшего управления ростом объема данных, многие организации устанавливают квоты на почтовые ящики. Непреднамеренным следствием этой политики часто бывает увеличение количества и размера архивов. Эти дополнительные данные источники должны быть оценены и вопрос их миграции стоит рассмотреть во время планирования миграции. Можно предоставить пользователям компонент самообслуживания, который даст им перенести только важные данные. Для оптимизация хранилища Exchange мы рекомендуем использовать другой продукт Quest Archive Manager for Exchange, в нем есть, в частности, полезный функционал по дедупликации вложенных файлов, аналог DAOS в Notes.

ACL и делегирование


Разрешенные списки для контроля доступа (ACL) и делегирование ключевые элементы для операционной в среде Notes, они также имеют решающее значение для защиты целостности. В результате важно точно преобразовать связанные права и права доступа к эквивалентным правам в Exchange Server и Office 365. В идеале сделать это автоматически, что ускорит процесс и исключит человеческую ошибку. Чтобы поддержать эффективность защиты информационных активов организации, ACL и преобразование делегирования должно быть выполнено одновременно с почтовыми данными. Некоторые организации пытаются назначить эквивалентные права вручную или с помощью скриптов, после завершения переноса данных. Однако, такой подход может негативно повлиять на производительность и добавить пробелы в безопасность данных организации.

Собственное содержание Notes


Тот самый Active Mail. Еще одна распространенная проблема, когда миграция с IBM Notes встречается с большим количеством форматированного текста. Exchange и Office 365 не поддерживают интегрированные таблицы с вкладками, кнопки, сохраненные формы и другой проприетарный контент в Notes. В результате вам потребуется либо подготовиться к потере этой функциональности или инвестировать в решение для миграции, способное преобразовать эти элементы в формат, который может быть перенесен. Скажем сразу, что решения от Quest такое никак не конвертируют и могут разве что перенести такие письма в виде вложений, чтобы пользователь мог их потом открыть через клиент Notes.

Группы и личные адресные книги


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

Взаимодействие с приложениями Notes


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

Ресурсы и почтовые базы данных


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

  • Создания ресурсных почтовых ящиков в целевой среде;
  • Переноса данных из базы данных резервирования в Exchange;
  • Обеспечения того, чтобы пользователи обеих систем могли сотрудничать и использовать ресурсы в Notes и Exchange.

Шаг 4: обеспечение максимальной эффективности миграции


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

Архитектура миграционного решения


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

Процесс миграции


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

Гибкость и самообслуживание


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

Шаг 5: запуск пробной миграции


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

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

Определение объема пилотной миграции


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

Выбор данных и систем


В процессе пилотной миграции важно использовать боевые данные и боевые системы. Это очень важно по некоторым причинам:

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

Установление ожиданий


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

Шаг 6: планирование времени миграции для минимизации влияния на организацию


Группировка пользователей


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

Сроки миграции


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

Шаг 7: запуск миграции и отслеживание ее прогресса


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

Заключение


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

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

Статья на Хабр: Миграция IBM Lotus Notes/Domino в Microsoft Exchange

Quest Migrator for Notes to Exchange на сайте Gals

Quest Coexistence Manager for Notes на сайте Gals

Quest Migrator for Notes to Exchange на сайте Quest

Quest Coexistence Manager for Notes на сайте Quest
Подробнее..

Вернуть пропавший скутер, или история одного IoT мониторинга

23.09.2020 20:15:33 | Автор: admin

Год назад мы запустили пилотную версию промо проекта по децентрализованному прокату электроскутеров.


Изначально проект назывался Road-To-Barcelona, позже стал Road-To-Berlin (отсюда встречающиеся на скриншотах R2B), а в итоге и вовсе был назван xRide.


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


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


Пользователь устанавливал iOS или Android приложение на телефон, подходил к понравившемуся ему скутеру, после чего телефон и скутер устанавливали peer-to-peer соединение, происходил обмен ETH и пользователь мог начать поездку включив скутер через телефон. По завершении поездки так же можно было провести оплату поездки за счет эфира из кошелька пользователя на телефоне.


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


Так в целом и выглядел наш пилот, запущенный в сентябре прошлого года в двух городах Германии: Бонн и Берлин.



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


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


Что и зачем мониторить: скутеры, инфраструктура, зарядки?


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


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


Скутеры


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


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


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


Конечно, необходимо также проверять что происходит с нашими Hardware компонентами:


  • работает ли Bluetooth?
  • работает ли сам GPS модуль?
    • так же у нас была проблема с тем, что GPS мог отсылать неверные координаты и "залипать", а определить это можно было только на уровне дополнительных проверок на скутере,
      и нотифицировать поддержку как можно скорее для устранения проблемы

И последнее: проверки софтверной части, начиная с ОС и загрузки процессора, сети и диска, заканчивая уже более специфичными для нас проверками наших собственных модулей (jolocom, keycloak).


Hardware



Что же представляла наша "железная" часть?
Учитывая максимально сжатые сроки и необходимость быстрого прототипирования мы выбрали для себя максимально простой для реализации и подбора компонентов вариант Raspberry Pi.
Помимо самого Rpi мы имели кастомную борду (которые мы сами разработали и заказывали в Китае для ускорения процесса сборки конечного решения) и набор компонентов реле (для включения/выключения скутера), считыватель заряда батареи, модем, антенны. Все это было компактно укомплектовано в специальную коробочку "xRide box".


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


Docker? Plain linux? и деплой


Вернемся к мониторингу, итак Raspberry что же мы имеем?


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


К сожалению, довольно быстро стало ясно что Docker на RPi хоть и работает, но дает достаточно много накладных расходов, в частности по энергопотреблению.


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


Второй причиной стала одна из библиотек наших партнеров на Node.js (sic!) единственный компонент системы, который не был написан на Go/C/C++.
Авторы библиотеки не успели вовремя предоставить рабочую версию на любом из "нативных" языков.
Мало того, что нода сама по себе не является самым элегантным решением для низкопроизводительных девайсов, так еще и сама библиотека была весьма прожорлива по ресурсам.


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


OS


В итоге, качестве ОС мы, опять же, избрали самый простой вариант и использовали Raspbian (сборка Debian для Pi).
Весь наш софт мы пишем на Go, поэтому и основной hardware-агент модуль в нашей системе мы также написали на Go.
Именно он и отвечает за работу с GPS, Bluetooth, считывание заряда, включение скутера, итд.


Деплой

Тут же встал вопрос о необходимости реализации механизма доставки обновлений на девайсы (OTA) как обновлений самого нашего агента/приложения, так и обновления самой ОС/"прошивки"
(так как новые версии агента могли требовать обновлений ядра или компонентов системы, библиотек итд).


После довольно долгого анализа рынка выяснилось, что существует довольно много решений для доставки обновлений на девайс.
От относительно простых утилит, по большей части ориентированных на обновление/dual-boot вроде swupd/SWUpdate/OSTree до полноценных платформ вроде Mender и Balena.


В первую очередь мы решили, что нас интересуют именно end-to-end решения, поэтому выбор сразу пал на платформы.
Самым Balena была исключена ввиду того, что фактически использует тот же самый Docker внутри своего balenaEngine.
Но отмечу, что несмотря на это, в конечном итоге мы постоянно использовали их продукт Balena Etcher для флеша прошивок на SD карты простая и крайне удобная утилита для этого.


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


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


Ansible

Самым простым решением в нашей ситуации оказалось использование Ansible. Пары playbook'ов для начала было вполне достаточно.
Суть их сводилась к тому, что мы просто подключались с хоста (CI сервер) по ssh к нашим расберри и разливали на них обновления.


В самом начале все было просто нужно было находиться в единой сети с устройствами, разливка шла через Wi-Fi.
В офисе просто находилось десяток тестовых малинок, подключенных к одной сети, каждое устройство имело статический IP адрес так же указанный в Ansible Inventory.


Именно Ansible доставлял наш мониторинг-агент на конечные устройства


3G/LTE


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


В реальности у скутеров вообще не может быть никакого соединения кроме мобильного 3G/LTE (и то не постоянно).
Это накладывает сразу много проблем и ограничений, вроде низкой скорости соединения и нестабильной связи.


Но самое главное в 3G/LTE сети мы не можем просто надеяться на статичный IP присвоенный в сети.
Это частично решается некоторыми провайдерами SIM карт, есть даже специальные симки предназначенные для IoT устройств со статическими IP адресами. Но мы не имели доступа к таким SIM картам и не могли использовать IP адреса.


Конечно, были идеи делать некую регистрацию IP адресов aka service discovery где-то вроде Consul, но от подобных идей пришлось отказаться,
так как у нас в тестах IP адрес мог меняться слишком часто, что приводило к большой нестабильности работы.


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


VPN


В качестве решения этой проблемы мы выбрали VPN а конкретно Wireguard.


Клиенты (скутеры) на старте системы подключались к VPN серверу и держали возможность подключения к ним. Этот туннель и использовался для доставки обновлений.



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


Облачные ресурсы


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


Дано


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


  • Быстрое решение, так как мониторить необходимо уже во время процесса разработки
  • Объем/количество нужно множество метрик
  • Сбор логов обязателен
  • Надежность данные критически важны для успеха запуска
  • Нельзя использовать pull модель нужен push
  • Нужен единый мониторинг не только железа, но и облака

Конечная картинка выглядела примерно так



Выбор стека


Итак, перед нами встал вопрос выбора стека для мониторинга.


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


Существует огромное множество решений для мониторинга,
начиная полноценными системами вроде Nagios, icinga или zabbix и заканчивая уже готовыми решениями по Fleet management.



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


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


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


(B)ELK?


Первое решение, которое реально рассматривалось широко известный ELK стек.
На самом деле он должен называться BELK, ведь начинается все с Beats https://www.elastic.co/what-is/elk-stack



Конечно, ELK это одно из самых известных и мощных решений в области мониторинга, а уж в сборе и обработке логов, так и самое.


Мы подразумевали, что ELK будет использоваться для сбора логов и, так же как долговременное хранилище метрик полученных из Prometheus.
Для визуализации можно использовать Grafan'у.


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


Но все-таки изначально ELK вырос из логов и пока функционал метрик имеет ряд серьезных недостатков:


  • Значительно медленнее Prometheus
  • Интегрируется в куда меньшее количество мест чем Prometheus
  • Сложно настроить алертинг по ним
  • Метрики занимают большое количество места
  • Настройка дашбордов с метриками в Kiban'е значительно сложнее Grafan'ы

В общем, метрики в ELK тяжелые и пока не такие удобные как в других решениях, которых сейчас на самом деле значительно больше чем просто Prometheus: TSDB,
Victoria Metrics, Cortex итд итп. Конечно, очень бы хотелось иметь сразу полноценное all-in-one решение, но в случае с metricbeat выходило слишком много компромиссов.


Да и у самого ELK стека есть ряд непростых моментов:


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

Надо сказать, что в последнее время с последним пунктом стало получше и помимо вывода в open-source X-pack (в том числе аутентификация) начала меняться сама модель прайсинга.
Но на момент, когда мы собирались разворачивать это решение, алертинга не было совсем.
Возможно, можно было попробовать собрать что-то с использованием ElastAlert или других community решений, но все же решили рассмотреть другие альтернативы.


Loki Grafana Prometheus


На данный момент неплохим решением может быть сборка стека мониторинга на основе чисто Prometheus как поставщика метрик,
Loki для логов, а для визуализации можно использовать все ту же Grafana.
К сожалению, на момент старта прода пилота проекта (сентярбь-октябрь 19ого года) Loki еще находился в бета версии 0.3-0.4,
а на момент старта разработки и вовсе не мог рассматриваться как produtcion решение.


Я пока не имею опыта реального использования Loki в серьезных проектах, но могу сказать, что Promtail (агент для сбора логов) здорово работает как для bare-metal, так и для подов в kubernetes.


TICK


Пожалуй, наиболее достойной (единственной?) полнофункциональной альтернативой ELK стеку сейчас можно назвать только TICK стек Telegraf, InfluxDB, Chronograf, Kapacitor.



Я опишу все компоненты ниже более подробно, но в целом идея такая:


  • Telegraf агент для сборки метрик
  • InfluxDB база данных метрик
  • Kapacitor обработчик метрик в реальном времени для алертинга
  • Chronograf веб панель для визуализации

Для InfluxDB, Kapacitor и Chronograf есть официальные helm чарты, которые мы использовали для их разворачивания.


Надо отметить, что в свежей версии Influx 2.0 (beta) Kapacitor и Chronograf стали частью InfluxDB и больше не существуют отдельно


Telegraf



Telegraf это очень легковесный агент для сбора метрик на конечной машине.
Он умеет мониторить огромное количество всего, от nginx до
сервера minecraft.


У него есть ряд классных преимуществ:


  • Быстрый и легкий (написан на Go)
    • Ест минимальное количество ресурсов
  • Push метрик по умолчанию
  • Собирает все необходимые метрики
    • Системные метрики без каких-либо настроек
    • Хардварные метрики вроде информации с датчиков
    • Очень легко добавлять собственные метрики
  • Много плагинов "из коробки"
  • Собирает логи

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


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


Telegraf вообще отличный агент для сборки метрик, даже если вы не используете весь остальной ICK стек.
Многие скрещивают его и с ELK и с различными другими time-series базами по удобству, так как он умеет писать метрики почти куда угодно.


InfluxDB



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


InfluxDB тоже написан на Go и работает, по ощущениям, значительно быстрее в сравнении с ELK на нашем (не самом мощном) кластере.


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


Недостатки $$$ или скалирование ?

У TICK стека есть только один обнаруженный нами недостаток он дорогой. Даже очень.


А что есть в платной версии, чего нет в бесплатной?


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


А именно поднять кластер с High availability можно только в Enterprise версии.


Хотите полноценное HA нужно либо платить, либо городить какие-нибудь костыли. Есть пара решений сообщества например influxdb-ha похоже на грамотное решение, но написано что не подходит для продакшена, а так же
influx-spout простое решение с прокачкой данных через NATS (его тоже придется скалировать, но это решаемо).
Жаль, но оба они, похоже, заброшены нет свежих коммитов, предположу, что дело в скором ожидаемом выходе новой версии Influx 2.0 в которой многое будет иначе (пока информации о скалировании в ней нет).


Официально для бесплатной версии существует Relay фактически это примитивное HA, но только посредством балансировки,
так как все данные будут писаться во все инстансы InfluxDB за load balancer'ом.
У него есть некоторые недостатки вроде потенциальных проблем с перезаписью точек и необходимости создавать базы для метрик заранее
(что при обычной работе с InfluxDB происходит автоматически).
К тому же шардирование не поддерживается, это означает дополнительные накладные расходы на дуплицированные метрики (и обработка и хранение),
которые могли вам быть не нужны, но разделить их возможности нет.


Victoria Metrics?


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



Time-series баз немало, но наиболее подающая надежды Victoria Metrics, у нее целый ряд плюсов:


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

Мы не собирались строить полностью кастомный стек на основе Victoria и основная надежда была на то, что мы сможем воспользоваться ею как drop-in заменой для InfluxDB.


К сожалению, это невозможно, несмотря на то, что поддерживается протокол InfluxDB, это работает только для записи метрик "наружу" доступно только Prometheus API,
а значит натравить Chronograf на нее не получится.
Более того, для метрик поддерживаются только числовые значения (мы использовали строковые значения для кастомных метрик об этом в разделе админка).
Очевидно, по той же причине VM не может хранить логи, как это делает Influx.


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


Выбор базы

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


Основных причин такого выбора было несколько:


  • Нам очень нравился функционал TICK стека целиком
  • Мы уже успели его развернуть и оно отлично работало
  • Сроки поджимали и не оставалось много времени тестировать другие варианты
  • У нас не ожидалось такой большой нагрузки

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


Со стеком и базой решили теперь об остальных компонентах TICK стека.


Kapacitor



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


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


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



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


В Influx 2.0 Kapacitor стал частью DB


Chronograf



Я повидал много различных UI решений для мониторинга, но могу сказать, что по функционалу и UX ничто не сравнится с Chronograf'ом.


Начинали мы использовать TICK стек, как ни странно, с Grafan'ой в качестве веб-интерфейса.
Описывать ее функционал не буду, всем известны ее широкие возможности по настройке всего что угодно.


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


Пожалуй, основное удобство работы с Chronograf в том, что вы можете смотреть внутренности вашей InfluxDB через Explore.


Казалось бы, в Grafana есть почти идентичный функционал, но в реальности настройка дашборда в Chronograf может осуществляться несколькими кликами мыши
(попутно смотря на визуализацию там же), тогда как в Grafana вам все равно рано или поздно придется редактировать JSON конфигурацию
(само собой Chronograf позволяет выгрузить ваши настроенные "руками" даши и редактировать в виде JSON если необходимо но мне никогда не приходилось их трогать после создания на UI).


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


Сами дашборды, помимо приятного визуального стиля, фактически ничем от дашбордов в Grafana или Kibana не отличаются:


Так выглядит то самое окно запросов:


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


Ну и конечно же, Chronograf максимально удобен для просмотра логов. Выглядит это так:



По умолчанию Influx логи заточны под использование syslog и поэтому в них есть важный параметр severity.


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


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


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


Аутентификация


Отдельно стоит упомянуть то, что Chronograf поддерживает OAuth и OIDC в качестве аутентификации.
Это очень удобно, так как позволяет легко прикрутить его к вашему серверу и сделать полноценное SSO.


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


Админка


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


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


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


Один из уже упомянутых плюсов Influx возможность легко создавать свои собственные метрики.
Это позволяет использовать его для огромного множества сценариев.
Мы старались записывать туда всю полезную информацию: заряд батареи, состояние замка, работоспособность датчиков, bluetooth, GPS, множество других healthcheck'ов.
Все это мы и отображали на админ панели.


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


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


Да и вообще так было веселее. Постоянно звучали фразы вроде "Ребята Смитерс умер!"



Строковые метрики


Важно, что InfluxDB позволяет хранить не только числовые значения, как в случае с Victoria Metrics.


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


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


В результате API зарядок было далеко от идеала, но основной проблемой было то, что мы не всегда могли понять их состояние.
Тут на помощь и пришел Influx. Мы просто-напросто записывали приходящий нам строковый status в поле базы InfluxDB без изменений.


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


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


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



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


Очень сильно нам это пригодилось, когда мы разыскивали скутер (смотри выводы в конце).


Мониторинг инфраструктуры


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



Если выделить чисто стек мониторинга, то он выглядит следующим образом:


Из того что мы хотели бы проверять в облаке, это:


  • Базы данных
  • Keycloak
  • Микросервисы

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


Мы следили в основном за работоспособностью подов и потреблением памяти. В случае падения алерты в Slack.


Для отслеживания подов в Kubernetes есть два пути: DaemonSet и Sidecar.
Оба способа подробно описаны в этом блог посте.
Мы использовали Telegraf Sidecar и помимо метрик собирали логи подов.
В нашем случае с логами пришлось повозится. Несмотря на то что Telegraf умеет вытаскивать логи из Docker API, мы хотели иметь единообразный сбор логов с нашими конечными устройствами и настраивали для этого syslog для контейнеров. Возможно, это решение не было красивым, но нареканий в его работе не было и логи хорошо отображались в Chronograf'e.


Мониторить мониторинг???

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


Выводы


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


Как можно делать мониторинг


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


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

Основная проблема TICK стека в бесплатной версии отсутствие возможностей по скалированию. Для нас это не стало проблемой.


Мы не собирали точных данных/цифр о нагрузке, но мы собирали данные с примерно 30и скутеров одновременно.
Каждый из них собирал более трех десятков метрик. Одновременно собирались логи с устройств. Сбор и отправка данных происходили каждые 10 секунд.


Важно отметить, что спустя полторы недели пилота, когда основную массу "детских болячек" удалось исправить и самые важные проблемы уже были решены,
нам пришлось снизить частоту отправки данных на сервер до 30и секунд. Это стало необходимо, потому что трафик на наших LTE SIM картах начал быстро таять.
Основную массу трафика съедали логи, сами метрики даже с 10и-секундным интервалом практически не тратили его.


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


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


TICK идеально для небольших-средних проектов

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


Если у вас нет тысяч подов или сотен машин даже один инстанс InfluxDB прекрасно справится с нагрузкой.
В некоторых случаях вас может устроить Influx Relay как примитивное решение по High Availability.


И, само собой, никто не мешает вам настраивать "вертикальное" скалировние и просто выделить различные сервера под различные типы метрик.


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


В таком случае, на сегодняшний день, я бы порекомендовал посмотреть в сторону сбора метрик через Victoria Metrics и логов с помощью Loki.
Правда, снова оговорюсь, что Loki/Grafana значительно менее удобны (в виду своей большей универсальности) чем готовый TICK, но зато они бесплатны.


Важно: вся описанная здесь информация актуальна для версии Influx 1.8, в данный момент вот-вот должен выйти в релиз Influx 2.0.
Пока не довелось попробовать его в боевых условиях и сложно делать выводы об улучшениях, точно еще лучше стал интерфейс, упростилась архитектура (без kapacitor и chronograf),
появились темплейты ("киллер фича" можно отслеживать игроков в Fortnite и получать нотификации когда твой любимый игрок выигрывает партию). Но, к сожалению, в данный момент в версии 2 нет ключевой вещи, по которой мы выбрали первую версию нет сбора логов.
Этот функционал в Influx 2.0 тоже появится, но каких-либо сроков, даже примерных, найти не удалось.


Как не нужно делать IoT платформы (теперь)


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


Конечный результат и та платформа на основе Ansible + TICK + WireGuard, которую мы собрали самостоятельно нас полностью устраивает. Но на сегодняшний день, я бы порекомендовал внимательней посмотреть на Balena прежде чем пытаться собрать свою IoT платформу самим.


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


А совсем недавно они и вовсе выпустили свою Hardware, которая легко подключается в их экосистему.


Эй, а что с пропавшим скутером?


Итак скутер, "Ральф", бесследно исчез.
Мы сразу побежали смотреть карту в нашей "админке", с данными GPS метрик из InfluxDB.


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


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


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

Подробнее..

Обзор возможностей Kubespray Отличие оригинальной версии и нашего форка

20.09.2020 14:22:27 | Автор: admin

23 сентября 20.00 МСК Сергей Бондарев проведёт бесплатный вебинар Обзор возможностей Kubespray, где расскажет, как готовят kubespray, чтобы получилось быстро, эффективно и отказоустойчиво.


Сергей Бондарев расскажет отличие оригинальной версии и нашего форка:



Отличие оригинальной версии и нашего форка.


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


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


  • собирал кластер etcd;
  • устанавливал кублеты, генерил сертификаты, конфиги и токены доступа для статик подов контролплейна и прочих служебных компонентов;
  • создавал сервис аккаунты для рабочих узлов и подключал их в кластер.

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


В итоге разница между кластерами, созданными моим форком и оригинальным это kube-proxy и сроки действия сертификатов.


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


В Kubeadm куб-прокси запускается, как daemonset, а сертификаты выписываются на 1 год, и их надо периодически продлевать. kubeadm наконец-то научился это делать одной командой.


Разница небольшая, и на сегодня мы используем оба варианта.


Особенности (недостатки) при промышленной эксплуатации:


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


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


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


Например у меня была проблема с кубадмом, когда он падал в момент добавления второго и третьего мастера, и после этого кубспрей делал kubeadm reset на узле, и пробовал добавить мастер еще раз.


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


Opensource как он есть.


Всё это и многое другое на бесплатном вебинаре Обзор возможностей Kubespray 23 сентября 20.00 МСК.


Присоединяйтесь!

Подробнее..

Перевод 3 года с Kubernetes в production вот что мы поняли

21.09.2020 12:22:00 | Автор: admin
Прим. перев.: в очередной статье из категории lessons learned DevOps-инженер австралийской компании делится главными выводами по итогам продолжительного использования Kubernetes в production для нагруженных сервисов. Автор затрагивает вопросы Java, CI/CD, сетей, а также сложности K8s в целом.

Свой первый кластер Kubernetes мы начали создавать в 2017 году (с версии K8s 1.9.4). У нас было два кластера. Один работал на bare metal, на виртуальных машинах RHEL, другой в облаке AWS EC2.

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

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

Вот ключевые уроки, которые мы вынесли из опыта использования Kubernetes в production на протяжении трех лет.

1. Занимательная история с Java-приложениями


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

В 20172018 годах некоторые наши приложения работали на Java восьмой версии. Частенько они отказывались функционировать в контейнерных средах вроде Docker и падали из-за проблем с heap-памятью и неадекватной работы сборщиков мусора. Как оказалось, эти проблемы были вызваны неспособностью JVM работать с механизмами контейнеризации Linux (cgroups и namespaces).

С тех пор Oracle приложила значительные усилия, чтобы повысить совместимость Java с миром контейнеров. Уже в 8-ой версии Java появились экспериментальные флаги JVM для решения этих проблем: XX:+UnlockExperimentalVMOptions и XX:+UseCGroupMemoryLimitForHeap.

Но, несмотря на все улучшения, никто не будет спорить, что у Java по-прежнему плохая репутация из-за чрезмерного потребления памяти и медленного запуска по сравнению с Python или Go. В первую очередь это связано со спецификой управления памятью в JVM и ClassLoader'ом.

Сегодня, если нам приходится работать с Java, мы по крайней мере стараемся использовать версию 11 или выше. И наши лимиты на память в Kubernetes на 1 Гб выше, чем ограничение на максимальный объем heap-памяти в JVM (-Xmx) (на всякий случай). То есть, если JVM использует 8 Гб под heap-память, лимит в Kubernetes на память для приложения будет установлен на 9 Гб. Благодаря этим мерам и улучшениям жизнь стала чуточку легче.

2. Обновления, связанные с жизненным циклом Kubernetes


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

Дело в том, что в Kubernetes слишком много движущихся частей, которые необходимо учитывать при проведении обновлений. Для того, чтобы кластер мог работать, приходится собирать все эти компоненты вместе начиная с Docker и заканчивая CNI-плагинами вроде Calico или Flannel. Такие проекты, как Kubespray, KubeOne, kops и kube-aws, несколько упрощают процесс, однако все они не лишены недостатков.

Свои кластеры мы разворачивали в виртуальных машинах RHEL с помощью Kubespray. Он отлично себя зарекомендовал. В Kubespray были сценарии для создания, добавления или удаления узлов, обновления версии и почти все, что необходимо для работы с Kubernetes в production. При этом сценарий обновления сопровождался предостережением о том, что нельзя пропускать даже второстепенные (minor) версии. Другими словами, чтобы добраться до нужной версии, пользователю приходилось устанавливать все промежуточные.

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

3. Сборка и деплой


Будьте готовы к тому, что придется пересмотреть пайплайны сборки и деплоя. При переходе на Kubernetes у нас прошла радикальная трансформация этих процессов. Мы не только реструктурировали пайплайны Jenkins, но с помощью инструментов, таких как Helm, разработали новые стратегии сборки и работы с Git'ом, тегирования Docker-образов и версионирования Helm-чартов.

Вам понадобится единая стратегия для поддержки кода, файлов с deploymentами Kubernetes, Dockerfiles, образов Docker'а, Helm-чартов, а также способ связать все это вместе.

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

  • Код приложения и его Helm-чарты находятся в разных репозиториях. Это позволяет нам версионировать их независимо друг от друга (семантическое версионирование).
  • Затем мы сохраняем карту с данными о том, какая версия чарта к какой версии приложения привязана, и используем ее для отслеживания релиза. Так, например, app-1.2.0 развертывается с charts-1.1.0. Если меняется только файл с параметрами (values) для Helm, то меняется только patch-составляющая версии (например, с 1.1.0 на 1.1.1). Все требования к версиям описываются в примечаниях к релизу (RELEASE.txt) в каждом репозитории.
  • К системным приложениям, таким как Apache Kafka или Redis (чей код мы не собирали и не модифицировали), у нас иной подход. Нам не были нужны два репозитория, поскольку Docker-тег был просто частью версионирования Helm-чартов. Меняя Docker-тег для обновления, мы просто увеличиваем основную версию в теге чарта.

(Прим. перев.: сложно пройти мимо такой трансформации и не указать на нашу Open Source-утилиту для сборки и доставки приложений в Kubernetes werf как один из способов упростить решение тех проблем, с которыми столкнулись авторы статьи.)

4. Тесты Liveliness и Readiness (обоюдоострый меч)


Проверки работоспособности (liveliness) и готовности (readiness) Kubernetes отлично подходят для автономной борьбы с системными проблемами. Они могут перезапускать контейнеры при сбоях и перенаправлять трафик с нездоровых экземпляров. Но в некоторых условиях эти проверки могут превратиться в обоюдоострый меч и повлиять на запуск и восстановление приложения (это особенно актуально для stateful-приложений, таких как платформы обмена сообщениями или базы данных).

Наш Kafka стал их жертвой. У нас был stateful set из 3 Broker'ов и 3 Zookeeper'ов с replicationFactor = 3 и minInSyncReplica = 2. Проблема возникала при перезапуске Kafka после случайных сбоев или падений. Во время старта Kafka запускал дополнительные скрипты для исправления поврежденных индексов, что занимало от 10 до 30 минут в зависимости от серьезности проблемы. Такая задержка приводила к тому, что liveliness-тесты постоянно завершались неудачей, из-за чего Kubernetes убивал и перезапускал Kafka. В результате Kafka не мог не только исправить индексы, но даже стартовать.

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

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

Обновление: в свежих версиях Kubernetes появился третий тип тестов под названием startup probe. Он доступен как альфа-версия, начиная с релиза 1.16, и как бета-версия с 1.18.

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

5. Работа с внешними IP


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

В своем кластере мы используем Calico как CNI и BGP в качестве протокола маршрутизации, а также для взаимодействия с пограничными маршрутизаторами. В Kube-proxy задействован режим iptables. Доступ к нашему очень загруженному сервису в Kubernetes (ежедневно он обрабатывает миллионы подключений) открываем через внешний IP. Из-за SNAT и маскировки, проистекающих от программно-определяемых сетей, Kubernetes нуждается в механизме отслеживания всех этих логических потоков. Для этого K8s задействует такие инструменты ядра, как сonntrack и netfilter. С их помощью он управляет внешними подключениями к статическому IP, который затем преобразуется во внутренний IP сервиса и, наконец, в IP-адрес pod'а. И все это делается с помощью таблицы conntrack и iptables.

Однако возможности таблицы conntrack небезграничны. При достижении лимита кластер Kubernetes (точнее, ядро ОС в его основе) больше не сможет принимать новые соединения. В RHEL этот предел можно проверить следующим образом:

$  sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_maxnet.netfilter.nf_conntrack_count = 167012net.netfilter.nf_conntrack_max = 262144

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

Это полностью сбило нас с толку, когда мы только начинали в 2017 году. Однако сравнительно недавно (в апреле 2019-го) проект Calico опубликовал подробное исследование под метким названием Why conntrack is no longer your friend (есть такой её перевод на русский язык прим. перев.).

Действительно ли вам нужен Kubernetes?


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

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

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

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

Помните, что технология исключительно ради технологии бессмысленна.

P.S. от переводчика


Читайте также в нашем блоге:

Подробнее..

АйТиБалаган! 3 Зачем DevOps-инженеру программирование и что такое виртуализация

21.09.2020 14:20:44 | Автор: admin

IT-балаганят, спорят, делятся кейсами:



Темы:


  • Что такое DevOps;
  • Зачем разработчику уметь в DevOps;
  • Зачем DevOps-инженеру уметь в программирование?
  • Виртуализация VS контейнеризация;
  • Минимальный набор знаний по DevOps в 2к20;
  • Будущее DevOps;
  • VMWare юзкейсы;
  • VMWorld 2020 онлайн что за зверь?

Навигация:


О DevOps и всём-всём-всём...

0:00 Начало;
3:35 Представление гостей;
7:38 Что такое DevOps;
33:30 Зачем DevOps-инженеру программирование;
41:40 Фреймворки в DevOps;
49:50 Как уживаться разработчикам и девопсеру;
1:12:40 Будущее DevOps;
1:19:30 Минимальный набор знаний для девопсера;
1:26:30 Перерыв;
1:32:20 Девопс это сисадмин для программистов?
1:34:40 Про зарплаты;
1:38:00 Про контейнеризацию;
1:47:55 Про продукты VWware и виртуализацию;
1:57:15 Про VMWorld;
2:00:20 Конференции и ресурсы по девопсу;
2:10:00 Как быть с большим объемом информации в профессии;
2:23:23 Про безопасность и DevOps;
2:48:10 Куда развиваться девопсеру.


P.S. В АйТиБалагане раз и не два поминался SRE. Если тема вам интересна, и есть желания стать SRE-инженером, то есть смысл присмотреться к онлайн-интенсиву SRE. На три дня вы погрузитесь в теорию и практику SRE: разработаете и будете поддерживать сайт, состоящий из нескольких микросервисов. Научитесь правильно распределять ограниченные ресурсы для обеспечения быстродействия, отказоустойчивости и доступности сайта для максимальной надежности, достаточной, чтобы были довольны пользователи. 1113 декабря сего года wellcome!


Спикеры курса SRE

Подробнее..

Наиболее интересные факты о Ceph по результатам опроса пользователей в 2019 году

23.09.2020 00:14:39 | Автор: admin
TL;DR: наиболее интересные факты о Ceph в таблицах и графиках, полученных из результатов опроса пользователей Ceph в 2019 году.



Какой у вас тип организации?


Ответили на вопрос: 405
Пропустили вопрос: 0
Ответ Ответили %
Коммерческая 257 63.46
Правительственная 19 4.69
Военная 0 0
Образовательная 57 14.07
Некоммерческая 16 3.95
Другая 56 13.82



Почему используете Ceph?


Ответили на вопрос: 405
Пропустили вопрос: 0
Ответ Ответили %
Открытый исходный код 367 90.62
Масштабируемость 326 80.49
Стоимость 247 60.99
Функционал 223 55.06
Отказоустойчивость 309 76.30
Надежность\живучесть\целостность данных 279 68.89
Производительность 125 30.86
Возможность внедрения со смежными технологиями 120 29.63
Другое 13 3.21



Как давно используете Ceph?


Ответили на вопрос: 405
Пропустили вопрос: 0
Ответ Ответили %
Менее года 72 17.78
1-2 года 65 16.05
2-5 лет 203 50.12
Более 5 лет 58 14.32
Не пользуюсь 7 1.73



В каких странах у вас развернут Ceph?


Ответили на вопрос: 405
Пропустили вопрос: 0
Ответ Ответили %
Другая 249 61.48
США 87 21.48
Германия 73 18.02
Китай 30 7.41
Великобритания 29 7.16
Россия 26 6.42
Франция 20 4.94



Как устанавливаете Ceph?


Ответили на вопрос: 344
Пропустили вопрос: 61
Ответ Ответили %
Пакеты от разработчиков 170 49.42
Пакеты из дистрибутивов 131 38.08
Пакеты от производителей 93 27.03
Собираем свои пакеты 26 7.56
Собираем свою версию 12 3.49



N.B. Если всё ещё немного плаваете в вопросах, как устанавливать и разворачивать правильно Ceph c 15 октября запускается курс по Ceph от практиков. Вы изначально получите системные знания по базовым понятиям и терминам, а по окончании курса научитесь полноценно устанавливать, настраивать и управлять Ceph.


Как разворачиваете?


Ответили на вопрос: 312
Пропустили вопрос: 93
Ответ Ответили %
Ansible 134 42.95
ceph-deploy 133 42.63
Другое (тут Proxmox + CLI) 75 24.04



Применяемая операционная система


Ответили на вопрос: 344
Пропустили вопрос: 61
Ответ Ответили %
Ubuntu 131 38.08
Debian 101 29.36
CentOS 125 36.34
RHEL 34 9.88
SLES\OpenSuse 21 6.10
Другая 55 15.99



Какое оборудование применяете?


Ответили на вопрос: 343
Пропустили вопрос: 62
Ответ Ответили %
Supermicro 171 50.00
Dell 131 38.30
HPE 89 26.02
Другое 162 47.23



Какие накопители применяете?


Ответили на вопрос: 342
Пропустили вопрос: 63
Ответ Ответили %
HDD 305 89.18
SSD (SAS, SATA) 261 76.32
NVMe 161 47.08
Другие 21 6.14



Используете отдельную сеть для OSD?


Ответили на вопрос: 342
Пропустили вопрос: 63
Ответ Ответили %
Да 249 72.81
Нет 93 27.19


Какое ПО используете совместно с Ceph?


Ответили на вопрос: 340
Пропустили вопрос: 65
Ответ Ответили %
RBD на Linux серверах 123 36.18
Proxmox 114 33.53
KVM 105 30.88
OpenStack 97 28.53
Kubernetes 88 25.88
Другое 178 52.35



Для чего используете RBD?


Ответили на вопрос: 295
Пропустили вопрос: 110
Ответ Ответили %
Виртуализация 232 78.64
Резервное копирование 133 45.08
Облака 122 41.36
Контейнеры 117 39.66
Архивное хранилище 94 31.86



Для чего используете RGW?


Ответили на вопрос: 163
Пропустили вопрос: 242
Ответ Ответили %
Архивное хранение 105 64.42
Резервное копирование 92 56.44
Big data и аналитика 61 37.42



Для чего используете CephFS?


Ответили на вопрос: 184
Пропустили вопрос: 221
Ответ Ответили %
NAS общего назначения 98 53.26
Резервное копирование 87 47.28
Домашние каталоги 63 34.24
Архивное хранение 54 29.35
Media\Streaming 44 23.91



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


Ответили на вопрос: 312
Пропустили вопрос: 93
Ответ Ответили %
Ceph Dashboard 170 54.49
Grafana (свои настройки) 135 43.27
Prometheus 126 40.38
Proxmox 91 29.17
Zabbix 60 19.23
Nagios\Icinga 54 17.31



N.B. Если есть необходимость подтянуть, а то и научиться правильному логированию и мониторингу, добро пожаловать на курс Мониторинг и логирование инфраструктуры в Kubernetes. Сейчас можно приобрести курс с существенной скидкой. На курсе узнаете Узнаете, что именно мониторить, какие метрики собирать и как настраивать алерты для оперативного поиска и устранения проблем в кластере. Какие метрики стоит собирать с помощью Prometheus? Как визуализировать мониторинг с помощью Grafana и как грамотно настроить алерты?
Данные для графиков взяты отсюда.
Подробнее..

Перевод Наши выводы за год миграции GitLab.com на Kubernetes

23.09.2020 10:08:04 | Автор: admin
Прим. перев.: адаптацию Kubernetes в GitLab считают одним из двух главных факторов, способствующих росту компании. Тем не менее, до недавнего времени инфраструктура онлайн-сервиса GitLab.com была построена на виртуальных машинах, и только около года назад началась её миграция в K8s, которая до сих пор не завершена. Рады представить перевод недавней статьи SRE-инженера GitLab о том, как это происходит и какие выводы делают инженеры, участвующие в проекте.



Вот уже около года наше инфраструктурное подразделение занимается миграцией всех сервисов, работающих на GitLab.com, в Kubernetes. За это время мы столкнулись с проблемами, связанными не только к перемещением сервисов в Kubernetes, но и с управлением гибридным deployment'ом во время перехода. О ценных уроках, полученных нами, и пойдет речь в этой статье.

С самого начала GitLab.com его серверы работали в облаке на виртуальных машинах. Этими виртуальными машинами управляет Chef, а их установка происходит с помощью нашего официального Linux-пакета. Стратегия развертывания на случай, если нужно обновить приложение, состоит в простом обновлении парка серверов скоординированным последовательным образом с помощью CI-пайплайна. Этот метод пусть медленный и чуточку скучный гарантирует, что GitLab.com применяет те же способы установки и конфигурирования, что и пользователи автономных (self-managed) инсталляций GitLab, применяющие для этого наши Linux-пакеты.

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

Первые шаги к Kubernetes и cloud-native GitLab


В 2017-м был создан проект GitLab Charts для подготовки GitLab к развертыванию в облаке, а также для того, чтобы дать пользователям возможность устанавливать GitLab в кластеры Kubernetes. Тогда мы знали, что перенос GitLab в Kubernetes увеличит возможности масштабирования SaaS-платформы, упростит развертывания и повысит эффективность использования вычислительных ресурсов. В то же время многие функции нашего приложения зависели от примонтированных NFS-разделов, что замедляло переход с виртуальных машин.

Стремление к cloud native и Kubernetes позволило нашим инженерам планировать постепенный переход, в ходе которого мы отказались от некоторых зависимостей приложения от сетевых хранилищ, попутно продолжая разрабатывать новые функции. С тех пор, как мы начали планировать миграцию летом 2019-го, многие из этих ограничений были устранены, и процесс перевода GitLab.com на Kubernetes теперь идет полным ходом!

Особенности работы GitLab.com в Kubernetes


Для GitLab.com мы используем единый региональный кластер GKE, обрабатывающий весь трафик приложения. Чтобы минимизировать сложность (без того мудреной) миграции, мы концентрируемся на сервисах, которые не зависят от локального хранилища или NFS. GitLab.com использует преимущественно монолитную кодовую базу на Rails, и мы направляем трафик в зависимости от характеристик рабочей нагрузки на различные endpoint'ы, изолированные в свои собственные пулы узлов.

В случае фронтенда эти типы делятся на запросы к web, API, Git SSH/HTTPS и Registry. В случае бэкенда мы разбиваем job'ы в очереди по различным характеристикам в зависимости от предопределенных границ ресурсов, которые позволяют нам устанавливать целевые показатели уровня обслуживания (Service-Level Objectives, SLOs) для различных нагрузок.

Все эти сервисы GitLab.com настроены с помощью немодифицированного Helm-чарта GitLab. Конфигурация проводится в субчартах, которые могут быть выборочно включены по мере того, как мы постепенно переносим сервисы в кластер. Даже с учетом того, что было решено не включать в миграцию некоторые из наших stateful-сервисов, такие как Redis, Postgres, GitLab Pages и Gitaly, использование Kubernetes позволяет радикально сократить число VM, которыми управляет Chef в настоящее время.

Прозрачность и управление конфигурацией Kubernetes


Все настройки управляются самим GitLab'ом. Для этого используются три конфигурационных проекта на основе Terraform и Helm. Мы стараемся везде по возможности использовать сам GitLab для запуска GitLab'а, но для эксплуатационных задач у нас функционирует отдельная инсталляция GitLab. Она нужна для того, чтобы не зависеть от доступности GitLab.com при проведении развертываний и обновлений GitLab.com.

Хотя наши пайплайны для кластера Kubernetes работают на отдельной инсталляции GitLab, есть у репозиториев кода есть зеркала, публично доступные по следующим адресам:

  • k8s-workloads/gitlab-com конфигурационная обвязка GitLab.com для Helm-чарта GitLab;
  • k8s-workloads/gitlab-helmfiles содержит конфигурации для сервисов, которые не связаны с приложением GitLab непосредственно. В их число входят конфигурации для ведения логов и мониторинга кластера, а также для интегрированных инструментов вроде PlantUML;
  • Gitlab-com-infrastructure конфигурация Terraform для Kubernetes и старой (legacy) VM-инфраструктуры. Здесь настраиваются все ресурсы, необходимые для запуска кластера, включая сам кластер, пулы узлов, учетные записи служб, резервирование IP-адресов.


При внесении изменений показывается общедоступное краткое резюме со ссылкой на подробный diff, который SRE анализирует перед внесением изменений в кластер.

Для SRE ссылка ведет на подробный diff в инсталляции GitLab, которая используется для эксплуатации и доступ к которой ограничен. Это позволяет сотрудникам и сообществу без доступа к эксплуатационному проекту (он открыт только для SRE) просматривать предлагаемые изменения в конфигурации. Сочетая общедоступный экземпляр GitLab'а для кода с закрытым экземпляром для CI-пайплайнов, мы сохраняем единый рабочий процесс, в то же время гарантируя независимость от GitLab.com при обновлениях конфигурации.

Что мы выяснили за время миграции


В процессе переезда был накоплен опыт, который мы применяем к новым миграциям и deploymentам в Kubernetes.

1. Рост расходов из-за трафика между зонами доступности



Посуточная egress-статистика по парку Git-хранилищ на GitLab.com

Google делит свою сеть на регионы. Те, в свою очередь, разбиваются на зоны доступности (AZ). Git-хостинг связан с большими объемами данных, поэтому нам важно контролировать сетевой egress. В случае внутреннего трафика egress бесплатен только в том случае, если он остается в границах одной зоны доступности. На момент написания этой статьи мы отдаем примерно 100 Тб данных в обычный рабочий день (и это только для Git-репозиториев). Сервисы, которые в нашей старой топологии, основанной на VM, находились на одних и тех же виртуальных машинах, теперь работают в разных pod'ах Kubernetes. Это означает, что некоторая часть трафика, которая раньше была локальной для VM, может потенциально выходить за пределы зон доступности.

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

2. Limit'ы, request'ы ресурсов и масштабирование



Число реплик, обрабатывающих production-трафик на registry.gitlab.com. Трафик достигает своего пика в ~15:00 UTC.

Наша история с миграцией началась в августе 2019-го, когда мы перенесли первый сервис реестр контейнеров GitLab (GitLab Container Registry) в Kubernetes. Этот критически важный сервис с высоким трафиком хорошо подошел для первой миграции, поскольку представляет собой stateless-приложение с малым числом внешних зависимостей. Первой проблемой, с которой мы столкнулись, стало большое число вытесненных pod'ов из-за нехватки памяти на узлах. Из-за этого нам пришлось менять request'ы и limit'ы.

Было обнаружено, что в случае приложения, у которого потребление памяти растет со временем, низкие значения для request'ов (резервирующих память для каждого pod'а) вкупе с щедрым жестким limit'ом на использование приводили к насыщению (saturation) узлов и высокому уровню вытеснений. Чтобы справиться с этой проблемой, было решено увеличить request'ы и снизить limit'ы. Это сняло давление с узлов и обеспечило жизненный цикл pod'ов, который не оказывал слишком высокого давления на узел. Теперь мы начинаем миграции с щедрыми (и почти одинаковыми) значениями request'ов и limit'ов, корректируя их по необходимости.

3. Метрики и логи



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

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

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

Параллельное обслуживание одних и тех же запросов на старой VM-инфраструктуре и новой, основанной на Kubernetes, представляло собой уникальную задачу. В отличие от миграции типа lift-and-shift (быстрый перенос приложений как есть в новую инфраструктуру; подробнее можно прочитать, например, здесь прим. перев.), параллельная работа на старых VM и Kubernetes требует, чтобы инструменты для мониторинга были совместимы с обеими средами и умели объединять метрики в один вид. Важно, что мы используем одни и те же dashboardы и запросы к логам, чтобы добиться согласованной наблюдаемости во время переходного периода.

4. Переключение трафика на новый кластер


Для GitLab.com часть серверов выделяется под канареечную (canary) стадию. Канареечный парк обслуживает наши внутренние проекты, а также может включаться пользователями. Но в первую очередь он предназначен для проверки изменений, вносимых в инфраструктуру и приложение. Первый перенесенный сервис начал с приема ограниченного объема внутреннего трафика, и мы продолжаем использовать этот метод, чтобы убедиться в соблюдении SLO перед тем, как направить весь трафик в кластер.

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

5. Резервные мощности pod'ов и их использование


Почти сразу была выявлена следующая проблема: pod'ы для сервиса Registry стартовали быстро, однако запуск pod'ов для Sidekiq занимал до двух минут. Продолжительный запуск pod'ов для Sidekiq стал проблемой, когда мы приступили к миграции в Kubernetes рабочих нагрузок для worker'ов, которым нужно быстро обрабатывать job'ы и быстро масштабироваться.

В данном случае урок заключался в том, что, хотя Horizontal Pod Autoscaler (HPA) в Kubernetes хорошо справляется с ростом трафика, важно принимать во внимание характеристики рабочих нагрузок и выделять резервные мощности pod'ов (особенно в условиях неравномерного распределения спроса). В нашем случае наблюдался внезапный всплеск job'ов, влекущий за собой стремительное масштабирование, что приводило к насыщению ресурсов CPU до того, как мы успевали масштабировать пул узлов.

Всегда есть соблазн как можно больше выжать из кластера, однако мы, изначально столкнувшись с проблемами с производительностью, теперь начинаем с щедрого pod budget'а и уменьшаем его впоследствии, пристально следя за SLO. Запуск pod'ов для сервиса Sidekiq значительно ускорился и теперь в среднем занимает около 40 секунд. От сокращения времени запуска pod'ов выиграл как GitLab.com, так и наши пользователи инсталляций self-managed, работающие с официальным Helm-чартом GitLab.

Заключение


После переноса каждого сервиса мы радовались преимуществам использования Kubernetes в production: более быстрому и безопасному деплою приложения, масштабированию и более эффективному распределению ресурсов. Причем плюсы миграции выходят за рамки сервиса GitLab.com. От каждого улучшения официального Helm-чарта выигрывают и его пользователи.

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


P.S. от переводчика


Читайте также в нашем блоге:

Подробнее..

1113 декабря онлайн-интенсив SRE Одна из самых востребованных IT-профессий в мире

24.09.2020 14:19:46 | Автор: admin

Как совсем недавно была мода и высокий спрос на DevOps-инженеров, так сейчас рекрутеры крупнейших компаний ищут Site Reliability Engineer. Достаточно зайти на сайты крупнейших компаний, лидеров IT-рынка, чтобы в этом убедиться. Apple, Google, Booking, Amazon.


Site Reliability Engineering это билет в открытый мир IT. Любая страна, любая IT-компания.


От Apple до Google






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


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



Что будет на курсе:


Строить


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


Ломать


Рассмотрите внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки. Разберетесь в устойчивости, error budget, практике тестирования, управлении прерываниями и операционной
нагрузкой.


Чинить


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


Изучать


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


Преподавать вам будут спикеры-практики:



Интенсив пройдёт в декабре 2020, а именно 1113 декабря. Каждый день начинаем в 10:00, проверка связи в 9:45. По расписанию занятия идут до 19:00 с перерывом на обед.


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


Пока ещё действует акционное предложение. Осталось 28 мест из 30.


Никогда не поздно всё поменять!

Подробнее..

Перевод Как меняется бизнес Docker для обслуживания миллионов разработчиков, часть 1 Хранилище

24.09.2020 16:22:36 | Автор: admin


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


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


Подробный анализ образов Docker Hub


Доставка приложений переносимым, безопасным и ресурсоэффективным способом требует инструменты и сервисы для безопасного хранения и совместного использования для вашей команды разработчиков. На сегодняшний день Docker с гордостью предлагает крупнейший в мире registry для образов контейнеров, Docker Hub, используемый более 6.5 миллионов разработчиков по всему миру. В настоящее время в Docker Hub хранится более 15ПБ образов контейнеров, охватывающих всё, начиная от популярнейших баз данных с хранением данных в оперативной памяти, и заканчивая платформами поточной передачи событий, тщательно отобранных и доверенных официальных образов Docker, а также порядка 150 миллионов образов, созданных сообществом Docker.


Согласно отчету, полученному нашими внутренними аналитическими инструментами, из 15 ПБ образов, хранящихся в Docker Hub, более 10ПБ не использовалось более полугода. Мы обнаружили, копнув глубже, что более 4.5ПБ этих неактивных образов связаны с бесплатными учетными записями. Многие такие образы использовались короткое время, включая образы, полученные из конвейеров CI с Docker Hub, настроенных так, что удаление временных образов игнорировалось.


Из-за большого объема неактивных данных, простаивающих в Docker Hub, команда столкнулась со сложным вопросом: как ограничить эти данные, за которые Docker ежемесячно платит, не влияя при этом на остальных клиентов Docker?


Основные принципы, принятые для решения проблемы были такими:


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

Помощь разработчикам в управлении неактивными образами


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


В соответствии с новой политикой, с 1 ноября 2020 года, образы, размещенные в бесплатных репозиториях Docker Hub, манифест которых не обновлялся последние полгода, будут удалены. Данная политика не применима к образам, хранимых на платных учетных записях Docker Hub, или учетных записях проверенных издателей образов Docker, а также официальным образам Docker.


  • Пример 1: Молли, пользователь бесплатной учетной записи, закачала в Docker Hub 1 января 2019 года образ с меткой molly/hello-world:v1. Этот образ никогда не скачивался с момента публикации. Этот помеченный образ будет считаться неактивным начиная с 1 ноября 2020 года, когда новая политика начнет действовать. Образ и любая метка, указывающая на него, будут удалены 1 ноября 2020 года.
  • Пример 2: У Молли есть образ без метки molly/myapp@sha256:c0ffee, закачан 1 августа 2018 года. Последнее скачивание было 1 августа 2020 года. Этот образ считается активным, и не будет удален 1 ноября 2020 года.

Минимизация влияния на сообщество разработчиков


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


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



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


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


Следите за сообщениями по e-mail касательно любых образов с истекающим сроком действия, либо перейдите на тарифные планы Pro или Team для хранения неактивных образов без ограничений.


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


P.S. Учитывая то, что технология Docker не теряет актуальности, как заверяют её создатели, совсем не лишним было бы изучить эту технологию от и до. Тем более это всегда в пользу, когда вы выработаете с Kubernetes. Если хотите познакомиться с best practice кейсами, чтобы понять, где и как лучше использовать Docker, рекомендую комплексный видеокурс по Docker, в котором мы разберем все его инструменты. Полная программа курса на странице курса.

Подробнее..

Перевод Как масштабируется бизнес Docker для обслуживания миллионов разработчиков, часть 2 Исходящие данные

26.09.2020 12:23:55 | Автор: admin


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


В первой части мы подробно рассмотрели образы, хранимые в Docker Hub, крупнейшем registry образов контейнеров. Мы пишем об этом для того, чтобы вы лучше понимали, как наши обновленные Условия обслуживания повлияют на команды разработчиков, использующих Docker Hub для управления образами контейнеров и конвейерами CI\CD.


Об ограничениях по частоте скачивания было объявлено ранее в наших Условиях обслуживания. Мы подробнее рассмотрим ограничения по частоте, которые вступят в силу с 1 ноября 2020 года:


Бесплатный тарифный план, анонимные пользователи: 100 скачиваний за 6 часов
Бесплатный тарифный план, авторизованные пользователи: 200 скачиваний за 6 часов
Тарифный план Pro: без ограничений
Тарифный план Team: без ограничений


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


N.B. Больше тонкостей и best practice кейcов вы получите на курсе Docker от практиков. Причём вы можете проходить его, когда вам удобно и по времени, и по настрою.


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


Подробный анализ частот скачивания образов Docker Hub


Мы потратили много времени анализируя скачивание образов из Docker Hub, чтобы определить причину ограничения скорости, а также как именно нужно ограничивать. То, что мы увидели, подтвердило, что фактически все пользователи скачивают образы с предсказуемой скоростью для типовых рабочих процессов. Однако есть заметное влияние небольшого числа анонимных пользователей, например порядка 30% всех скачиваний исходят только от 1% анонимных пользователей.



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


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


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


К примеру, если у вас уже есть образ, Docker Engine выдаст запрос на манифест, поймет, что у него уже есть все необходимые слои на основе принятого манифеста, после чего остановится. С другой стороны если вы скачиваете образ, поддерживающий несколько архитектур, запрос на манифест вернет список манифестов образов для каждой поддерживаемой архитектуры. Затем Docker Engine выдаст еще один запрос на манифест касательно конкретной архитектуры, на которой он работает, в ответ получит список всех слоев образа. Затем он будет запрашивать каждый отсутствующий слой (blob).


N.B. Более широко эта тема раскрыта на курсе Docker, в котором мы разберем все его инструменты: от основных абстракций до параметров сети, нюансов работы с различными ОС и языками программирования. Вы познакомитесь с технологией и поймете, где и как лучше использовать Docker.


Получается, что скачивание образа это на самом деле один или два запроса манифеста, а также от нуля и до бесконечности запросы слоев (blob). Исторически Docker отслеживал частоту скачивания на основе слоев, поскольку это наиболее связано с использованием полосы пропускания. Но тем не менее, мы прислушались к сообществу, что так сложнее, ведь нужно отслеживать запрашиваемое число слоев, что приведет к игнорированию best practices касательно работы с Dockerfile, а также интуитивно непонятнее для пользователей, желающих просто работать с registry, не сильно разбираясь в деталях.


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


Ждем ваши отзывы


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


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


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


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


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

Подробнее..

Двадцать интервью за две недели. Краткие выводы длинным текстом

18.09.2020 22:22:25 | Автор: admin

image


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


Вводная


Сразу скажу, мой опыт относится к позиции "senior devops / sre". На этом рынке спрос больше, чем предложение. Всего со мной контактировало около 20 компаний. Где-то я выходил в финал, где-то сходил с дистанции после первого интервью.


Я разместил резюме на трех сайтах и в одном телеграм канале.
Это дало огромный поток входящих звонков и сообщений. Дело даже не дошло до изучения вакансий на сайтах. И я просто не успевал смотреть компании, которые только жали кнопочку "интересный кандидат".
Вывод для HR: Пишите и звоните первыми (наверное, все HR и так это знают).
Вывод для соискателей: Необязательно публиковать свое резюме везде. Пара тройка главных мест и приготовьтесь к общению.
Вывод для обоих: Запаситесь вежливостью и постарайтесь отвечать всем. Вежливый отказ лучше игнора. А вежливый фидбек то, что делает мир лучше.


Общие условия


Где-то 90% компаний предлагают рыночный уровень ЗП и похожие условия: тк рф, белую ЗП в рублях, дмс (почти у всех), что-то пожевать в офисе.


ДМС есть, но не все ДМС одинаково хороши. Спрашивайте, не только есть ли ДМС, но и от какой компании. От себя могу порекомендовать ту, которая начинается на "best" и заканчивается на "doctor" :-). Интересные исключения: у кого-то ситуация "нет ДМС, зато есть фитнес". В одной компании оплачивают 50% медицинских расходов.


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


Размер компании


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


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


Уровень ЗП


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


Я шел на эксперименты и повышал зарплатные ожидания в резюме на сайтах, но мне продолжали звонить (причем я уточнял, какую сумму они видели в резюме). Торг в большую сторону начинался, когда мне были готовы дать оффер, но я говорил, что у меня уже есть оффер от другой компании. Торга в меньшую сторону, "указать в резюме много, а потом согласиться на меньше" не было вообще. Мне сразу говорили, что не готовы столько платить.
Вывод: Слишком завышать зарплатные ожидания тоже не надо. У вас не будет шанса доказать, что вы стоите этих денег. А так же не будет шанса поторговаться вниз.
Лучше поставить среднюю или чуть выше и торговаться вверх, на этапе оффера.
Лайфхак: Но если много звонят повышайте ожидания. Если мало звонят понижайте.


Строчки "высокая ЗП", "конкурентная ЗП", "хорошие финансовые условия".
Их вставляют в резюме, но они ничего не значат, когда разговор идет в стиле: "сколько вы хотите?". Даже строчка "бонусы" может означать следующее: "По договору, ваш оклад будет 85%, но вы всегда будете получать 15% бонус".


Денежные бонусы


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


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


Странные условия


Иногда бывают компании с условиями, которые я бы назвал странными для моего случая. Например, строгий дресс код. Или 85% ЗП на этапе испытательного срока. Если там была рыночная ЗП, я отказывался, но старался дать честный фидбек.
Совет соискателям: Если что-то вам кажется странным или недопустимым, не тратьте время. Но не бойтесь давать фидбек и честно указывайте странности, как причину отказа. Возможно, компания готова меняться и ваш фидбек ей в этом поможет. Например, мне сказали "забудьте про 85%".
Вопрос компаниям: Какой смысл в странных условиях? Есть куча компаний, которые готовые платить N денег. Соискатель будет получать свои N денег в одном месте, на одних условиях, или те же N денег в другом месте на других условиях.


Иногда есть странные компании, которые готовы платить сильно выше рынка. В таких случаях надо быть крайне осторожным, как сапёр на минном поле. Надо смотреть очень внимательно, будет ли вам там комфортно работать. Потому что вы рискуете стать заложником компании с такой ЗП. А, если уйдете, будет очень больно переходить на меньшую зп.
Логика простая: Если вы три-шесть месяцев будете получать на 30-50% выше рынка, но сожжете кучу нервных клеток, это вам аукнется сильнее, чем заработанные деньги. Прибавьте к этому стресс от падения уровня дохода, когда вы перейдете на работу с рыночной ЗП. Одним словом, четыре буквы.


Фидбек


Каждый раз после интервью я просил дать фидбек. Просил сказать, что бы они рекомендовали мне подтянуть, чтобы стать более интересным для них. Если я не подойду, как кандидат, естественно. Я думал, что это станет уберфичей моего поиска работы data driven career и все такое :-)


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


По технологиям


Это мой личный взгляд и, конечно же, я капитаню, ошибаюсь, да и вообще ничего не понимаю)
Но я вижу запрос на знание современных технологий: виртуализация/облака, docker, ci/cd, пайплайны, ansible, python, kubernetes, prometheus, ELK и т.д.
Это то, что я видел в первых строчках большого количества вакансий, в блоке "обязательно". Похоже, это то, куда все движутся, и уже давно.
Я очень хочу двигаться в одном направлении со всеми, поэтому выставил вот такие приоритеты при выборе компании:


  1. Те, кто уже давно там.
  2. Те, кто ещё не там, но хочет.
  3. Те, кому это и не надо.

История одного парня


Расскажу историю одного парня. Он был большим профессионалом в классических технологиях и подходах. Но строчки в его резюме про "большой опыт в таких-то технологиях" больше совпадали с блоком "дополнительные пожелания" в вакансиях работодателей (там, где обычно про highload опыт). С блоком "обязательные требования" все было не так хорошо опыта в современных технологиях было не так много. А зарплатные ожидания были неплохие)


В результате не так много компаний были готовы платить много денег.
Парень сделал для себя простой вывод, который может пригодится таким же "старичкам".
Большой опыт в старых highload технологиях это хороший бонус. Но одного его недостаточно без знания современных технологий. То есть, работу найти можно, но очень большую ЗП вам не предложат. Если хотите быть востребованными, необходимо иметь или набирать опыт в современном стеке. А такой опыт проще всего получить в компаниях первого типа ("те, кто уже давно там")


Интересные случаи


Все их ждали, полагаю :-)


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


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


Вместо резюме


Я не встретил неадекватности со стороны компаний (после которого бросаются писать обличающие статьи). У меня почти не было случаев, когда HR наугад кидал мне неправильную вакансию (только раз предложили фронтенд). В общении я получал адекватность и вежливость. Возможно, дело в том, что я старался быть вежливым сам. Поэтому получал вежливость в ответ.


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


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

Подробнее..

Перевод Какие возможности появились у утилиты rdiff-backup благодаря миграции на Python 3

22.09.2020 10:23:41 | Автор: admin
В процессе миграции на Python 3 разработчики утилиты rdiff-backup усовершенствовали её, добавив много новых фич.



В марте 2020 года вышел второй крупный релиз утилиты rdiff-backup. Второй за 11 лет. Во многом, это объясняется прекращением поддержки Python 2. Разработчики решили совместить приятное с полезным и доработали функционал утилиты.

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

Второе рождение rdiff-backup пережила благодаря команде энтузиастов, которую возглавили Эрик Зольф и Патрик Дюфресне из IKUS Software, а также Отто Кекяляйнен из Seravo.


Новые фичи


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

Автоматизация на базе Travis CI


Другое важнейшее улучшение это конвейер CI/CD на базе распределённого веб-сервиса Travis CI. Теперь пользователи смогут запускать rdiff-backup в различных тестовых средах без риска сломать работающий проект. Конвейер CI/CD позволит выполнять автоматизированную сборку и доставку для всех основных платформ.

Простая установка с помощью yum и apt


Новая версия работает на большинстве ОС семейства Linux Fedora, Red Hat, Elementary, Debian и многих других. Разработчики постарались подготовить все необходимые открытые репозитории для лёгкого доступа к утилите. Установить rdiff-backup можно с помощью менеджера пакетов или пошаговой инструкции на GitHub-странице проекта.

Новый дом


Сайт проекта переехал с Savannah на GitHub Pages (rdiff-backup.net), разработчики обновили контент и дизайн сайта.

Как работать с rdiff-backup


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

Бэкап


Чтобы запустить бэкап на локальном диске (например, USB), введите команду rdiff-backup, затем имя источника (откуда будете копировать файлы) и путь к каталогу, в который вы планируете сохранить их.

Например, чтобы сделать бэкап на локальном диске с именем my_backup_drive, введите:

$ rdiff-backup /home/tux/ /run/media/tux/my_backup_drive/

Для сохранения файлов во внешнем хранилище введите путь к удалённому серверу вместе со знаком ::

$ rdiff-backup /home/tux/ tux@example.com::/my_backup_drive/

Вероятно, ещё вам потребуются SSH ключи для доступа на сервер.

Восстановление файлов из бэкапа


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

Тут нам на помощь придут команды копирования cp для локального диска и scp для удалённого сервера.

Для локального диска нужно написать, например, такое:

$ cp _run_media/tux/my_backup_drive/Documents/example.txt \ ~/Documents

Для удалённого сервера:

$ scp tux@example.com::/my_backup_drive/Documents/example.txt \ ~/Documents

У команды rdiff-backup есть опции, которые позволяют настроить параметры копирования. Например, --restore-as-of даёт возможность указать, какую версию файла нужно восстановить.

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

$ rdiff-backup --restore-as-of 4D \ /run/media/tux/foo.txt ~/foo_4D.txt

Или, может быть, вам нужна последняя версия:

$ rdiff-backup --restore-as-of now \ /run/media/tux/foo.txt ~/foo_4D.txt

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



На правах рекламы


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

Подробнее..

Из песочницы Прямая интеграция IBM Integration Bus и Oracle AQ

22.09.2020 18:18:39 | Автор: admin
Здравствуйте!

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

В процессе работы над новым сервисом возникла необходимость создать адаптер к ИС реализующей интерфейс очередей сообщений Oracle Advanced Queuing.

Проведя некоторый research, выделил три варианта интеграции в порядке приоритета:

  1. Oracle Messaging Gateway, т.к.

    • Входит в лицензию Oracle EE. Благо в организации такая имеется
    • Реализация MOM (message-oriented middleware) с отличными от Oracle системами обмена сообщениями, в том числе IBM MQ
    • С IIB интегрируется c использованием нативных MQ-узлов (MQInput/MQOutput/MQGet)

  2. Oracle Internet Directory т.к.

    • Реализует JNDI, необходимый для интеграции по JMS
    • С IIB интегрируется c использованием нативных JMS-узлов (JMSInput/JMSOutput/JMSReceive)

  3. Кастомная реализация на Java т.к.

    • Есть Java API для Oracle AQ
    • С IIB интегрируется c использованием узла JavaCompute

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

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

Про то как настроить отправку запросов в очереди AQ нашел тут.

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

Собственно, для этого нужно:

  1. Положить на файловую систему необходимые библиотеки aqapi.jar, jta.jar, ojdbc8.jar
  2. Связать креденшлы к базе с JNDI-ресурсом командой:

    mqsisetdbparms BRK_NAME -n jndi::oracle.jms.AQjmsInitialContextFactory -u oracleUser -p oraclePassword
    

  3. Добавить JMS-провайдер, где в команде указать:

    • URL базы параметр jndiEnvironmentParms
    • путь к папке с библиотеками параметр jarsURL
    • наименование фабрики соединений параметр connectionFactoryName
    • начальный контекст параметр initialContextFactory
    • флаг поддержки транзакционности параметр jmsProviderXASupport

    mqsicreateconfigurableservice BRK_NAME -c JMSProviders -o Service_AQ_JMS -n jarsURL,jndiEnvironmentParms,jmsProviderXASupport,connectionFactoryName,initialContextFactory -v "/home/mqm/aq/lib","db_url=jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostName) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=serviceName)))","true","QueueConnectionFactory","oracle.jms.AQjmsInitialContextFactory"
    

  4. Далее использовать созданный конфигурационный сервис в JMS-узлах брокера. Пути к очередям или топикам указываются в нотации Queues/QUEUE_NAME, Topics/TOPIC_NAME. В случае использования destination list необходимо дописать jndi://, т.е. jndi://Queues/QUEUE_NAME.

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

Надеюсь кому-нибудь будет полезно, ведь данный метод вендором не описан.
Подробнее..

MinIo для самых маленьких

23.09.2020 10:08:04 | Автор: admin
MinIO прекрасное решение, когда надо легко и просто организовать объектное хранилище. Элементарная настройка, множество платформ и хорошая производительность сделали своё дело на ниве народной любви. Так что у нас не было другого пути, как месяц назад заявить о совместимости Veeam Backup & Replication и MinIO. Включая такую важную функцию, как Immutability. На самом деле у MinIO есть целый раздел в документации, посвящённый нашей интеграции.

Поэтому сегодня мы поговорим о том, как:

  • Настроить MinIO очень быстро.
  • Настроить MinIO чуть менее быстро, но значительно качественней.
  • Использовать его в качестве Archive Tier для масштабируемого репозитория Veeam SOBR.



Что ты такое?


Краткая вводная для тех, кто не сталкивался с MinIO. Это опенсорсное объектное хранилище, совместимое с Amazon S3 API. Выпускается под лицензией Apache v2 и придерживается философии спартанского минимализма.

То есть у него нет развесистого GUI с дашбордами, графиками и многочисленными меню. MinIO просто запускает свой сервер одной командой, на котором можно просто хранить данные, используя всю мощь S3 API. Но надо заметить, что простота эта может быть обманчива, когда речь заходит об используемых ресурсах. RAM и CPU поглощаются на отлично, но о причинах будет ниже. И, к слову сказать, такие комбайны, как FreeNAS и TrueNAS под капотом используют именно MinIO.

На этом введение можно и заканчивать.

Настройка MinIO очень быстро


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

Итак, в случае Windows идём на официальный сайт https://min.io/download#/windows и качаем последнюю версию. Там же наблюдаем инструкцию по запуску:

 minio.exe server F:\Data

И там же ссылка на чуть более развёрнутый Quick start guide. Инструкции не верить смысла нет, поэтому запускаем и получаем примерно такой ответ.


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

Для любителей линуксов всё остаётся не менее простым. Простейшая инструкция:

wget https://dl.min.io/server/minio/release/linux-amd64/miniochmod +x minio./minio server /data

Результат будет неотличим от виденного ранее.

Настройка MinIO чуть более осмысленная


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

HTTPS


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

  • Создаём сертификат
  • В случае Windows кладём его в C:\Users\%User%\.minio\certs
  • В случае Linux в ${HOME}/.minio/certs
  • Перезапускаем сервер

Банальный Lets Encrypt это скучно и описано везде, так что наш путь это путь самурая, поэтому в случае Windows скачиваем Cygwin, а в случае Linux просто проверяем, что у нас установлен openssl. И делаем немного консольной магии:

  • Создаём ключи: openssl ecparam -genkey -name prime256v1 | openssl ec -out private.key
  • Создаём сертификат по ключу: openssl req -new -x509 -days 3650 -key private.key -out public.crt
  • Копируем private.key и public.crt в папку, указанную выше
  • Перезапускаем MinIO

Если всё прошло как надо, то в статусе появятся примерно такие строчки.


Включаем MinIO Erasure Coding


Сперва пара слов о сабже. В двух словах: это программная защита данных от повреждения и потери. Как рейд, только намного надёжней. Если классический RAID6 может позволить себе потерять два диска, то MinIO спокойно переживает потерю половины.Более детально технология описана в официальном гайде. Но если взять самую суть, то это реализация кодов Рида-Соломона: вся информация хранится в виде блоков данных, к которым есть блоки чётности. И вроде это всё уже было сделано много раз, только есть важное но: мы можем явно указывать соотношение блоков чётности к блокам данных для хранимых объектов.
Хотите 1:1? Пожалуйста!
Хотите 5:2? Без проблем!

Очень важная функция, если вы используете сразу несколько нод и хотите найти свой собственный баланс между максимальной безопасностью данных и затраченных ресурсов. Из коробки MinIO использует формулу N/2 (где N общее количество дисков), т.е. делит ваши данные между N/2 дисками данных и N/2 дисками четности. Переводя на человеческий: можно потерять половину дисков и восстановить данные. Это соотношение задаётся через Storage Class, позволяя вам самостоятельно выбрать, что важнее: надёжность или ёмкость.

В гайде приведён такой пример: предположим, что у вас инсталляция на 16 дисков и вам надо сохранить файл размером 100 Мб. Если используются настройки по умолчанию (8 дисков под данные, 8 под блоки чётности), то файл в итоге займёт практически двойной объём т.е. 200 Мб. Если отношение дисков будет 10/6, то понадобится 160 Мб. 14/2 114 Мб.

Другое важное отличие от рейдов: в случае выпадения дисков MinIO будет работать на уровне объектов, восстанавливая один за другим, не останавливая работу всей системы. В то время как обычный рейд будет вынужден восстанавливать весь volume, что займёт непредсказуемое количество времени. На памяти автора дисковая полка, которая после выпадения двух дисков ушла на пересчёт на полторы недели. Было весьма неприятно.

Звучит всё это очень здорово, но насколько сложной будет настройка? Давайте посмотрим. Берём команду для запуска и просто перечисляем диски, на которых нужно создать хранилище. Если всё сделано верно, то в репорте увидим количество задействованных дисков. И совет, что негоже на один хост добавлять сразу половину дисков, ибо это к потере данных.

c:\minio>minio.exe server F:\ G:\ H:\ I:\ J:\ K:\


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

Чтобы не стирать пальцы, каждый раз набирая адрес и ключи доступа (да и небезопасно это), удобно при первом запуске сразу создать alias по формуле mc alias set <YOUR-MINIO-ENDPOINT> [YOUR-ACCESS-KEY] [YOUR-SECRET-KEY]

mc alias set veeamS3 https://172.17.32.52:9000 YOURS3ACCESSKEY YOURSECERTKE

Или же можно сразу добавить ваш хост:

mc config host add minio-veeam https://minio.jorgedelacruz.es YOURS3ACCESSKEY YOURSECERTKEY

А потом создадим immutable бакет красивой командой

mc mb --debug -l veeamS3/immutablemc: <DEBUG> PUT /immutable/ HTTP/1.1Host: 172.17.32.52:9000User-Agent: MinIO (windows; amd64) minio-go/v7.0.5 mc/2020-08-08T02:33:58ZContent-Length: 0Authorization: AWS4-HMAC-SHA256 Credential=minioadmin/20200819/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-bucket-object-lock-enabled;x-amz-content-sha256;x-amz-date, Signature=**REDACTED**X-Amz-Bucket-Object-Lock-Enabled: trueX-Amz-Content-Sha256: UNSIGNED-PAYLOADX-Amz-Date: 20200819T092241ZAccept-Encoding: gzipmc: <DEBUG> HTTP/1.1 200 OKContent-Length: 0Accept-Ranges: bytesContent-Security-Policy: block-all-mixed-contentDate: Wed, 19 Aug 2020 09:22:42 GMTLocation: /immutableServer: MinIO/RELEASE.2020-08-16T18-39-38ZVary: OriginX-Amz-Request-Id: 162CA0F9A3A3AEA0X-Xss-Protection: 1; mode=blockmc: <DEBUG> Response Time: 253.0017ms

--debug позволяет видеть не просто итоговое сообщение, а более развёрнутую информацию.

-l значит --with-lock, что значит immutable

Если теперь вернуться в веб интерфейс, то там появится наш новый бакет.


На данный момент это всё. Мы создали защищенное хранилище и готовы переходить к интеграции с Veeam.

Можно ещё удостовериться, что всё работает на отлично:

c:\minio>mc admin info veeamS3 172.17.32.52:9000Uptime: 32 minutesVersion: 2020-08-16T18:39:38ZNetwork: 1/1 OKDrives: 6/6 OK0 B Used, 1 Bucket, 0 Objects6 drives online, 0 drives offline

MinIO и Veeam


Внимание! Если по какой-то из невероятных причин вы хотите работать через HTTP, то по адресу HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\ создайте DWORD ключ SOBRArchiveS3DisableTLS. Выставите его значение в 1 и помните, что мы такое поведение решительно не одобряем и никому не советуем.

Внимание ещё раз! Если из-за какого-то недоразумения вы продолжаете использовать Windows 2008 R2, то при попытке подключить MinIO к Veeam вы скорее всего получите примерно такую ошибку: Failed to establish connection to Amazon S3 endpoint. Лечится это официальным патчем от Microsoft.

Ну что же, с приготовлениями закончено, давайте откроем интерфейс VBR и перейдём на вкладку Backup Infrastructure, где вызовем мастер добавления нового репозитория.


Само собой, интересует нас Object storage, а именно S3 Compatible. В открывшемся визарде задаём имя, проходим шаги с указанием адреса и учётной записи. Если требуется, то не забываем указать гейт, через который будут проксироваться запросы к хранилищу.


После чего выбираем бакет, папку и ставим галочку Make recent backups immutable. Или не ставим. Но раз уж мы сделали хранилище с поддержкой этой функции, то грех будет не воспользоваться.


Next > Finish и наслаждаемся результатом.

Теперь надо добавить его к SOBR репозиторию в качестве Capacity Tier. Для этого или создаём новый, или редактируем имеющийся. Нас интересует шаг Capacity Tier.


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

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


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

И напоследок, ответ на коварный вопрос: что же будет если всё же взять и попробовать удалить бекап из Immutable стораджа?

Вот ответ:



На этом на сегодня всё. По верной традиции, ловите список полезных топиков по теме:
Мануал Using MinIO with Veeam
Пример по использовани MinIO вместе с Veeam Backup for Office 365.
Общий мануал по настройке S3 стораджей в Veeam.
Ветка на нашем форуме про S3 хранилища.
Подробнее..

Построение сетевой инфраструктуры на базе Nebula. Часть 1 задачи и решения

24.09.2020 12:15:14 | Автор: admin


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


Для справки. Nebula облачная среда SaaS для удаленного поддержания сетевой инфраструктуры. Все устройства, поддерживающие Nebula, управляются из облака через безопасное соединение. Можно управлять крупной распределенной сетевой инфраструктурой из единого центра, не затратив усилия по его созданию.


Для чего нужен очередной облачный сервис?


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


Сеть новая заботы старые


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


Приходится придумывать различные схемы для выхода из вышеописанного тупика. Например, ноутбук с доступом в Интернет через USB 4G модем подключается через патчкорд к настраиваемой сети. На этом ноутбуке поднимается VPN клиент, и через него сетевой администратор из штаб-квартиры пытается получить доступ к сети филиала. Схема не самая прозрачная даже если привезти ноутбук с заранее настроенным VPN на удаленную площадку и попросить его включить, далеко не факт что всё заработает с первого раза. Особенно если речь о другом регионе с другим провайдером.


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


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


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


Примечание. Самые печальные проколы начинаются со слов: Да что там этот Zabbix (Nagios,OpenView и т.д.) настраивать? Я сейчас вот его быстренько подниму и готово!


От внедрения к эксплуатации


Рассмотрим конкретный пример.


Получено тревожное сообщение о том, что где-то не отвечает точка доступа WiFi.


Где она находится?


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


Допустим, нам повезло и точка доступа питается через PoE, а коммутатор позволяет её перезагрузить удаленно. Ехать не надо, но нужен удаленный доступ до коммутатора. Остается настроить проброс портов через PAT на маршрутизаторе, разобраться с VLAN для подключения извне и так далее. Хорошо, если все настроено заранее. Работа, может, и не сложная, но делать нужно.


Итак, точку по питанию перезагрузили. Не помогло?


Допустим, что-то не так в аппаратной части. Теперь ищем информацию о гарантии, начале эксплуатации и других интересующих деталях.


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


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


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


Как это выглядит при использовании Nebula?


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


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


Зарегистрировать используемые устройства в облаке можно двумя способами: по старинке просто вписав серийник при заполнении веб-формы или отсканировав QR-код при помощи мобильного телефона. Всё что нужно для второго способа смартфон с камерой и доступом в Интернет, в том числе через мобильного провайдера.


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



Рисунок 1. Отчет безопасности Nebula Control Center.


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


А как же RADUIS сервер? Ведь нужна какая-то централизованная аутентификация!


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


Отдельно стоит сказать о WPA2-Enterprise, для которого нужен отдельный сервис аутентификации. У Zyxel Nebula есть собственный аналог DPPSK, который позволяет использовать WPA2-PSK с индивидуальным ключом для каждого пользователя.


Неудобные вопросы


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


А это точно безопасно?


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


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


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


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


Насколько Nebula дороже или дешевле приходящего админа?


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


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


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


Если же говорить на тему выгодно или не выгодно приобретать платный пакет услуг (Pro-Pack), то примерный ответ может звучать так: если организация маленькая, можно обойтись базовой версией, если организация растет, то имеет смысл подумать о Pro-Pack. Различие между версиями Zyxel Nebula можно посмотреть в таблице 1.


Таблица 1. Различия наборов функций базовой версии и версии Pro-Pack для Nebula.



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


А что с защитой трафика?


Nebula использует протокол NETCONF для обеспечения безопасности работы с сетевым оборудованием.


NETCONF может работать поверх нескольких транспортных протоколов:



Если сравнивать NETCONF с другими методами, например, управление через SNMP следует отметить, что NETCONF поддерживает исходящее TCP-соединение для преодоления барьера NAT и считается более надежным.


Что с поддержкой оборудования?


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


  • центральные коммутаторы 10G;


  • коммутаторы уровня доступа;


  • коммутаторы с PoE;


  • точки доступа;


  • сетевые шлюзы.



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


Постоянное развитие


Сетевые устройства с традиционным методом управления имеют только один путь совершенствования изменение самого устройства, будь то новая прошивка или дополнительные модули. В случае с Zyxel Nebula есть дополнительный путь для улучшений через совершенствование облачной инфраструктуры. Например, после обновления Nebula Control Center (NCC) до версии 10.1. (21 сентября 2020) пользователям доступны новые возможности, вот некоторые из них:


  • владелец организации теперь может передать все права владения другому администратору в той же организации;


  • новая роль под названием Представитель владельца, которая имеет те же права, что и владелец организации;


  • новая функция обновления прошивки в масштабах всей организации (функция Pro-Pack);


  • в топологию добавлены две новые опции: перезагрузка устройства и включение и выключение питания порта PoE (функция Pro-Pack);


  • поддержка новых моделей точек доступа: WAC500, WAC500H, WAC5302D-Sv2 и NWA1123ACv3;


  • поддержка аутентификации по ваучерам с печатьюQR-кодов (функцияPro-Pack).



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


  1. Telegram chat Zyxel


  2. Форум по оборудованию Zyxel


  3. Много полезного видео на канале Youtube


  4. Zyxel Nebula простота управления как основа экономии


  5. Различие между версиями Zyxel Nebula


  6. Zyxel Nebula и рост компании


  7. Сверхновое облако Zyxel Nebula экономичный путь к безопасности?


  8. Zyxel Nebula Options for Your Business


Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru