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

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

Создание шаблона VDS с Zabbix 5 на CentOS 8

07.11.2020 14:06:38 | Автор: admin


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

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

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



Как мы создавали этот образ: требования к серверу


Для использования Zabbix 5 рекомендуется использовать 2 Гб RAM и 2 ядра CPU.

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

Веб-интерфейс Zabbix может использовать Apache или Nginx с PHP 7.2+, а в качестве базы данных MySQL, PostgreSQL, Oracle или SQLite.

Мы будем создавать образ с использованием Nginx и MySQL.

Подготовка образа


Обновим установленные пакеты до последней версии:

sudo dnf update -y

Добавим постоянное разрешение для входящего трафика на http/80, https/443, tcp/10051 (zabbix trapper) порты и перезагрузим правила файрвола:

sudo firewall-cmd --permanent --add-service=httpsudo firewall-cmd --permanent --add-service=httpsfirewall-cmd --permanent --add-port=10051/tcp

Применим новые правила файрвола:

sudo systemctl reload firewalld

Установим nginx:

dnf install nginx -y

Запустим и включим сервер Nginx:

sudo systemctl start nginxsudo systemctl enable nginx

Установим PHP, PHP-FPM, и требуемые модули PHP:

dnf install php-fpm php-cli php-mysqlnd php-json php-gd php-ldap php-odbc php-pdo php-opcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap php-zip -y

Установим MySQL Server:

dnf install mysql-server -y

Включим и запустим сервер MySQL:

systemctl start mysqldsystemctl enable mysqld

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

sudo sed -i '/Group=mysql/a \ExecStartPre=/bin/sleep 30' /usr/lib/systemd/system/mysqld.service

Изменим группу и пользователя из под которого будет работать nginx внеся изменения в /etc/php-fpm.d/www.conf:

sudo sed -i --follow-symlinks 's/user = apache/user = nginx/g' /etc/php-fpm.d/www.confsudo sed -i --follow-symlinks 's/group = apache/group = nginx/g' /etc/php-fpm.d/www.conf

Изменим владельца каталога сессий PHP так же соответственно на nginx:

sudo chown -R nginx. /var/lib/php/session

Удалим строки с коментариями из файла конфигурации /etc/nginx/nginx.conf (что бы не было двойных срабатываний для sed):

sudo sed -i -e '/^[ \t]*#/d'  /etc/nginx/nginx.conf

Добавим в /etc/nginx/nginx.conf настройки компрессии gzip

sudo sed -i '/types_hash_max_size 2048;/a \\    gzip on;\    gzip_static on;\    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/x-icon image/svg+xml application/x-font-ttf;\    gzip_comp_level 9;\    gzip_proxied any;\    gzip_min_length 1000;\    gzip_disable "msie6";\    gzip_vary on; \' /etc/nginx/nginx.conf

Добавим в /etc/nginx/nginx.conf настройки индексного файла index.php:

sudo sed -i '/        root         \/usr\/share\/nginx\/html;/a \        index index.php index.html index.htm;\' /etc/nginx/nginx.conf

Добавим настройки для дефолтного сервера обработку php через сокет php-fpm, отключим лог для статических файлов, увеличим время expire, отключим лог доступа и ошибок для favicon.ico и robots.txt и запретим доступ к файлам .ht для всех:

sudo sed -i '/        location \/ {/a \try_files $uri $uri/ /index.php?q=$uri&$args;\        }\    \        location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ {\        access_log off;\        expires max;\        }\    \        location ~ \.php$ {\        try_files  $uri =404;\        fastcgi_pass   unix:/run/php-fpm/www.sock;\        fastcgi_index index.php;\        include fastcgi_params;\        fastcgi_intercept_errors on;\        fastcgi_ignore_client_abort off;\        fastcgi_connect_timeout 60;\        fastcgi_send_timeout 180;\        fastcgi_read_timeout 180;\        fastcgi_buffer_size 128k;\        fastcgi_buffers 4 256k;\        fastcgi_busy_buffers_size 256k;\        fastcgi_temp_file_write_size 256k;\        }\    \        location = /favicon.ico {\        log_not_found off;\        access_log off;\        }\    \        location = /robots.txt {\        allow all;\        log_not_found off;\        access_log off;\        }\    \        location ~ /\.ht {\        deny all;' /etc/nginx/nginx.conf

Установим wget требуемый для установки certbot:

sudo dnf install wget -y

Скачаем исполняемый файл certbot с оффсайта:

cd ~wget https://dl.eff.org/certbot-auto

Переместим certbot в /usr/local/bin/:

mv certbot-auto /usr/local/bin/certbot-auto

И назначим права и владельцем root:

chown root /usr/local/bin/certbot-autochmod 0755 /usr/local/bin/certbot-auto

Установим зависимости certbot: (ответ Y в конвеер на вопрос установки зависимостей, и --install-only, что бы не инициировать установку сертификатов на данном этапе):

yes | certbot-auto --install-only

Установим репозиторий Zabbix, что бы дать пользователю возможность его без проблем обновлять:

dnf install https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm -y

Установим сервер, агент и утилиты Zabbix:

dnf install zabbix-server-mysql zabbix-web-mysql zabbix-agent zabbix-get -y

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

Создадим базу данных Zabbix (так же можно запустить клиент mysql и вводить команды заключенные в двойные кавычки в интерактивном режиме):

mysql -uroot -e "CREATE DATABASE zabbix DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin;"

Создадим пользователя mysql zabbix с пустым паролем:

mysql -uroot -e "CREATE USER 'zabbix'@'localhost' IDENTIFIED BY '';"

Предоставим все привелегии пользователю zabbix на базу zabbix

mysql -uroot -e "GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';"

Загрузим схему zabbix в базу данных:

zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix zabbix

Установим шаблон конфигурации Zabbix для Nginx:

dnf install zabbix-nginx-conf -y

Удалим подстроку из дефолтного конфига nginx, т.к. default_server будет определен в zabbix.conf:

sed -i --follow-symlinks 's/default_server//g' /etc/nginx/nginx.conf

Добавим строку default_server в конфигурацию сервера zabbix для Nginx:

sed -i '/#        server_name     example.com;/a \        listen          80 default_server;\        server_name     _;\' /etc/nginx/conf.d/zabbix.conf

Изменим пользователя PHP-FPM с apache на nginx для Zabbix:

sed -i --follow-symlinks 's/user = apache/user = nginx/g' /etc/php-fpm.d/zabbix.confsed -i --follow-symlinks 's/group = apache/group = nginx/g' /etc/php-fpm.d/zabbix.conf

Установим временную зону в php.ini (Zabbix проверяет наличие этой настройки при установке):

sed -i --follow-symlinks 's/;date.timezone =/date.timezone = Europe\/Moscow/g' /etc/php.ini


Назначим владельцем каталога /etc/zabbix nginx (для корректной записи конфигурации веб-сервером):

chown -R nginx. /etc/zabbix

Назначим группу каталога zabbix для /etc/zabbix/zabbix_* (Для чтения файлов конфигурации Zabbix сервером и агентом):

chown :zabbix /etc/zabbix/zabbix_*

Перезапустим и активируем сервисы Zabbix server и Zabbix agent:

systemctl restart zabbix-server zabbix-agent nginx php-fpmsystemctl enable zabbix-server zabbix-agent php-fpm

Далее создадим скрипт в домашнем каталоге root который по запросу пользователя сгенерирует и установит пароли для root и zabbix и скорректирует их в конфигурации сервера Zabbix и веб-интерфейса Zabbix. Воспользуемся перенаправлением heredoc с делимитером POSTINSTALL, что бы записать скрипт как есть, без раскрытия специальных символов:

cat <<"POSTINSTALL" > /usr/local/bin/secure_mysql#!/bin/bash# Сгенерируем пароль для пользователей MySQL root и zabbix, используя openssl с вырезанием символов =+/ и сохраним их в переменных:ZABBIXPASS="$(openssl rand -base64 29 | tr -d "=+/" | cut -c1-25)"ROOTPASS="$(openssl rand -base64 29 | tr -d "=+/" | cut -c1-25)"# Установим новые пароли пользователям:mysql -uroot -e "ALTER USER 'zabbix'@'localhost' IDENTIFIED BY '$ZABBIXPASS';"mysql -uroot -e "ALTER USER 'root'@'localhost' IDENTIFIED BY '$ROOTPASS';"# И выведем их в консольecho "New password for zabbix@localhost: $ZABBIXPASS"echo "New password for root@localhost: $ROOTPASS"# Запишем новый пароль zabbix в /etc/zabbix/zabbix_server.conf:sed -i --follow-symlinks "s/# DBPassword=/DBPassword=${ZABBIXPASS}/g" /etc/zabbix/zabbix_server.conf# Запишем новый пароль zabbix в /etc/zabbix/web/zabbix.conf.php:sed -i --follow-symlinks "s/\['PASSWORD'\]\s*=\s''/\['PASSWORD'\] = '${ZABBIXPASS}'/g" /etc/zabbix/web/zabbix.conf.php# Перезапустим затронутые сервисы:systemctl restart zabbix-server zabbix-agent nginx php-fpm# Обнулим переменныеZABBIXPASS=ROOTPASS=# Удалим файл, так как после того как пароли установлены, он более не нужен:rm -f /usr/local/bin/secure_mysqlPOSTINSTALL

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

chmod +x /usr/local/bin/secure_mysql

На данном этапе все настройки выполнены, остается выключить сервер и сделать снапшот:

shutdown -h now

После этого, развернув новый сервер из образа, мы, в роли пользователя, можем перейти по ссылке с адресом сервера, например: http://vps_ip_address/
На странице DB connection оставить настройки по умолчанию, так как на данном этапе у пользователя MySQL zabbix пустой пароль. На странице Zabbix server details, можно указать название экземпляра сервера в поле Name, или оставить пустым.
После этого войдем в панель управления с логином Admin и паролем zabbix (логин и пароль по умолчанию для новых установок сервера Zabbix), и в разделе Administration Users Admin установим новый пароль для учетной записи администратора сервера.
Что бы обезопасить себя от возможных инцидентов связанных с SQL-иньекциями, мы сгенерируем пароли для пользователей MySQL root и zabbix подключившись к серверу через ssh и выполнив скрипт:

secure_mysql

При выполнении скрипта, мы получим пароли в консоль в таком виде:

New password for zabbix@localhost: sdfiUB34xudgsRMiwKdd90spWNew password for root@localhost: Z1b0HjjyDJYQEtXqNWPaSySnH

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

Настройка HTTPS


Опционально можно настроить использование сертификатов Let's Encrypt с помощью ранее установленного certbot'a, для этого необходимо указать действующее доменное имя сервера в файле /etc/nginx/conf.d/zabbix.conf исправив параметр server, например:

server_name zabbix.mydomainname.ru;

Перезапустим веб-сервер:

service nginx restart

Запустим certbot:

/usr/local/bin/certbot-auto --nginx

Введем свой e-mail, cогласимся с условиями сервиса (A), Подписка на рассылку (опционально) (N), выберем доменные имена для которых нужно издать сертификат (Enter для всех).

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

Congratulations! You have successfully enabled ...

После этого подключения на 80 порт будут перенаправляться на 443 (https).
Добавим в /etc/crontab для автоматического обновления сертификатов:

# Cert Renewal30 2 * * * root /usr/local/bin/certbot-auto renew --post-hook "nginx -s reload"

Готово, теперь у нас есть готовый сервер Zabbix с настроенными сертификатами Let's Encrypt!

Для владельцев бизнеса: предложите свой софт


Если вы разработчик софта, который разворачивают и используют на VPS, то мы можем включить вас в маркетплейс. Так мы можем помочь вам привести новых клиентов, трафик и узнаваемость.

Просто предложить нам образ в комментариях


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

Чего вам не хватает в маркетплейсе RUVDS?

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



Подробнее..

Личная файлопомойка. Как я настраивал файлообменник на VPS

26.11.2020 12:17:06 | Автор: admin


Эпоха флешек давно канула в Лету. Что, впрочем, неудивительно: незаменимый инструмент для переноса файлов в кармане утратил свою актуальность с появлением облачных сервисов доступных везде, где есть интернет, причем практически с любого устройства. Однако в этой бочке меда не обошлось без маленькой ложки дегтя. Во-первых, бесплатные тарифы у большинства вендоров накладывают строгие ограничения на объем облачного хранилища и количество устройств, на которые можно установить приложение для синхронизации. Во-вторых, используя публичные облачные сервисы, вы доверяете свои файлы сторонней компании и никак не можете повлиять на их безопасность. В-третьих, подобные хранилища не слишком удобны для командной работы, которая весьма актуальна в период мировой короновирусной истерии пандемии. Выход? Можно смириться, а можно организовать сетевое файловое хранилище самостоятельно! Один из примеров решения этой задачи мы сейчас и рассмотрим.

Зачем, Холмс?


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

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

Безусловно, за $9.99 в месяц можно купить 2 терабайта в облаке у Dropbox, но там нет возможности многопользовательской работы. При нынешнем курсе доллара аренда виртуального сервера с дисковым объемом 40 Гб, но без ограничений на количество подключений, выйдет примерно в ту же сумму, а если выбрать конфигурацию попроще с одним ядром то даже дешевле. Определенная часть этого дискового пространства будет занята операционной системой, но для хранения файлов останется минимум 20 Гбайт, чего для моих целей вполне достаточно.

При этом файловое хранилище на VPS имеет целый ряд других неоспоримых преимуществ:
можно публиковать веб-сайты прямо из общей папки;
можно организовать доступ к нему с использованием SFTP;
можно настроить торрент-клиент для загрузки и выгрузки контента;
в том же контейнере можно смонтировать сервер NFS или SMB для использования VPN.

В общем, немного поразмыслив, я решил настроить File Storage на виртуальном сервере от этот провайдер использует в своей инфраструктуре преимущественно Windows Server, что намекает на относительную простоту организации удаленного хранилища (ха-ха!). Тем более, на моих устройствах (за исключением, разумеется, мобильных) установлена винда и macOS, поэтому серьезных проблем с подключением к удаленному серверу возникнуть уж точно не должно, подумал я (ха-ха два раза).

Матчасть


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

Для реализации своей задумки я выбрал виртуальный сервер в следующей конфигурации:
Windows Server 2019
2 ядра (Intel Xeon);
2 Гб RAM;
40Гб HDD.



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

Настройка сервера


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



В окне Мастера добавления ролей и компонентов нажимаем Далее, затем, выбрав вариант Установка ролей и компонентов, снова жмем Далее. Выбираем в списке наш сервер (собственно, он и будет там представлен в единственном экземпляре), и очередным нажатием на кнопку Далее переходим к настройке ролей.



Нас интересует раздел Файловые службы и службы хранилища. Эта роль установлена на сервере по умолчанию. Установите флажок Файловые службы и службы SCSI и разверните расположенный под ним список. Здесь следует дополнительно установить следующие флажки:
Файловый сервер;
Рабочие папки;
Диспетчер ресурсов файлового сервера (в открывшемся окне нажмите Добавить компоненты).

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

Создание нового раздела


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



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



Я решил эту проблему, создав отдельный логический том, отличный от того, на котором установлена Windows там мы сможем развлекаться, как нашей душе угодно. Для этого:
В окне Диспетчера серверов откройте расположенное в верхней части меню Средстива, а в нем Управление компьютером.
В открывшемся окне выберите в левой панели оснастку Управление дисками. Вы увидите единственный диск, на котором расположена операционная система.
Щелкните на диске правой клавишей мыши и выберите Сжать том. При общем объеме диска в 40 Гбайт в поле Размер сжимаемого пространства, Мб я прописал значение 25 000, посчитав, что для работы винде хватит 15 Гбайт дискового пространства.
Щелкните мышью на кнопке Сжать, и дожидитесь, пока Windows освободит место на диске.



После того как в Диспетчере дисков появится неразмеченное свободное пространство, необходимо проделать следующие шаги:
Щелкните правой клавишей мыши в нераспределенной области, и в контекстном меню выберите пункт Создать простой том;
В окне Мастера создания простого тома нажмите Далее, убедитесь, что размер тома соответствует объему неразмеченной области, снова нажмите Далее.
Введите букву диска (по умолчанию D:) и опять нажмите Далее.
Выберите в качестве файловой системы NTFS, размер кластера по умолчанию, установите флажок Быстрое форматирование. Остальные параметры можно оставить без изменений. Нажмите Далее. Затем щелкните мышью на кнопке Готово.



Если теперь мы откроем Проводник, то увидим, что в системе появился новый диск D:.

Создаем шару


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



Откроется одноименное окно, в котором демонстрируются следующие оснастки:
Серверы содержит список серверов (в нашем случае один) и журнал событий;
Тома данные о логических томах, общих ресурсах, сведения о диске;
Диски данные о зарегистрированных в системе дисковых накопителях;
Пулы носителей список доступных пулов хранения, по умолчанию пустой;
Общие ресурсы сведения обо всех настроенных на сервере общих ресурсах (шарах);
iSCSI сведения о виртуальных дисках iSCSI;
Рабочие папки данные о настроенных на сервере синхронизируемых Рабочих папках

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



Запустится Мастер создания общих ресурсов. В первую очередь нужно выбрать из списка подходящий профиль общей папки. Нам подойдет вариант Общий ресурс SMB быстрый профиль, поскольку он позволяет предоставлять доступ к файлам на компьютерах с Windows и не требует настройки дополнительных параметров.



Нажимаем Далее. В следующем окне нам предложат выбрать папку для создания общего ресурса. Устанавливаем переключатель в позицию Ввести пользовательский путь, жмем Обзор и выбираем созданную нами ранее папку Share. Снова жмем Далее.



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



По нажатию Далее система продемонстрирует стандартный для Windows Server список разрешений на доступ к папке, согласно которому полные права на чтение и запись имеет только пользователь с правами Администратора. Нажмите в окне Мастера на кнопку Настройка разрешений, затем Добавить -> Выберите субъект, в нижнем поле введите Все (без кавычек), нажмите Ок и установите флажок Полный доступ. Нажмите Применить, затем Ок.

Осталось только нажать в окне Мастера создания общих ресурсов кнопку Далее и Создать. Выбранная нами папка появится в панели общие ресурсы.



Траблшутинг


Теперь, казалось бы, мы можем обращаться к этой папке прямо из Проводника. Для этого набираем в адресной строке \\ip-адрес-нашего-сервера, вводим имя и пароль Администратора, и видим нашу расшаренную папку с тем именем, которое мы задали ей на этапе настройки. Можно пользоваться шарой? Хренушки. Отказано в доступе. Винда не была бы виндой, если бы все было так просто. Самый простой способ избавиться от этой ошибки такой.

Вновь подключаемся к серверу по RDP, щелкаем правой кнопкой мыши на значке подключения к сети в трее и выбираем в контекстном меню Открыть Параметры сети и интернет.
В открывшемся окне проматываем содержимое вниз и жмем на надпись Центр управления сетями и общим доступом.
В расположенной слева панели жмем на надпись Изменить дополнительные параметры общего доступа.
Устанавливаем переключатель в положение Включить сетевое обнаружение.
Переходим в раздел Все сети чуть ниже, устанавливаем переключатель в положение Включить общий доступ, чтобы сетевые пользователи могли читать и записывать файлы в общих папках.
Жмем Сохранить изменения.



Если сетевое обнаружение никак не хочет включаться, делаем следующее: в панели поиска набираем без кавычек Службы или services.msc, и принудительно запускаем следующие службы (если они еще не запущены):
DNS-клиент (DNS Client)
Обнаружение SSDP (SSDP Discovery)
Публикация ресурсов обнаружения функции (Function Discovery Resource Publication)
Узел универсальных PNP-устройств (UPnP Device Host)

Для каждой из этих служб настоятельно рекомендую включить автоматический запуск. Все? Теперь-то мы можем использовать общую папку? Нет!

Запускаем на сервере Проводник, находим в нем нашу расшаренную папку. Щелкаем на ней правой клавишей мыши, в контекстном меню выбираем пункт Свойства и открываем вкладку Безопасность. Выбираем щелчком мыши пользователя Все и нажимаем на кнопку Изменить. Устанавливаем флажок Полный доступ, жмем Применить и Ок.



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



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



На этом этапе кое-кто отчаивается и идет покупать платный аккаунт в Dropbox за $9.99. Но мы сильны духом, любим секс, а потому продолжаем эксперименты. Вновь открываем Удаленный рабочий стол на сервере, вводим в поисковую строку слово Администрирование (без кавычек) и нажимаем Enter. В окне Администрирование выбираем Локальная политика безопасности -> Локальные политики -> Назначение прав пользователя -> Отказать в доступе этому компьютеру из сети Гость. Дважды щелкаем на этой строке мышью и удаляем Гостя из списка.



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

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



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

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

Квотирование и Рабочие папки


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



Подробнее..

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

02.11.2020 10:17:21 | Автор: admin
А не пришло ли время разобраться и навести наконец-то порядок с безопасностью в мониторинге? Тем более, в одной из популярных систем мониторинга и встроенная возможность такая имеется.



На схеме видно, что зашифровать можно почти все потоки внутри Zabbix. В этой статье мы расскажем и покажем как это сделать, а еще расскажем о новой интеграции Zabbix с хранилищем секретов Hashicorp Vault. Там можно хранить любую чувствительную информацию от логина/пароля в БД до значений макросов. Это позволит централизованно управлять авторизационными данными, вести аудит и не хранить их на файловой системе или в БД Zabbix. Такой функционал появился в последней (на момент публикации статьи) версии Zabbix 5.2.

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

Велкам ту подкат.

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

  • Пользователь (web-браузер) <-> Zabbix web-сервер. Управление конфигурацией Zabbix, представление метрик. Шифрование настраивается средствами web-сервера.
  • Zabbix web-сервер <-> Zabbix-сервер. Web-сервер проверяет запущен ли Zabbix-сервер, запрашивает текущее состояние очереди, выполняет тест элементов данных и некоторые другие операции. Единственный поток, который в соответствии с архитектурой Zabbix нельзя зашифровать. Мы даже пытаться не будем.
  • Zabbix web-сервер <-> База данных Zabbix. Web-сервер обновляет конфигурацию в БД, извлекает данные для визуализации, удаляет исторические данные (по нажатию на Очистить историю) и запускает задания Выполнить сейчас (Execute now). Можно настроить при установке или позже в файле конфигурации zabbix.conf.php. Поддерживается TLS-шифрование при помощи ключей. Для хранения логина и пароля для БД можно использовать Vault. Важный факт: сертификаты, защищённые паролем не поддерживаются.
  • Zabbix-сервер <-> База данных Zabbix. Zabbix-сервер через configuration syncer загружает в свой кэш конфигурацию, через history syncer записывает собранные данные в БД, очищает историю (housekeeping) и выполняет некоторые другие операции. Настройки шифрования выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_server.conf.
  • Zabbix-сервер <-> Zabbix-агент. Поддерживаются общий ключ PSK и сертификаты. Взаимодействие этих компонентов делится на две части: к узлу сети (TLSAccept для пассивных проверок) и от узла сети (TLSConnect для активных проверок).
  • Zabbix-сервер <-> Zabbix-прокси. Поддерживаются общий ключ PSK и сертификаты. Настройки выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_proxy.conf.
  • Zabbix-прокси <-> Zabbix-агент. Поддерживаются общий ключ PSK и сертификаты. Взаимодействие этих компонентов делится на две части: к узлу сети (TLSAccept для пассивных проверок) и от узла сети (TLSConnect для активных проверок).
  • Zabbix-прокси <-> БД Zabbix-прокси. Настройки выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_proxy.conf.
  • Zabbix sender -> Zabbix-прокси. Поддерживаются общий ключ PSK и сертификаты в качестве параметров при вызове через командную строку.
  • Zabbix-агент -> Zabbix get. Поддерживаются общий ключ PSK и сертификаты в качестве параметров при вызове через командную строку.


Пользователь (web-браузер) <-> Zabbix web-сервер


Шифрование этой коммуникации не поддерживается со стороны Zabbix, нужно самостоятельно выполнить настройку на стороне Apache или Nginx. В этой статье мы рассмотрим настройку Nginx с самоподписанным SSL-сертификатом, т.к. преимущественно используем именно Nginx в своих проектах по мониторингу на базе Zabbix. Можно использовать сертификат доверенного центра сертификации, например, бесплатный от Let's Encrypt. Это позволит избежать страшных предупреждений в браузере. Обращаем внимание, что использование самоподписанного сертификата никак не умаляет надежности шифрованного соединения, оно будет таким же защищённым как и при использовании сертификата от доверенного CA.

Листинг настройки
# mkdir -p /etc/ssl/private/
# chmod 0750 /etc/ssl/private
# openssl req \
> -newkey rsa:2048 -nodes -keyout /etc/ssl/private/zabbix.key \
> -x509 -days 365 -out /etc/ssl/certs/zabbix.crt \
> -subj "/C=RU/ST=Russia/L=Moscow/O=Gals/OU=Gals_Dev/CN=gals.software/emailAddress=welcome@gals.software"
# chmod 0400 /etc/ssl/certs/zabbix.crt
# chmod 0400 /etc/ssl/private/zabbix.key
# mv /etc/nginx/conf.d/zabbix.conf /etc/nginx/conf.d/zabbix-ssl.conf
# vi /etc/nginx/conf.d/zbx-ssl.conf
listen 443 ssl default_server;
ssl on;
ssl_certificate /etc/ssl/certs/zabbix.crt;
ssl_certificate_key /etc/ssl/private/zabbix.key;
# vi /etc/nginx/conf.d/zabbix.conf
server {
listen 80;
return 301 https://$host$request_uri;
}
# systemctl restart nginx




В браузере появится замочек и можно посмотреть детали сертификата. Соединение зашифровано.


Zabbix web-сервер <-> База данных Zabbix


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

Листинг создания пользователей для Zabbix web-сервера и Zabbix-сервера
mysql> CREATE USER    'zabbix_srv'@'%' IDENTIFIED WITH mysql_native_password BY '<strong_password>',    'zabbix_web'@'%' IDENTIFIED WITH mysql_native_password BY '<strong_password>' REQUIRE SSL    PASSWORD HISTORY 5; mysql> CREATE ROLE 'zabbix_srv_role', 'zabbix_web_role'; mysql> GRANT SELECT, UPDATE, DELETE, INSERT, CREATE, DROP, ALTER, INDEX, REFERENCES ON zabbix.* TO 'zabbix_srv_role'; mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON zabbix.* TO 'zabbix_web_role'; mysql> GRANT 'zabbix_srv_role' TO 'zabbix_srv'@'%'; mysql> GRANT 'zabbix_web_role' TO 'zabbix_web'@'%'; mysql> SET DEFAULT ROLE 'zabbix_srv_role' TO 'zabbix_srv'@'%'; mysql> SET DEFAULT ROLE 'zabbix_web_role' TO 'zabbix_web'@'%';


Вызов статуса вернет, в том числе, данные по настройкам шифрования. Убедимся, что в строке SSL указаны алгоритмы шифрования.



Настройку шифрования между Zabbix и базой данных можно выполнить сразу при первичной настройке Zabbix через web-интерфейс. Обратите внимание на подпись напротив Database TLS encryption. Из-за того, что для подключения к локальной БД используется socket file, нет возможности настроить шифрованное подключение. Поэтому в поле Хост базы данных должны быть указаны IP-адрес или имя сервера с БД.



Меняем localhost на IP-адрес сервера и появляется чекбокс.



На двух скриншотах выше можно увидеть нововведение в Zabbix версии 5.2 поддержку интеграции с хранилищем Vault. Перед началом настройки Zabbix мы создали пару ключей и учетными данными для подключения к БД.



Берем клиентские ключи MySQL, заполняем необходимые поля и нажимаем Далее.



Другой способ настроить то же самое соответствующие ключи в конфигурационном файле zabbix.conf.php.

$DB['ENCRYPTION'] = true;
$DB['KEY_FILE'] = '/etc/ssl/mysql/client-key.pem';
$DB['CERT_FILE'] = '/etc/ssl/mysql/client-cert.pem';
$DB['CA_FILE'] = '/etc/ssl/mysql/ca.pem';
$DB['VERIFY_HOST'] = true;
$DB['CIPHER_LIST'] = '';


Zabbix-сервер <-> База данных Zabbix


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

DBTLSConnect=required
DBTLSCAFile=/etc/ssl/mysql/ca.pem
DBTLSCertFile=/etc/ssl/mysql/client-key.pem
DBTLSKeyFile=/etc/ssl/mysql/client-cert.pem
DBTLSCipher=''


После выполненных настроек, необходима перезагрузка службы Zabbix-сервера. Логин и пароль для подключения Zabbix-сервера к БД мы также храним в Vault.



Использование Vault требует добавления значений к следующим переменным в конфигурации Zabbix-сервера:

VaultDBPath=kv/secret/zabbix
VaultToken=s.Ev50RnGXNM3FmmcVBMRrR4Nz
VaultURL=http://192.168.56.101:8200


Переменная VaultDBPath отвечает за хранение учетных данных для подключения к БД. Подробнее о шифровании подключений к БД можно узнать в документации Zabbix.

Zabbix-сервер <-> Zabbix-прокси


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



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

На стороне прокси все настройки выполняются в конфигурационном файле. Для активных проверок:

TLSConnect=psk
TLSPSKIdentity=test_zabbix
TLSPSKFile=/var/zabbix/agentd.psk


Для пассивных проверок:

TLSAccept=psk
TLSPSKIdentity=test_zabbix
TLSPSKFile=/var/zabbix/agentd.psk


Второй способ шифрования подключения использование сертификатов. Заметим, что для pre-shared key (PSK) и сертификатов, закрытый ключ хранится на файловой системе в открытом виде.
Подробная информация доступна в документации Zabbix.

Zabbix-сервер <-> Zabbix-агент и Zabbix-прокси <-> Zabbix-агент


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



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

Zabbix-прокси <-> БД Zabbix-прокси


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

Zabbix sender -> Zabbix-прокси и Zabbix-агент -> Zabbix get


Шифрование соединения с утилитами Zabbix sender и Zabbix get выполняется при помощи специальных параметров при вызове соответствующих утилит.

zabbix_sender -z 127.0.0.1 -s zabbix02 -k Encrypt -o 18 --tls-connect psk --tls-psk-identity test_zabbix --tls-psk-file /etc/zabbix/keys/agent.psk

zabbix_get -s 127.0.0.1 -k agent.version \
--tls-connect psk --tls-psk-identity test_zabbix --tls-psk-file /etc/zabbix/keys/agent.psk


Авторегистрация с шифрованием


Шифрование также поддерживается и для процесса авторегистрации.



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

Хранение чувствительной информации в Vault


Приятное нововведение, которое появилось в версии Zabbix 5.2 поддержка хранилища Vault. Его можно использовать как для хранения учетных данных для доступа к БД так и для значений макросов. Так значения макросов выглядят в Vault:



А так на них можно сослаться в интерфейсе Zabbix:



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

Заключение


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

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

А ещё можно почитать:

Добавляем CMDB и географическую карту к Zabbix

Мониторинг принтеров дело благородное

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

Elastic под замком: включаем опции безопасности кластера Elasticsearch для доступа изнутри и снаружи

Для обработки событий от Zabbix, Prometheus, Elastic и других систем рекомендуем использовать Amixr (презентация по запросу).
Подробнее..

CrowdSec современная альтернатива Fail2Ban и коллективный иммунитет для Интернета

16.11.2020 12:07:26 | Автор: admin

CrowdSec

Инструмент Fail2Ban хорошо известен админам. Программа анализирует логи на сервере и подсчитывает количество попыток доступа с конкретных IP-адресов по указанным протоколам. В случае нарушения правила данный IP-адрес блокируется на заданный отрезок времени. Например, джейл для авторизации по SSH включён с дефолтными настройками 5 попыток авторизации за 10 минут, после чего происходит бан IP-адреса на 10 минут. Отличный способ отфильтровать мусорный трафик от разных сканеров и защита от DDoS.

Fail2Ban и SSHGuard лучшие инструменты в своей области. Однако новый опенсорсный проект CrowdSec представляется интересной альтернативой. Это локальная замена Fail2Ban, а потенциально нечто большее глобальная база репутации IP-адресов типа иммунной системы интернета.

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



Разработчики CrowdSec называют следующие ключевые особенности:

  • обнаружение атак и реагирование на всех уровнях (логи могут лежать в любом месте);
  • простота в установке и обслуживании (установка с визардом в консоли);

    git clone https://github.com/crowdsecurity/crowdsec/releases/latest
    

    sudo ./wizard.sh -i
    


    Установка CrowdSec. Визард в консоли помогает выбрать и предлагает, какие демоны/логи нужно мониторить, хотя возможна и последующая настройка через обычные конфиги
  • интеграция с другими компонентами (чтение логов и автоматическая блокировка нарушителей на уровне CDN);
  • общий доступ (опционально): метаданные можно отправлять в центральный API, так что данные о вредоносных IP-адресах получат все пользователи. Нужно подчеркнуть, что это опциональная фича, и никто не заставляет передавать метаданные в общий доступ;
  • лёгкий вес: автономная работа, минимум оперативной памяти и CPU;
  • возможность обработки холодных логов (из архива) для своеобразной симуляции;
  • предустановленные панели мониторинга.

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

Ещё один интересный момент инструмент написан на языке программирования Go.

С архитектурной точки зрения система состоит из трёх основных компонентов:

  • постоянно работающая служба CrowdSec, которая отслеживает логи, атаки и т. д.;
  • инструмент командной строки, интерфейс для взаимодействия со службой;
  • модули интеграции (bouncers) с другими инструментами типа Cloudflare для реального обеспечения блокировки.

Вот как выглядит архитектура программы из документации:



На данный момент разработано пять модулей интеграции (bouncers):
cs-cloudflare-blocker, cs-custom-blocker (пользовательские сценарии), cs-netfilter-blocker, cs-nginx-blocker и cs-wordpress-blocker. Например, модуль для Nginx сверяет каждый неизвестный IP-адрес с базой данных, прежде чем веб-сервер ответит на запрос или выдаст ошибку 403. Модуль Netfilter просто добавляет вредоносные IP-адреса в чёрный список nftables/ipset.

Для простоты настройки на сайте собраны коллекции и конфигурации.

Коллекции это, по сути, просто наборы парсеров и сценариев для разных ситуаций. Например, в коллекцию Nginx входит парсер логов nginx-logs и базовые http-сценарии для определения типичных вредоносных ботов (агрессивный краулинг, сканирование/пробирование портов, чёрный список user-agent'ов, а также определение попыток проведения атаки path traversal).

Полный список коллекций:


Один из вариантов работы с CrowdSec через консольную программу cscli:

cscli metrics

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

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

cscli ban list



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

Но кроме cscli, конфигурацию можно изменить и традиционным способом, путём редактирования текстового файла в формате YAML:

vi /etc/crowdsec/config/profiles.yaml

Естественно, кастомные сценарии тоже поддерживаются.

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

Сейчас компания пытается предложить пользователям платный доступ к облачному API и базе данных с репутацией IP-адресов, которая составляется совместными усилиями. При этом поставщики информации в эту базу освобождаются от оплаты, а платят только чистые потребители, которые не хотят делиться информацией из своих логов. Планируется два тарифных плана: premium и enterprise с услугами по поддержке, специальными служебными инструментами (типа развёртывания системы на несколько локаций из одного центрального места), применением дата-майнинга и машинного обучения (обнаружение тенденций в глобальных данных), более продвинутом анализе холодных логов (форензика, криминалистика, расследования хотя данное направление бизнеса в Европе затруднено из-за закона GDPR).

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



Разработчики обращают внимание, что программа пока в бета-версии, но никаких проблем на продакшне ни у кого не возникало. Они также говорят, что программа на Go элементарно портируется на другие платформы вроде Windows и Mac.

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



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


Виртуальные серверы с защитой от DDoS-атак и новейшим железом, серверы размещены в одном из лучших российских дата-центров DataPro. Всё это про наши эпичные серверы. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe! Поспешите заказать.

Подробнее..

Dell Technologies Forum 2020 приглашаем на большую онлайн-конференцию о цифровой трансформации и новейших IT-решениях

25.11.2020 14:11:26 | Автор: admin
Dell Technologies постоянно проводит много самых разных мероприятий в мире и в России, но одно из них особенно важно для нас. Это ежегодная конференция Dell Technologies Forum, к которой мы всегда долго и тщательно готовимся, начиная этот процесс едва ли на за полгода до даты проведения. Обычно DTF проходит в оффлайне, но в 2020 году по понятным причинам формат изменён на онлайн. И в этом есть свои плюсы: не нужно никуда ехать, выступающих видно и слышно гораздо лучше, а ещё мы смогли пригласить несколько особенно классных гостей как зарубежных, так и российских!

Для тех, кто с DTF уже знаком, мы просто оставим ссылку на регистрацию (участие бесплатное) здесь. И с радостью будем ждать вас 2 декабря в 10:00 по московскому времени. А тем, кто пока с главной конференцией года Dell Technologies не знаком, под катом подробно расскажем, что же именно там будет происходить. Мы уверены, что практически каждый обязательно сможет найти в программе что-то интересное и полезное для себя.



Итак, Dell Technologies Forum 2020 это мероприятие большое. Мы начнём 2 декабря ровно в 10:00 по Москве, а в 15:00 планируем завершить все выступления. Если у вас найдутся свободные 5 часов замечательно, но если вдруг нет, то в программе вы сможете заранее выбрать наиболее интересные и подключиться к трансляции именно во время них.

Сразу после приветствия от Майкла Делла, который в представлении явно не нуждается, и Бориса Щербакова, вице-президента и генерального директора Dell Technologies в России, одновременно стартуют пять тематических потоков. Точное время каждого из них уже определено, так что можно гибко планировать своё время заранее.

Перед этим всех ждёт интересный бонус развёрнутое выступление Джона Роуза, президента и технического директора Dell Technologies. Джон расскажет о том, как изменились подходы к организации удалённых рабочих мест сотрудников в 2020 году, поделится интересной аналитикой по теме и даст ряд полезных советов о том, как сделать удалёнку эффективной и удобной для всех: как для сотрудников, так для организации и IT-службы.



Серверы и сети


Здесь у нас запланировано больше всего сессий сразу девять.

1. IT без границ: Кинетическая инфраструктура

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

2. Автоматизация сетевой фабрики ЦОД

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

3. От пилота к продуктиву. Практика применения искусственного интеллекта

Сегодня ни один эффективный бизнес не обходится без применения решений с использованием технологий ИИ. Но построение эффективных и производительных решений очень непростая задача. Своим опытом в рамках этой сессии поделится Артём Булкин, ведущий инженер департамента серверных и сетевых решений Dell Technologies в России.

4. Граничные вычисления и интернет вещей на службе современных организаций

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

5. Модернизация глобальной сети предприятия с решением SD-WAN

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

6. Intrinsic Security: Почему ИТ-администраторы должны помогать в защите от кибератак

В ближайшие 3-5 лет обеспечение безопасности на самых разных уровнях станет еще более масштабной совместной задачей для IT-департаментов. Кибератаки станут изощрённее, при этом организации сталкиваются с нехваткой квалифицированных специалистов по безопасности уже сейчас, а в будущем проблема станет ещё острее. Очень важно заранее подготовиться к этому. Как именно это сделать расскажет Дмитрий Жечков, менеджер по развитию бизнеса сетевой виртуализации и безопасности VMware в РФ и СНГ.

7. Intel: формирование будущего технологий

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

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

Искусственный интеллект, периферийные среды, 5G, облако, управление данными, безопасность и дополненная/расширенная реальность новые технологии, трансформирующие наш мир и образ жизни. Они вносят радикальные перемены в отрасли и изменяют ландшафты всех IT-отделов и компаний. В рамках этого выступления мы расскажем о том, как эти технологии связаны между собой, и о том, почему важно их объединять для достижения наибольшей эффективности.

9. Подготовка к современному управлению данными для внедрения связанных с данными инноваций

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



Цифровое рабочее место и удалённая работа


1. Современные технологии организации цифрового рабочего пространства

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

2. Современное мобильное рабочее место

Каким должно быть современное рабочее место? О подходах к выбору техники, которая позволит максимально эффективно решать самые разные рабочие задачи, расскажет Артур Антонов, технический эксперт Dell Technologies с 12-летним опытом работы в IT.

3. Мониторы и периферийные устройства

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

4. Устройства для требовательных приложений

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

5. Практическое руководство по современному управлению удаленными ПК с Windows 10

Подробно поговорим о том, как решение Dell Technologies Unified Workspace на базе VMware Workspace ONE помогает упростить развертывание устройств для удаленных пользователей, работающих из дома, и обеспечивает управление и безопасность этих ПК в режиме реального времени из облака.

6. Услуги для повышения эффективности удаленной работы персонала и ускорения бесперебойной работы основных бизнес-систем

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

7. Инновации вне офиса: как ускорить реализацию стратегии по обеспечению гибкости персонала с помощью Dell Technologies

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

8. IT-отдел Dell: трансформация технологий для предоставления сотрудникам возможности работать в любой точке и в любое время

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



Хранение и защита данных


1. Обзор СХД от Dell EMC

На эту сессию мы советуем обратить особое внимание. Во время неё руководитель технического департамента Dell Technologies в России и руководитель группы системных инженеров Дмитрий Агеев подробно расскажут обо всех возможностях наших новейших решений для хранения данных PowerStore, PowerFlex и PowerMax.

2. PowerMax хранилище без компромиссов

Ещё более глубокое погружение в нюансы и особенности системы Dell EMC PowerMax, идеально подходящей для современной аналитики, массивной консолидации, облачной инфраструктуры и новых подходов к разработке. Спикер Дмитрий Шишин, старший системный инженер Dell Technologies.

3. Супер-скейлер. Как Dell EMC PowerFlex меняет подход к хранению и работе с данными

Детальный разбор особенностей Dell EMC PowerFlex, который проведёт старший системный инженер Dell Technologies Александр Маландин.

4. PowerStore. Новый уровень автоматизации и адаптивная интеграция с VMware

Системы хранения Dell EMC PowerStore это идеальный баланс производительности, эффективности и масштабируемости. Это одна из наших самых новых СХД, и подробно её особенности и реализованные в ней инновации разберёт Алексей Шатный, старший системный инженер Dell Technologies.

5. PowerScale. Хранение неструктурированных данных

Dell EMC PowerScale горизонтально масштабируемая платформа NAS, созданная на основе программно-определяемого подхода. Как с её помощью устранить проблемы управления неструктурированными данными и обеспечить простоту использования системы в любых масштабах, покажет Григорий Могилёв, системный инженер Dell Technologies.

6. Технологии и подходы Dell Technologies для резервного копирования

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

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

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



Решения для виртуальных и облачных сред


1. Dell Technologies Cloud путь к гибридному облаку

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

2. Готовые решения для VDI

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

3. Гиперконвергентные системы

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

4. PowerProtect резервное копирование для виртуальных и облачных сред

Платформа Dell Technologies PowerProtect предоставляет уникальные возможности для управления защитой данных различных типов. На этой сессии мы познакомим вас с её возможностями для защиты данных в физических, виртуальных и облачных инфраструктурах.

5. ECS внутри объектной СХД

Как устроена объектная СХД? Для решения каких задач её лучше всего применять? Что уникального она может предложить? На эти и многие другие вопросы о Dell EMC ECS ответит Михаил Владимиров, старший технический консультант Dell Technologies с почти 20-летним опытом работы в IT и огромной экспертизой в области файловых и объектных систем, аналитики больших данных и высокопроизводительных вычислений.

6. Гибридные системы хранения данных Dell EMC

Во время этого выступления мы сконцентрируемся на особенностях и СХД Dell Technologies, сочетающих в себе возможности SSD- и SAS- накопителей Dell EMC SC, PowerVault и Unity XT.



Виртуальные демонстрации


В этом тематическом блоке мы сфокусируемся на демонстрации особенностей и преимуществ наиболее актуальных на сегодняшний день продуктов и решений Dell Technologies. Прежде всего, конечно же, это наша новейшая СХД PowerStore, а также гиперконвергентная система VxRail. Также мы покажем как оптимизировать процессы управления в ЦОД с помощью OpenManage Integration for VMware vCenter и продемонстрируем работу сетевых сервисов SmartFabric. Далее расскажем о нашем фирменном решении Cyber Recovery, которое предназначено для построения надёжной линии защиты данных от программ-вымогателей и других кибератак. Ну и обязательно подробно поговорим о подходах Dell Technologies к VDI, продемонстрируем как они работают на практике, и объясним, в чём их ключевые достоинства.

Дополнят Dell Technologies Forum 2020 специальные выступления очень интересных гостей это отдельная и очень интересная часть программы.



Алексей Немов, вице-президент Федерации спортивной гимнастики России и четырёхкратный олимпийский чемпион, поделится секретами достижения успеха и мотивации команды. Всё это актуально не только в спорте, но и в IT, особенно в непростом 2020 году.



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



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

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

Спасибо за внимание и до встречи на DTF 2020 2 декабря в 10:00 по московскому времени!
Подробнее..

Перевод Для продолжения введите точное число машин

09.11.2020 14:21:24 | Автор: admin
За карьеру мне приходилось сисадминить в нескольких больших компаниях. Речь о миллионе Linux-серверов и больше. Когда под вашей опекой столько котиков, иногда нужно произвести действия с большой группой. Время от времени со всеми сразу.

По моему опыту, компании с таким огромным серверным флотом стремятся создавать инструменты для массового управления. У этих инструментов разные названия, но суть примерно одинаковая: заходишь по ssh как рут, запускаешь команду и, возможно, получаешь какой-то код выхода и/или результат.

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

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

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

Когда у вас появится такой инструмент, сами увидите подобные ошибки.

Моя просьба достаточно простая: если в качестве проверки здравомыслия собираетесь запросить подтверждение, *не* используйте тип Y/N. Вместо этого попросите прочитать с экрана число и ввести его обратно.

Это будет выглядеть так:

<pre>Бла-бла-бла 123456 машин будут затронуты этим. Продолжить?Введите количество машин для подтверждения:</pre>

Затем для выполнения команды нужно точно ввести 123456.

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

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

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

Например, вывести число с одним из числовых разделителей вашего языка, например 123,456 или 123.456, или 123456, или что-то ещё, что вам подходит. Хитрость в том, чтобы не принимать это в качестве входных данных, а требовать, чтобы клиент удалил разделитель и вставил просто цифры.

<pre>Бла-бла-бла 123 456 машин будут затронуты. Продолжить?Введите количество машин для подтверждения: 123456ОК! Продолжаем.</pre>

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

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

Рейчел Кролл, сисадмин в Facebook
Подробнее..

Перевод Используем Ansible вместе с Terraform

30.10.2020 18:08:58 | Автор: admin


Недавно я начал применять Terraform для создания облачной лабы для тестов, и это довольно круто. Буквально за несколько дней я поднялся с никогда не использовал AWS до я умею декларативно создавать изолированную инфраструктуру в облаке. Я поставил парочку серверов в выделенной сети в VPC с security group и отдельными ключами SSH, все это заняло у меня несколько сотен строк кода.


Все приятно и прельстиво, но после создания сервера из некоторого базового AMI мне надо его развернуть. Мой типовой инструмент для этого Ansible, но, к сожалению, у Terraform нет встроенного модуля для Ansible (есть обратный, начиная с Ansible 2.5, прим. переводчика), в отличие от Chef и Salt. Это не похоже на Packer, имеющий ansible (удаленный) и ansible-local, который я использовал для сборки образов Docker.


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


Нужно ли развертывание в облаке?


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


Далее если делаете свои AMI, вам все равно нужно как-то запускать развертывание, так что опять появляются такие вещи, как Ansible. Ну и опять же, я рекомендую использовать Packer вместе с Ansible.


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


Как использовать Ansible вместе с Terraform


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


Встроенный inventory с IP сервера


Наиболее очевидное и хакерское решение запускать Ansible с помощью local-exec, например так:


provisioner "local-exec" {    command = "ansible-playbook -i '${self.public_ip},' --private-key ${var.ssh_key_private} provision.yml"}

Просто и приятно, но тут сразу же есть нюанс. local-exec запускается без ожидания запуска сервера, так что в большинстве случаев это не сработает, потому что на момент подключения еще некуда подключаться.


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


В результате у меня получилась следующая вещь, запускающая роль Ansible provisioner:


provisioner "remote-exec" {    inline = ["sudo dnf -y install python"]    connection {      type        = "ssh"      user        = "fedora"      private_key = "${file(var.ssh_key_private)}"    }  }  provisioner "local-exec" {    command = "ansible-playbook -u fedora -i '${self.public_ip},' --private-key ${var.ssh_key_private} provision.yml"  }

Чтобы ansible-playbook работал, вам надо иметь код для Ansible рядом с кодом для Terraform:


$ ll infradrwxrwxr-x. 3 avd avd 4.0K Mar  5 15:54 roles/-rw-rw-r--. 1 avd avd  367 Mar  5 15:19 ansible.cfg-rw-rw-r--. 1 avd avd 2.5K Mar  7 18:54 main.tf-rw-rw-r--. 1 avd avd  454 Mar  5 15:27 variables.tf-rw-rw-r--. 1 avd avd   38 Mar  5 15:54 provision.yml

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


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


Динамический inventory после работы Terraform


Еще одно простое решение для раскатки инфраструктуры, созданной Terraform не связывать вместе Terraform и Ansible. Создаем инфраструктуру с помощью Terraform, а затем используем Ansible с динамическим inventory без привязки к тому, как сервера были созданы.


Так что вы сначала создаете инфраструктуру с помощью terraform apply, затем запускаете ansible-playbook -i inventory site.yml, где inventory каталог, содержащий скрипты динамического inventory.


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


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


Inventory, создаваемая из состояния Terraform


Есть еще одна интересная штука, которая, возможно, будет у вас работать создание статического inventory из состояния Terraform.


Terraform при работе поддерживает состояние инфраструктуры, содержащее все, включая ваши сервера. При использовании local backend это состояние сохраняется в файле JSON, который можно потом легко разобрать и сконвертировать в inventory для Ansible.


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


Первый


[all]52.51.215.84[all:vars][server]52.51.215.84[server.0]52.51.215.84[type_aws_instance]52.51.215.84[name_c10k server]52.51.215.84[%_1]52.51.215.84

Второй


$ ~/soft/terraform.py --root . --hostfile## begin hosts generated by terraform.py ##52.51.215.84        C10K Server## end hosts generated by terraform.py ##

Дополнение Ansible для Terraform, которое у меня не заработало


Наконец, есть несколько проектов, которые пытаются внедрить поддержку Ansible в Terraform, как это уже, например, сделано для Chef.


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


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


...provisioner "ansible" {    plays {        playbook = "./provision.yml"        hosts = ["${self.public_ip}"]    }    become = "yes"    local = "yes"}...

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


Заключение


Terraform и Ansible мощная связка, которую я использую для развертывания облачной инфраструктуры. Для типовых облачных серверов я запускаю Ansible через local-exec, позднее я запускаю Ansible отдельно с динамическим inventory.


Примеры можно найти здесь.


Благодарю за внимание и до новых встреч!

Подробнее..

Настраиваем и автоматизируем развёртывание Active Directory

03.11.2020 08:13:00 | Автор: admin


В этой статье я бы хотел предложить вам пошаговый туториал по развёртыванию контроллера домена Active Directory на Windows Server 2016 (с графической оболочкой), а также по вводу рабочей станции в получившийся домен. Чем этот туториал может выделиться на фоне других:


  1. Вместо простого "Далее, Далее, кликаем сюда, вбиваем это" я постарался дать внятное объяснение каждому шагу, каждой настройке, которую предстоит выполнить. Помимо основных понятий Active Directory, DNS и DHCP вы также сможете найти много интересной информации по всем галочкам, которые вы часто видели, но не задумывались об их назначении.
  2. В конце статьи я предложу способ автоматизировать развёртывание получившегося стенда полностью с нуля, имея на компьютере только iso-образы ОС Windows 7 и Windows Server 2016. И никакого PowerShell. Всего одной командой.

Статья предполагает наличие у читателя лишь самых начальных знаний об устройстве сетей (на уровне "Что такое IP-адрес и DNS-адрес").


Заинтересовало что-то из вышеперечисленного? Тогда погнали.


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



Начальное состояние стенда:


  1. На машине windows_server уже установлена ОС Windows Server 2016 Standard Evaluation (с GUI). Машина находится в состоянии "сразу после установки ОС". В процессе туториала на ней будут развернуты службы Active Directory (с доменом mydomain.com), DNS и DHCP.


  2. Машина workstation выполняет роль рабочей станции. На ней установлена ОС Windows 7. Машина находится в состоянии "сразу после установки ОС". В процессе туториала она будет подключена к домену mydomain.com.



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


  1. Объясню, почему я выбрал именно такой стенд для туториала;
  2. Супер-краткое описание технологии Active Directory;
  3. Выполняется небольшая предварительная настройка windows_server;
  4. На windows_server производится включение необходимых компонентов;
  5. На windows_server происходит настройка контроллера домена AD (совместно с DNS);
  6. На windows_server происходит настройка сервера DHCP;
  7. На windows_server регистрируется новая учетная запись в AD;
  8. На workstation происходит подключение к домену.

В конце туториала вас ждет приятный бонус я покажу вам как можно развернуть у себя на компьютере весь этот работающий стенд одной единственной командой. Вам понадобится только наличие двух установочных iso-образов (windows 7 и windows server 2016), да небольшой скрипт, ссылку на который я вам дам в конце статьи.


Почему такой стенд?


Такой стенд, с моей точки зрения, отлично подходит для первого самостоятельного "прощупывания" технологии Active Directory. Он минималистичен (всего 2 виртуальные машины), занимает минимум ресурсов, но при этом изолирован и самодостаточен. Его можно развернуть даже на довольно средненьком компьютере и ноутбуке. При этом на стенде уже присутствуют основные сетевые службы (AD + DNS). DHCP хоть и необязателен для функционирования AD, всё равно был добавлен в стенд в ознакомительных целях.


Disclaimer

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


Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями "что, зачем и почему". Туториал ориентирован на людей, не слишком знакомых с технологиями Active Directory, DNS и DHCP, которые хотели бы немного узнать о внутренней кухне администрирования сетей с Active Directory.


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


Что такое Active Directory


Active Directory это службы каталогов от компании Microsoft, как подсказывает нам Википедия. За этим сухим и невзрачным определением скрывается одна из важнейших технологий в администрировании сетей. Благодаря Active Directory администоратор сети получает очень удобное централизированное средство управления учетными записями пользователей, групповыми политиками (в т.ч. политиками безопасности) и объектами в сети (причём Active Directory без особых проблем справляется даже с гигантскими сетями). А благодаря встроенному механизму репликации, "положить" правильно настроенные сервисы AD не так-то просто. Ну и напоследок, благодаря Windows, настроить Active Directory можно буквально мышкой, так что даже совсем начинающие IT-шники смогут с этим справиться.


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


Начинаем


Вы установили Windows Server 2016 и (надеюсь) видите следующий экран:



Эта панель основное (графическое) средство администрирования Windows Server 2016. Здесь вы можете управлять компонентами и сервисами на вашем сервере (проще говоря, настраивать то, что умеет делать сервер). Эту же панель можно использовать и для базовых сетевых настроек Windows Server, для чего есть вкладка "Локальный сервер".


Базовые настройки Windows Server


Первое, что нужно сделать это поменять сетевое имя сервера.


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


Проблема в том, что по-умолчанию для Windows Server генерируется совершенно нечитаемое и неинформативное сетевое имя (я выделил его красным цветом на скриншоте).


Рабочии станции ещё могут позволить себе иметь нечитаемый Hostname, но никак не сервер. Поэтому я предлагаю поменять эту абракадабру его на что-то более разумное (например, на ADController), благо делается это быстро.


Смена сетевого имени

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



После смены имени машину нужно будет перезагрузить.


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


Настройки IP для интерфейса windows_server


Включаем нужные компоненты


Для нашего стенда нам понадобится включить следующие сервисы (или, как они тут называются, роли) на Windows Server:


  • Доменные службы Active Directory;
  • DNS-сервер;
  • DHCP-сервер.

Пройдемся вкратце по каждому из них.


Доменные службы Active Directory


Эта роль фактически "включает" технологию Active Directory на сервере и делает его контроллером домена (под доменом в технологии AD понимается группа логически связанных объектов в сети). Благодаря этой роли администратор получает возможность управлять объектами в сети, а также хранить информацию о них в специальной распределенной базе данных.


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


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


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


С этим пунктом все более менее понятно, а зачем же нам включать дополнительно ещё DNS-сервер?


DNS-сервер


Обычно протокол DNS (Domain Name System) используется для обращения к узлам в сети не по их IP-адресу, а по доменному имени (строковый идентификатор), что, конечно, гораздо удобнее. Другими словами, DNS чаще всего используется для разрешения доменных имен.


Но область применения протокола DNS не ограничивается только сопоставлением хостового имени и IP-адреса, что как раз подтверждает технология Active Directory. Дело в том, что Microsoft решила построить технологию Active Directory не с нуля, а на основе протокола DNS. В частности, протокол DNS используется при определении местонахождения всех ключевых сервисов Active Directory в сети. Другими словами, рабочая станция при подключении к контроллеру домена понимает, "куда" ей надо обращаться, именно с помощью протокола DNS.


Все DNS-записи (в том числе с информацией о сервисах Active Directory) хранятся на DNS-сервере, а это значит, что нам нужно заиметь свой собственный DNS-сервер! Вот только вопрос, откуда его взять? Есть два варианта:


  1. Использовать отдельную машину в роли DNS-сервера;
  2. Использовать саму машину windows_server в роли DNS-сервера.

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


Именно поэтому эту роль (DNS-сервера) тоже нужно добавить к ролям машины windows_server.


Кстати, если не добавить роль "DNS-сервер" сейчас, то в будущем у вас ещё будет такая возможность при конфигурировании контроллера домена AD.


DHCP-сервер


Протокол DHCP (Dynamic Host Configuration Protocol) нужен для автоматической выдачи сетевых настроек узлам в сети. Под сетевыми настройками понимается IP-адрес, адрес шлюза по-умолчанию, адрес DNS-сервера, и ещё ряд других настроек. Этот протокол чрезвычайно удобен при администрировании сетей, особенно больших.


В этом туториале я использую протокол DHCP чтобы рабочая станция workstation могла получить сетевые настройки (в частности, адрес DNS-сервера) без каких-либо действий с моей стороны.


Протокол DHCP не имеет никакого отношения к технологии Active Directory, и можно было бы обойтись вовсе без него (достаточно прописать все сетевые настройки на рабочей станции самостоятельно), но я решил включить этот протокол в данный туториал просто для общего ознакомления. К тому же, такая связка "Контроллер AD DNS-сервер DHCP-сервер" довольно часто встречается в реальной жизни, потому что это очень удобный набор сервисов.


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


Что ж, довольно теории, давайте лучше перейдём к включению этих самых ролей.


Мастер добавления ролей и компонентов


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


Выбор типа установки


Нас устраивает значение по-умолчанию (Установка ролей или компонентов"), но интересен и второй пункт он позволяет задействовать ещё одну возможность Windows Server инфраструктуру виртуальных рабочих мест (Virtual Desktop Environment VDI). Эта интереснейшая технология позволяет, буквально, виртуализировать рабочее место. То есть для пользователя создаётся виртуальное рабочее место, к которому он может подключаться через тонкий клиент. Пользователь лишь видит картинку, тогда как само рабочее место может совершенно прозрачно работать где угодно.


Впрочем, технология VDI это отдельная большая тема, а в этом туториале надо сосредоточиться на контроллере AD, так что кликаем "Далее" и видим экран выбора целевого сервера.


Выбор целевого сервера


Мастер добавления ролей позволяет устанавливать роль не только на текущую машину, но вообще на любой добавленный сервер, и даже на виртуальный жёсткий диск. Да, если ваша Windows Server развернута на виртуальной машине (а это довольно частое явление), то вы можете администрировать эту виртуальную машину даже не запуская её! Понаблюдать за этим процессом можно, например, здесь.


Нам же такая экзотика ни к чему, так что просто выбираем единственный возможный сервер (обратите внимание, что он теперь называется ADController место непонятной абракадабры), жмём "Далее" и, наконец, попадаем на экран выбора ролей, которые нужно добавить.


Выбор добавляемых ролей


Выбираем три роли, о которых уже говорили ранее, и продолжаем.


Выбор компонентов


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


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


При этом глядя на список "Компонентов" так сходу и не скажешь, что какие-то вещи в списке лишь "вспомогательные". Вот например, DHCP-сервер расценивается как роль, а WINS-сервер уже как компонент. А чем SMTP-сервер хуже DNS?


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


В любом случае, дополнительные компоненты нам не нужны, так что кликаем "Далее".


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


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


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


Остаётся лишь дождаться, когда заполнится progress-bar, и перейти к следующему пункту туториала настройке контроллера домена AD.


Настраиваем контроллер домена Active Directory


Все роли и компоненты успешно добавлены, о чём свидетельствует следующий экран:



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


Погодите-ка, ЧТО?!


А чем же я занимался последние 15 минут? Я же добавлял роли, и судя по сообщению, они успешно добавились! И тут меня снова хотят заставить добавлять какие-то новые роли? В чем-то тут подвох.


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


Английская версия скриншота


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


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


Конфигурация развёртывания


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



Технология Active Directory (как и DNS) подразумевает иерархическое построение имён на основе доменов. Домены могут выстраиваться в доменные деревья по принципу "родительско-дочерних" отношений. В основе дерева лежит так называемый корневой домен (на картинке выше это sources.com, xyz.com и abc.com). При этом домен может иметь сколько угодно потомков. Домен-потомок располагается в просранстве имён родителя и является его "поддоменом" (subdomain). У доменного имени домена-потомка есть дополнительный префикс относительно доменного имени родителя (rus.abc.com, eng.abc.com). Один корневой домен основывает только одно доменное дерево со своим независимым пространством имён.


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


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


  1. Добавить контроллер домена в существующий домен (помните про резервирование контроллеров в домене, так ведь?). Этот вариант не для нас, ведь домена ещё никакого нет;
  2. Добавить новый домен в лес. Этого мы тоже сделать не можем, т.к. и леса у нас тоже никакого нет;
  3. Добавить новый лес. Это вариант как раз для нас. При этом нам тут же предлагают выбрать корневой домен для этого леса (первый домен, который будет создан в лесу).

Назовём корневой домен mydomain.com и кликнем "Далее"


Параметры контроллера домена


Рассмотрим возможные параметры:


  1. Режим работы леса и домена. Домены в одном лесе могут работать в разных режимах в зависимости от версии Windows Server на борту. Лес должен иметь режим не выше, чем самый "старый" домен в его составе. Т.к. мы планируем использовать только Windows Server 2016, то оставим этот режим и для леса и для домена;
  2. DNS-сервер. Если ранее Вы не активировали роль DNS-сервера в мастере добавления ролей, то можете сделать это сейчас (вам даже предложат такой вариант по-умолчанию);
  3. Должен ли контроллер домена выступать в роли Global Catalog-сервера;
  4. Включить ли режим базы данных Active Directory "только на чтение". Основная задача, которую преследует технология RODC возможность безопасной установки собственного контролера домена в удаленных филиалах и офисах, в которых сложно обеспечить физическую защиту сервера с ролью DC. Контроллер домена RODC содержит копию базы Active Directory, доступную только на чтение. Это означает, что никто, даже при получении физического доступа к такому контроллеру домена, не сможет изменить данные в AD (в том числе сбросить пароль администратора домена) (информация взята отсюда)

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


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


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


Что такое вообще "Глобальный каталог"? Согласно Miscrosoft это распределенное хранилище данных, которое хранит частичное представление обо всех AD-объектах в лесу. Это хранилище располагается на котроллерах домена, которые имеют дополнительную роль "Global Catalog Server" (Сервер глобального каталога). От обычного кнтроллера домена GC-сервер отличается в первую очередь тем, что помимо полной копии всех объектов в своем домене, хранит также частичную информацию обо всех объектах в других доменах леса.


Чего это позволяет достичь? Давайте представим, что рабочая станция запросила информацию об объекте из другого домена. Она обращается на GC-сервер с просьбой предоставить ей информацию об этом объекте. GC-сервер, в свою очередь, может:


  1. Либо отдать рабочей станции нужную информацию сразу (если эта информация у GC-сервера имеется);
  2. Либо перенаправить запрос к нужному контроллеру домена, где эта информация точно будет находиться. Чтобы понять, какому контроллеру домена нужно перенаправить запрос, как раз и происходит поиск по GC.

Информация о том, какие атрибуты попадают в глобальный каталог, определена в Partial Attribute Set (PAS), который может настраивать администратор AD. Например, если администроатр понимает, что рабочие станции часто будут обращаться к атрибуту, который не содержится в глобальном каталоге, он может добавить туда этот атрибут. Тогда запросы рабочих станций при чтении этого атрибута будут выполняться значительно быстрее, т.к. уже ближайший GC-сервер сможет предоставить им всю нужную информацию.


Однако, если в лесе всего один домен (как у нас), то Глобальный каталог содержит полную копию объектов в домене и всё.


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


Что ж, давайте согласимся с этим "выбором" мастера и перейдём к последнему параметру на этом скриншоте к паролю для режима восстановления служб каталогов. Это особый режим безопасной загрузки Windows Server, который позволяет администратору работать с базой данных AD. Этот режим применяется, например, в следующих случаях:


  • база Active Directory повреждена и нуждается в исправлении;
  • требуется выполнить обслуживание базы данных AD (сжатие, анализ на наличие ошибок);
  • требуется восстановить резервную копию базы данных AD;
  • требуется сменить пароль администратора.

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


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


Делегирование DNS


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


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


NetBIOS-имя


Мы видим, что мастер предложил нам на выбор сразу же имя для нашего домена MYDOMAIN. Но вы можете (и должны) задать себе вопрос: а что такое вообще NetBIOS-имя и зачем оно нужно? И разве мы уже не настраивали сетевое имя узла (Hostname) в самом начале? Чего же от вас хотят?


NetBIOS (Network Basic Input/Oputout) это ещё один способ разрешения имён узлов в сети (более древний и более примитивный, чем DNS). NetBIOS-имена не предполагают никакой иерархии, их длина ограничивается всего лишь 16 символами, и они применяются только для разрешения имён компьютеров в локальной сети. Когда мы в самом начале туториала выбрали сетевое имя ADController мы, на самом деле, задали именно NetBIOS-имя для сервера. Но теперь от нас снова требуют выбрать NetBIOS-имя (да ещё и другое, отличное от ADContoller). Не много ли NetBIOS-имён для одного компьютера?


Дело в том, что Microsoft пошла ещё дальше и ограничила длину NetBIOS-имен не 16 символами, а 15 символами. 16-ый символ при этом считается зарезервированным суффиксом, который может принимать фиксированные значения. В зависимости от значения 16-го байта получаются разные классы NetBIOS-имён. Например, если суффикс равен 00, то NetBIOS-имя относится к рабочей станции. Если суффикс равен 1С, то это имя относится к имени домена.


То есть, как вы понимаете, на первом шаге мы задавали NetBIOS-имя для компьютера Windows Server (с суффиком 00). А теперь задаём NetBIOS-имя домена mydomain.com (с суффиксом 1С).


Кстати, можете, ради интереса, отмотать туториал в самое начало и посчитать количество символов в "нечитаемом" автоматически сгенерированном сетевом имени windows_server. Будет как раз 15 символов (максимальная длина NetBIOS-имени).


И напоследок скажу, что вы не можете пропустить этот шаг. NetBIOS хоть и устаревшая технология, но до сих пор используется ради совместимости с некоторыми старыми службами. Настроить контроллер домена Active Directory без NetBIOS-имени нельзя.


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


Расположение базы данных


Все ваши настройки должны пройти предварительную проверку:


Проверка предварительных требований


Как только всё готово, жмите "Установить" и спокойно идёте пить чай, потому что после установки автоматически начнётся очень-очень долгая перезагрузка. Зато настройка контроллера домена AD на этом закончена, поздравляю!


Настройка DHCP-сервера


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


  1. Авторизация DHCP-сервера в домене AD. Не каждый DHCP-сервер может раздавать сетевые настройки в домене AD только авторизованные. Это сделано с целях безопасности, чтобы другие DHCP-серверы не могли "подсунуть" неправильные настройки компьютерам в домене;
  2. Настройка новой DHCP-области. Это уже непосредственно настройка самого DHCP-сервера, в ходе которой определяются какие сетевые настройки будут выдаваться компьютерам в сегменте сети.

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


Запуск авторизации DHCP-сервера




В открывшемся мастере настройки DHCP после установки пропускаем первый приветственный экран и переходим к экрану авторизации


Авторизация DHCP-сервера в домене


На выбор предлагаются три варианта:


  1. Использовать учётные администратора (по-умолчанию)
  2. Использовать учётные данные другого пользователя;
  3. Пропустить авторизацию AD.

По-умолчанию авторизовать DHCP-сервер в домене могут только члены группы EnterpriseAdmins, куда как раз и входит пользователь MYDOMAIN\Администратор. При желании можно потратить немного времени и делегировать эту возможность админам "помельче" (региональным администраторам), подчерпнуть больше информации по этой теме можно отсюда.


Итак, выбираем вариант по-умолчанию и завершаем первый этап настроки DHCP-сервера.


Завершение авторизации DHCP-сервера


Теперь переходим непосредственно к настройкам DHCP. Для этого на панели мониторинга кликаем вкладку "Средства" и выбираем пункт "DHCP"



В открывшемся окне с настройками DHCP нужно кликнуть правой кнопкой мышки на IPv4 и затем на пункт меню "Создать область". После этого откроется мастер создания новой области.


Открытие мастера создания новой области



Что такое DHCP-область? Под этим понимается некий диапазон IP-адресов, которые может выдавать DHCP-сервер другим компьютерам в сети. Каждая область помимо диапазона IP-адресов также содержит другие сетевые настройки, с которыми мы сейчас и познакомимся.


Назовём DHCP-область SCOPE1 и перейдём дальше.


На следующем экране вам предложат выбрать диапазон адресов, которые будут выдаваться компьютерам в сети. Ранее я настраивал сетевой интерфейс на Windows Server, выдав ему адрес 192.168.1.1/24. Это статический адрес и он зарезервирован, его выдавать другим компьютерам нельзя.


Зато никто не мешает выдавать все остальные адреса в сети 192.168.1.0/24 так что задаём диапазон от 192.168.1.2 до 192.168.1.254 (192.168.1.255 это зарезервированный широковещательный адрес, его выдавать тоже нельзя).


Настройка диапазона адресов


В целом, никто не мешает вам как администратору выдавать меньше IP-адресов, чем доступно в адресации сети. Например, можно было бы выделить в сети всего 100 адресов для автоматической выдачи: 192.168.1.101-192.168.1.200.


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


Исключения в диапазоне и задержка DHCPOFFER


С исключениями всё более-менее понятно: если вы не хотите выдавать некоторые адреса в указанном ранее диапазоне, то вы можете указать эти адреса здесь в виде исключений. А что за задержка в DHCPOFFER такая?


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


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


Настройка времени аренды адресов


Протокол DHCP предполагает выделение адресов только на определённое время, после чего компьютеры должны продлять аренду. Здесь можно настроить это время (по-умолчанию 8 дней).


8 дней меня лично вполне устраивает, так что кликаем "Далее" и видим предложение настроить другие настройки, которые будут получать клиенты в сети (помимо IP-адреса). Соглашаемся.


Настроить дополнительные параметры


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


Шлюз по-умолчанию


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


А вот для понимания имени родительского домена, рассмотрим следующую ситуацию.


Допустим, есть домен mydomain.com и есть два компьютера в этом домене с именами comp1.mydomain.com и comp2.mydomain.com. Если comp1 хочет связаться с comp2, то он должен, по-хорошему, использовать следующую команду (обращение по Fully Qualified Domain Name FQDN):


ping comp2.mydomain.com

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


ping comp2

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


Процесс разрешения сетевых имён


  1. Поиск информации в hosts.txt или в кеше;
  2. Попытка найти имя через DNS;
  3. Попытка найти NetBIOS-имя в кеше;
  4. Попытка найти NetBIOS-имя через WINS-сервер;
  5. Попытка найти NetBIOS-имя путём отправки широковещательных пакетов в локальную сеть;
  6. Попытка найти NetBIOS-имя в LMHOSTS-файле.

Согласно алгоритму разрешения сетевых имен, сначала comp1 попробует найти информацию о comp2 в hosts.txt файле. Если этой информации там не окажется, то начинается процесс поиска узла через DNS. Вот только вопрос DNS-имена же находятся в каком-то домене, верно? Какое доменное имя нужно "пристыковать" к comp2 при выполнении пинга?


Вот тут в дело и вступает настройка DHCP, которая называется "имя родительсокго домена". Это как раз тот суффикс, который будет автоматически "пристыкован" к имени comp2 при выполнении DNS-разрешения имени. Так что если имя родительского домена равно "mydomain.com", то команда ping comp2 неявно преобразуется в ping comp2.mydomain.com.


Если же DNS-разрешение окажется неудачным, дальше начнутся попытки найти comp2 уже по NetBIOS-имени. Что такое WINS, и чем он отличается от Broadcast информация будет чуть дальше по тексту.


Что ж, в нашем случае имя родительсокго домена должно быть mydomain.com (значение по-умолчанию), а нужный DNS-сервер уже находится в списке, так что в итоге просто кликаем "Далее".


Настройки DNS


Теперь нас попросят указать настройки WINS-сервера. WINS (Windows Internet Name Service) сервер участвует в разрешении NetBIOS-имён в сети (прямо как DNS-сервер для DNS-имён). Вот только, в отличие от DNS, WINS-сервер не обязательно должен присутствовать в сети, чтобы разрешение NetBIOS-имён работало. Так зачем же он нужен тогда?


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


  1. При наличии большого количества NetBIOS-имён в сети широковещательный тафик может начать "зашумлять" канал;
  2. Широковещательные запросы не могут "выйти" за пределы текущей сети, поэтому узнать NetBIOS-имя из другой сети таким способом не выйдет.

Так вот, WINS-сервер позволяет решить обе этих проблемы. Этот сервер централизованно хранит NetBIOS-имена компьютеров, и обычные узлы в сети могут обращаться к нему для поиска IP-адреса интересующего их имени (как и для DNS). Такой подход, во-первых, резко уменьшает количество широковещательного трафика в сети, а, во-вторых, позволяет посылать NetBIOS-запросы в другие сети, а не только в текущую.


В нашей небольшой сети WINS-сервер нам ни к чему, поэтому просто пропускаем эту настройку и едем дальше.


WINS-серверы


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


Активация области


Создаём нового пользователя в домене AD


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


Для этого возвращаемся на панель мониторинга, кликаем на "Средства" и затем на "Пользователи и Компьютеры Active Directory"



В открывшемся меню можно заметить созданный домен mydomain.com и его состав. Видно, что помимо пользователей в домене созданы папочки для Computers, Domain Controllers и других сущностей. Но нас сейчас интересуют пользователи, поэтому кликаем правой кнопкой мышки на папке Users и выбираем "Создать" -> "Пользователь"



После этого появляется диалоговое окно с преложением ввести данные нового пользователя. По старой доброй традиции назовём пользователя Foo Bar. Обратите внимание, что пользователь отображается лишь как "Объект" в Active Directory наравне с другими объектами.


Новый объект - Пользователь


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


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


Параметры нового пользователя


После этого останется лишь подтвердить создание нового пользователя.


Подтверждение создания нового пользователя


Ну что ж, вот, кажется, и всё! Осталось лишь проверить ввод рабочей станции в домен.


Ввод рабочей станции в домен


Переключаемся на вторую машину workstation под управлением Windows 7 и заходим в свойства системы. Сейчас видно, что рабочая станция находится в рабочей группе (не в домене). Кстати говоря, WORKGROUP это тоже NetBIOS-имя. Только в отличии от имени домена оно имеет суффикс 1E.



Щелкаем на кнопку "Изменить параметры", затем в появившемся окне ещё раз "Изменить...".


В окне изменения имени компьютера пишем, что он должен принадлежать домену mydomain.com.


Подключение к домену


Видим предупреждение о нестандартном имени компьютера (testo-ПК содержит кириллицу). Это связано с тем, что NetBIOS-имена не могут содеражать кириллицу. Но мы с вами настроили DNS-сервер (DNS настройки прилетели на рабочую станцию по DHCP), а DNS-механизм разрешения имён, как мы знаем, имеет приоритет перед NetBOIS. Так что в данном случае на работоспособность AD кириллица не влияет. Но на практике так делать не надо!


Нестандартное имя компьютера


Вводим логин-пароль от новой учетной записи FooBar и, наконец, видим заветное сообщение "Добро пожаловать в домен"


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



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


Логин в AD


И после успешного входа на рабочий стол перепроверяем свойства системы.


Новые свойства системы


Полное имя компьютера поменялось на testo-ПК.mydomain.com, а это значит, что мы успешно ввели рабочую станцию в домен mydomain.com.


Автоматизируем


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


Так почему бы не автоматизировать все действия с клавиатурой и мышкой, которые мы предпринимали? И нет, я говорю не об AutoIT, я говорю о платформе Testo, создателем которой я являюсь. Эта платформа позволяет фиксировать все действия, проводимые с виртуальными машинами, в виде скриптов на специальном языке Testo-lang. Ну а Testo затем превратит эти скрипты обратно в действия.


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


Секция скрипта на языке Testo-lang


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



Всё, что Вам потребуется для создания собственного стенда с настроенной Active Directory это:


  1. Установочный iso-образ Windows Server 2016 русской версии;
  2. Установочный iso-образ Windows 7 (придётся поискать самим);
  3. Скрипты на языке Testo-lang;
  4. Установленная платформа Testo (бесплатно);
  5. Выполнить команду.

sudo testo run ./tests.testo --param ISO_DIR /path/to/your/iso/dir

И всё. Как и я обещал всего одна команда. Через пол часа час (зависит от шустрости вашего компьютера) вы сможете наслаждаться своим готовым стендом.


Итоги


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


  • сайт платформы Тесто.
  • youtube-канал, где можно найти много примеров.
  • основная статья на хабре
  • статья, где я автоматизировал несколько системных тестов для Dr. Web
  • скрипты на языке Testo-lang для этого туториала
Подробнее..

Docker swarm и балансировка нагрузки по нодам

03.11.2020 18:06:31 | Автор: admin

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

1) Описание проблемы

Чтобы понять проблему, рассмотрим ее на примере проекта нашей компании. Исторически сложилось, что мы использовали монолитную архитектуру с оркестрацией на docker swarm. Помимо монолита у нас имеется ряд вспомогательных сервисов и консьюмеров. Источником основной нагрузки на сервера выступает php-fpm, который выполняет код монолита. В продакшене мы имели следующую схему.

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

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

Данная схема достаточно хорошо работала, но с ростом количества пользователей нагрузка на сервер Web 1 значительно росла и становилось понятно, что его мощностей уже не достаточно. Мы понимали, что покупать более мощный сервер менее перспективно в плане отказоустойчивости и дороже по цене, чем масштабироваться горизонтально, увеличивая количество серверов. К тому же у нас в продакшене уже был готовый инструмент на сервере Web1, который успешно выполнял свою задачу. Поэтому мы добавили под управление Docker Swarm еще один сервер. Получилась следующая схема.

Мы получили кластер из двух серверов, в котором Web 1 является master нодой, а web2 обычный worker. В этой схеме мы были уверены в master ноде, поскольку это все тот же сервер, который у нас был . Мы понимали, что он надежный и имеет высокую доступность. А вот сервер Web 2 был темной лошадкой, поскольку его выбрали cloud сервером, исходя из ценовой политики, который ранее не испытывали в продакшене. При этом сервера не находятся в одном помещении, поэтому могут быть проблемы с сетевым взаимодействием.

Отсюда мы получили следующие важные для нас критерии: кластер должен автоматически перестраиваться в случае отказа воркера (Web 2) и забирать всю нагрузку и сервисы на себя, но после появления воркера (Web 2) автоматически раскидывать всю нагрузку обратно равномерно по серверам. По сути, это стандартная задача, которую должен решать Docker Swarm.

Мы провели эксперимент, отключили сервер Web 2 сами и посмотрели, что будет делать Swarm. Он сделал, что и ожидалось поднял все сервисы на master ноде (Web 1). Проверив то, что наш кластер верно себя ведет при отказе второго сервера, мы обратно включили Web 2.

На этом этапе мы обнаружили первую проблему нагрузка осталась по прежнему на сервере Web 1 и Docker Swarm лишь запустил сервисы, которые запускались глобально для всего кластера. Столкнувшись с первым ограничением, мы поняли, что сервера не так часто становятся недоступными. Поэтому в случае отказа Web 2 сервера, мы сами проведем балансировку, воспользовавшись командой:

docker service update  --force

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

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

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

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

Мы выполнили настройку кластера, выставили резервацию ресурсов под основной сервис php-fpm и выполнили проверку как поведет себя Docker Swarm при отключении ноды Web 2. Оказалось, что решив проблему с распределением сервиса php-fpm по серверам, мы указали резервацию ресурсов, которая не позволяла запускать php-fpm контейнеров больше, чем сейчас есть на данном сервере. Соответственно с отключением сервера Web 2 все остальные контейнеры запускались на сервере Web1, но сервис php-fpm оставался в подвешенном состоянии, поскольку из-за ограничения резервации ресурсов процессора он не имел подходящих нод для запуска всех реплик. С включением сервера Web 2 происходил запуск всех реплик php-fpm, которые не могли найти подходящий сервер, все остальные сервисы продолжали работу на сервере Web 1. В разрезе того, что основную нагрузку дает php-fpm, мы получили равномерное распределение загрузки серверов, при этом решили проблему с балансировкой нагрузки после отказа одной ноды и возвращения ее в строй. Но спустя некоторое время обнаружилась новая проблема.

Однажды нам понадобилось отключить Web 2 сервер для технических работ. В этот момент разработчики заливали код через ci на наш кластер и обнаружилось, что пока сервер Web 2 выключен, обновление кода не происходит. Это было очень плохо, поскольку сами разработчики не должны заботиться о состоянии кластера и иметь возможность в любой момент залить код на продакшен окружение. Источником проблемы как раз была резервация ресурсов под контейнер в Docker Swarm. Из-за недостатка свободных ресурсов, Swarm выдавал информацию об отсутствии подходящих нод для запуска и наше обновление кода благополучно зависало до появления второй ноды (Web 2) в кластере.

2) Наше решение проблемы

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

Именно эта идея и стала основой для нашего мини-проекта Swarm Manager. Swarm Manager это обычный bash-скрипт, который основывается на докер команды и ssh, осуществляет ту самую балансировку в нужный момент. Для его работы как демона мы запускаем его в cron контейнере. Визуально это выглядит следующим образом.

В целом видно, что в контейнер мы передаем cron конфиг с вызовом нашего скрипта swarm_provisioner.sh, который уже выполняет действия по балансировке. Чтобы swarm_provisioner.sh смог корректно работать на любой из нод кластера, необходимо разрешить ssh подключение к root пользователю с любого сервера кластера к любому серверу в кластере. Это даст возможность скрипту зайти на удаленный сервер и проверить запущенные на нем контейнеры. Для тех, кому не подходит пользователь root, можно поменять пользователя в swarm_provisioner.sh, заменив root в переменной SSH_COMMAND на подходящего пользователя с доступом к команде docker ps. Рассмотрим пример cron file:

SHELL=/bin/bash*/1 * * * * /swarm_provisioner.sh "web-group" "edphp-fpm" "-p 22"

Как видим, это обычный cron файл с вызовом каждую минуту скрипта swarm_provisioner.sh с заданными параметрами.

Рассмотрим параметры, которые передаются в скрипт.

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

Второй параметр имя сервиса, балансируемого по нодам, с приставкой названия кластера. В примере кластер называется ed, а сервис - php-fpm.

Третий параметр это порт ssh, по которому скрипт будет стучаться на сервера в кластере с указанным label и проверять количество запущенных контейнеров сервиса. Если скрипт увидит перекос по запущенным контейнерам на серверах, он выполнит команду docker service update --force.

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

swarm-manager:image: swarm-manager:latestvolumes:- /var/run/docker.sock:/var/run/docker.sock:ro- /swarm-keys:/root/.sshdeploy:replicas: 1update_config:parallelism: 1delay: 1sorder: start-firstrestart_policy:condition: on-failureplacement:constraints:- node.role==manager

3) Выводы

Мы получили инструмент, который решил наши проблемы. На данном этапе это только первая версия. Скорее всего, в будущем мы выполним замену ssh на docker api, которое позволит более просто запускать этот сервис из коробки, и поработаем над ограничениями, которые сейчас существуют.

Ссылка на проект.

Подробнее..

Перевод Вышел Loki 2.0

04.11.2020 12:10:51 | Автор: admin


Преобразовывайте свои журналы прямо во время запроса, настраивайте уведомления с Loki.


Прошел примерно год после выпуска Loki 1.0, мы за это время заметили большой всплеск внедрений в компаниях (например, Grofers и Paytm Insider), использующих как облачную версию Grafana, так и размещенную на своих мощностях. В то же время мы приложили много усилий для улучшения производительности, используя оптимизацию и распараллеливание запросов. В последнем выпуске 1.6.0 мы продолжили рефакторинг кода для достижения еще большей производительности, а также добавили небольшие новые функции к языку запросов, например, бинарные операции.


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


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


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


Давайте посмотрим детальнее на новые функции!


Извлечение меток из строк журналов во время запроса


Давайте посмотрим на новые дополнения к языку запросов в версии 2.0!



С оранжевыми пунктами вы уже должны быть знакомы. Выборка содержимого журнала с помощью |= != |~ и !~, а также преобразование ваших журналов в параметры с использованием rate и count_over_time уже работали в Loki 1.x. Все остальное, выделенное белым цветом новое в версии 2.0, мне кажется, что будет лучше рассмотреть, как оно работает детальнее на примерах, так что погнали!


Разбор


Это начальная точка: мы извлекаем метки во время запроса. Например, у нас есть поставщик журнала:



Посмотрите, какие метки были возвращены:



Давайте немножко поменяем запрос и посмотрим на результат, возвращаемый по этому журналу:



Обратите внимание на метки...



Вот так вот просто каждая пара ключ=значение из logfmt стала меткой!


Не используете logfmt? Тогда мы идем к вам!


Регулярное выражение:



JSON:



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

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


Выборка


В Loki 2.0 доступны более мощные возможности выборки. Используя расширенные существующие выражения для выборки, вы теперь можете отсеять данные, полученные на предыдущем этапе разбора. Давайте посмотрим на пример, показывающий только те строки журнала, где извлеченный параметр duration больше 1 секунды с помощью query_type=filter:



Обратите внимание на умную обработку Loki выходных типов в некоторых контекстах, в этом случае идет разбор duration в стиле Golang.


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



В вышеприведенном случае такие строки не JSON, так что они не были обработаны как JSON на этапе json. Теперь, когда вы узнали причину, можно легко и непринужденно исключить такие строки:



Форматирование


Упростить работу всем, кто смотрит журналы, стало еще легче. Loki 2.0 может перезаписать ваши строки журнала так, как они показаны, а также с его помощью можно сделать так:



Превращаем в такое:



Метки label_format и line_format используют синтаксис шаблонов Golang, позволяя вам выбрать связанные строки журнала для отображения. С этим также связаны другие дополнительные возможности, например, способность вертикального выравнивания или обрезания содержимого журнала.


Графики


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


  • sum_over_time
  • avg_over_time
  • stddev_over_time
  • stdvar_over_time
  • max_over_time
  • min_over_time
  • quantile_over_time

Давайте рассмотрим пример использования, чтобы отобразить 99 перцентиль параметра request_time из журналов NGINX, сгруппированных по целевому серверу:



А теперь берем тот же запрос и группируем по клиентскому IP:



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


Еще пара примеров:




В последнем примере вы можете видеть такое: duration(duration). Так можно указать Loki разбирать значения duration в стиле Golang (там добавляются единицы, например s или ms). Скоро будет доступна поддержка и других дополнительных типов, например kb, mb и прочих.


Создание уведомлений из любого запроса


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



Ранее для такого вам надо было настроить Loki в качестве источника данных для Prometheus, после чего указать Grafana использовать его для создания уведомлений. В Loki 2.0 мы внедрили распределенный механизм оценки правил, так что вы можете написать любой запрос и создать уведомление с использованием знакомого синтаксиса Prometheus. Эти уведомления потом отправляются в Prometheus Alertmanager, развернутый отдельно. Процесс создания и отправки уведомлений стал простым!



Удалено отдельное хранилище индексов


И последняя впечатляющая новость о Loki 2.0 удаление пометки "экспериментальный" с типа индекса boltdb-shipper!



В Loki 1.5 мы представили новый индекс boltdb-shipper. С новым индексом вы могли запустить Loki поверх любого объектного хранилища, а сейчас вам уже больше не нужно отдельное выделенное хранилище (DynamoDB, Bigtable, Cassandra и другие), а также все дополнительные, связанные с ним, затраты! В 2.0 эта функция готова к промышленному использованию. В Grafana Labs мы для себя уже переместили в этом направлении все наши кластера.


Дополнительная информация


Нет возможности запустить свой Loki, либо просто хотите попробовать все это в действии? Активируйте испытательный период в 30 дней в Grafana Cloud! В облаке вы получите экземпляр Loki, связанный с Grafana и Alertmanager с новым интерфейсом правил уведомлений, с которым вы легко запустите процесс сбора журналов и создания уведомлений за несколько минут!


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


А еще у нас есть шикарнейшее видео от Ward Bekker с исследованием и обзором новых функций в 2.0.



От редакции: Подробнее о работе с Loki можно узнать на курсе Слёрма Мониторинг и логирование инфраструктуры в Kubernetes. Курс от основ до продвинутого уровня для быстрого ввода в эксплуатацию мониторинга и логирования инфраструктуры.

Подробнее..

Перевод Распутывая Ansible Loops

05.11.2020 10:06:30 | Автор: admin

В посте рассматриваются следующие Ansible модули loop: with_items, with_nested, with_subelements, with_dict.


Исходный код https://github.com/ctorgalson/ansible-loops


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


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


Например, следующая задача использует модуль File (документация, код) для создания определенного каталога, если он еще не существует, и изменяет его атрибуты, если они еще не установлены правильно:


- file:    path: /home/jenkins/.ssh    state: directory    owner: jenkins    group: jenkins    mode: 700

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


Ansible декларативный?


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


- name: Copy SSH config file into Alices .ssh directory.  copy:    src: files/config    dest: /home/alice/.ssh/config    owner: alice    group: alice    mode: 0600

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


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


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


На самом деле для этого есть причина, если вас интересует внутреннее устройство Ansible. На странице Loops в документации указано, что loops на самом деле представляют собой комбинацию вещей с _ + lookup(), поэтому любой плагин поиска можно использовать в качестве источника для цикла. Поиск (Lookups) это тип плагина Ansible, который используется для доступа к данным в Ansible из внешних источников, и если вы сравните документацию Loops и каталог плагинов Ansible на Github, вы увидите многие из них с одинаковыми именами.


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


ЦИКЛ ANSIBLE


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


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


  1. Убедитесь, что присутствуют четыре пользователя: alice, bob, carol и dan.


  2. Убедитесь, что домашний каталог каждого пользователя содержит два каталога: .ssh/ и loops.


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



/home/alice/ .ssh/ bob/ carol/ dan/ loops/

ЦИКЛ 1. СОЗДАНИЕ ПОЛЬЗОВАТЕЛЕЙ WITH_ITEMS


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


- name: Remove user Chuck from the system.  user:    name: chuck    state: absent    remove: yes

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


- name: Remove users Chuck and Craig from the system.  user:    name: "{{ item }}"    state: absent    remove: yes  with_items:    - chuck    - craig

Возвращаясь к нашему первому примеру цикла, мы можем использовать with_items для создания первых пользователей в нашем списке, alice и bob:


Переменные

users_with_items:  - name: "alice"    personal_directories:      - "bob"      - "carol"      - "dan"  - name: "bob"    personal_directories:      - "alice"      - "carol"      - "dan"

TASKS

- name: "Loop 1: create users using 'with_items'."  user:    name: "{{ item.name }}"  with_items: "{{ users_with_items }}"

Здесь мы используем модуль Ansible User для перебора переменной с именем users_with_items. Эта переменная содержит имена и информацию о двух пользователях, но задача только гарантирует, что пользователи существуют в системе, она не создает каталоги, содержащиеся в списке personal_directories каждого пользователя (обратите внимание, что personal_directories это просто произвольный ключ в массиве данных для нашего примера).


Это примечательная особенность циклов Ansible (и Ansible в целом): поскольку TASKS вызывают определенные модули с определенной проблемной областью, обычно в задаче невозможно выполнять более одного вида вещей. В данном конкретном случае это означает, что мы не можем убедиться, что personal_directories пользователя существуют из этой TASKS (т. е. Потому что мы используем модуль User, а не модуль File).


Цикл with_items работает примерно так же, как этот цикл PHP:


<?phpforeach ($users_with_items as $user) {  // Do something with $user...}

Мы писали задачу как обычно, за исключением того, что:


Мы заменили имя переменной item.name на имя пользователя.


Мы добавили строку with_items, определяющую переменную для перебора.


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


РЕЗУЛЬТАТ

/home/ alice/ bob/

ЦИКЛ 2: СОЗДАВАЙТЕ КАТАЛОГИ ОБЩИХ ПОЛЬЗОВАТЕЛЕЙ, ИСПОЛЬЗУЯ WITH_NESTED


Примечание: Для цикла 2 нужны созданные юзеры, например с помощью цикла 1. Иначе будет ошибка chown failed: failed to look up user


В этом примере мы используем две переменные, users_with_items из цикла 1, и новую, common_directories, которая представляет собой список всех каталогов, которые должны присутствовать в каталоге каждого пользователя. Это означает, что (снова возвращаясь к PHP), нам нужно что-то, что работает примерно так:


<?phpforeach ($users_with_items as $user) {  foreach ($common_directories as $directory) {    // Create $directory for $user...  }}

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


Переменные

users_with_items:  - name: "alice"    personal_directories:      - "bob"      - "carol"      - "dan"  - name: "bob"    personal_directories:      - "alice"      - "carol"      - "dan"common_directories:  - ".ssh"  - "loops

TASKS

# Note that this does not set correct permissions on /home/{{ item.x.name }}/.ssh!- name: "Loop 2: create common users' directories using 'with_nested'."  file:    dest: "/home/{{ item.0.name }}/{{ item.1 }}"    owner: "{{ item.0.name }}"    group: "{{ item.0.name }}"    state: directory  with_nested:    - "{{ users_with_items }}"    - "{{ common_directories }}"

Как показано в приведенной выше задаче, к двум спискам в with_nested можно получить доступ, используя item.0 (для users_with_items) и item.1 (для common_directories) соответственно. Это позволяет нам, например, создайте каталог /home/alice/.ssh на самой первой итерации.


РЕЗУЛЬТАТ

/home/ alice/    .ssh/    loops/ bob/     .ssh/     loops/

ЦИКЛ 3: СОЗДАВАЙТЕ ЛИЧНЕ КАТАЛОГИ ПОЛЬЗОВАТЕЛЕЙ, ИСПОЛЬЗУЯ WITH_SUBELEMENTS


Примечание: Для цикла 3 нужны созданные юзеры, например с помощью цикла 1. Иначе будет ошибка chown failed: failed to look up user


В этом примере мы используем другой вид вложенного цикла with_subelements для создания каталогов, перечисленных в переменной users_with_items из цикла 1. В PHP цикл может выглядеть примерно так:


<?phpforeach ($users_with_items as $user) {  foreach ($user['personal_directories'] as $directory) {    // Create $directory for $user...  }}

Обратите внимание, что мы перебираем массив $users_with_items и $user['personal_directories'] для каждого пользователя.


Переменные

users_with_items:  - name: "alice"    personal_directories:      - "bob"      - "carol"      - "dan"  - name: "bob"    personal_directories:      - "alice"      - "carol"      - "dan"

TASKS

- name: "Loop 3: create personal users' directories using 'with_subelements'."  file:    dest: "/home/{{ item.0.name }}/{{ item.1 }}"    owner: "{{ item.0.name }}"    group: "{{ item.0.name }}"    state: directory  with_subelements:    - "{{ users_with_items }}"    - personal_directories

Цикл with_subelements работает почти так же, как with_nested, за исключением того, что вместо второй переменной он принимает переменную и ключ другого списка, содержащегося в этой переменной в данном случае personal_directories. Как и в цикле 2, первая итерация этого цикла создает (или проверяет существование) /home/alice/bob.


РЕЗУЛЬТАТ

/home/ alice/    .ssh/    bob/    carol/    dan/    loops/ bob/     .ssh/     alice/     carol/     dan/     loops/

ЦИКЛ 4: СОЗДАВАЙТЕ ПОЛЬЗОВАТЕЛЕЙ С ИСПОЛЬЗОВАНИЕМ WITH_DICT


Цикл 3 завершил настройку домашних каталогов, принадлежащих alice и bob, но есть еще два выдающихся пользователя, которые нужно создать, carol и dan. В этом примере этих пользователей создаются с помощью новой переменной users_with_dict и цикла Ansible with_dict.


Обратите внимание, что структура данных здесь содержит значимые ключи (dict или dictionary это имя Python для ассоциативного массива); with_dict может быть лучшим вариантом, если вы вынуждены использовать данные с таким типом структуры. Цикл, который мы создаем здесь в Ansible, в PHP примерно такой:


<?phpforeach ($users_with_dict as $user => $properties) {  // Create a user named $user...}

ПЕРЕМЕННЕ

users_with_dict:  carol:    common_directories: "{{ common_directories }}"  dan:    common_directories: "{{ common_directories }}"

TASKS

- name: "Loop 4: create users using 'with_dict'."  user:    name: "{{ item.key }}"  with_dict: "{{ users_with_dict }}"

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


РЕЗУЛЬТАТ

/home/ alice/    .ssh/    bob/    carol/    dan/    loops/ bob/    .ssh/    alice/    carol/    dan/    loops/ carol/ dan/

ЦИКЛ 5: СОЗДАВАЙТЕ ЛИЧНЕ КАТАЛОГИ, ЕСЛИ ОНИ НЕ СУЩЕСТВУЮТ


Поскольку мы не можем легко использовать users_with_dict, нам нужно использовать доступные инструменты Ansible, чтобы сделать это по-другому. Поскольку теперь мы создали необходимых пользователей alice, bob, carol и dan, мы можем повторно использовать цикл with_nested вместе с содержимым каталога /home/. В этом примере используется несколько новых функций, не связанных с циклами, чтобы показать, как циклы могут быть интегрированы в относительно сложные TASKS:


Регистрируемые переменные Ansible


Ansible условные выражения


Jinja2 (переменные)


Jinja2 (фильтры)


ПЕРЕМЕННЕ

common_directories:  - ".ssh"  - "loops"

TASKS

- name: "Get list of extant users."  shell: "find * -type d -prune | sort"  args:    chdir: "/home"  register: "home_directories"  changed_when: false- name: "Loop 5: create personal user directories if they don't exist."  file:    dest: "/home/{{ item.0 }}/{{ item.1 }}"    owner: "{{ item.0 }}"    group: "{{ item.0 }}"    state: directory  with_nested:    - "{{ home_directories.stdout_lines }}"    - "{{ home_directories.stdout_lines | union(common_directories) }}"  when: "'{{ item.0 }}' != '{{ item.1 }}'"

Здесь у нас есть две TASKS: одна использует модуль shell для выполнения команды find на сервере, а другая использует file для создания каталогов.


При выполнении в каталоге /home команда find \ -type d -prune | sort (выполняется модулем shell) вернет только имена каталогов, найденных внутри /home, другими словами, имена всех пользователей, каталоги которых необходимо подготовить.


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


"stdout_lines": [  "alice",  "bob",  "carol",  "dan",],

Вторая задача в этом примере (фактический цикл) почти полностью совпадает с циклом with_nested во втором примере, но следует отметить два отличия:


  1. Вторая строка в разделе with_nested выглядит несколько необычно:

- "{{ home_directories.stdout_lines | union(common_directories) }}"

  1. Есть еще одна строка, начинающаяся с when в конце TASKS:


    when: "'{{ item.0 }}' != '{{ item.1 }}'"
    


Давайте пройдемся по ним по очереди. Нечетная строка под with_nested применяет фильтр Jinja2 к новому списку каталогов из первой TASKS выше (это часть home_directories.stdout_lines). Базовый синтаксис фильтров Jinja:


объект для фильтрации (home_directories.stdout_lines)


применить фильтр (|)


имя фильтра плюс аргументы, если есть (union (common_directories))


Другими словами, мы используем фильтр для объединения home_directories.stdout_lines и переменной common_directories из начала этого примера в единый массив:


item:  - .ssh  - alice  - bob  - carol  - dan  - loops

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


К сожалению, это дало бы нам неверный результат если бы мы полагались только на цикл, мы бы обнаружили, что домашний каталог каждого пользователя будет содержать каталог с тем же именем, что и домашний каталог! (например, /home/alice/alice, /home/bob/bob и т. д.) Вот где появляются условные выражения Ansible when приходят:


when: "'{{ item.0 }}' != '{{ item.1 }}'"

Эта строка не позволяет задаче создать каталог, когда текущий элемент в home_directories.stdout_lines и текущий элемент в нашем объединении home_directories.stdout_lines идентичны (как указано в документации Ansible Loops, при объединении when с with_items (или любой другой оператор цикла), оператор when обрабатывается отдельно для каждого элемента ). В PHP то, что мы делаем во второй задаче, будет выглядеть примерно так:


<?php$users = ['alice', 'bob', 'carol', 'dan'];$common_directories = ['.ssh', 'loops'];$directories = $user + $common_directories;foreach ($users as $user) {  foreach ($directories as $directory) {    if ($directory != $user) {      // Create the directory    }  }}

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


РЕЗУЛЬТАТ

/home/ alice/    .ssh/    bob/    carol/    dan/    loops/ bob/    .ssh/    alice/    carol/    dan/    loops/ carol/    .ssh/    alice/    bob/    dan/    loops/ dan/     .ssh/     alice/     bob/     carol/     loops/

ВВОД


Циклы Ansible довольно странные. Они не только декларативны (как и все остальное в Ansible), но и имеют много разных типов, некоторые из имен которых (with_nested? with_subitems?) Трудно распутать.


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


Надеюсь, этот пост поможет вам избавиться от моего первоначального затруднения. С этой целью я собрал виртуальную машину Vagrant (Vagrant изначально поддерживает использование Ansible для подготовки) и Ansible playbook, который я использовал для создания и тестирования этих примеров). Просто следуйте инструкциям в README, чтобы запустить примеры из этого сообщения или попробовать свои собственные. Если у вас есть какие-либо вопросы или комментарии, напишите нам в Twitter по адресу @chromaticHQ!

Подробнее..

Proxmox Backup Server интеграция с Proxmox VE и базовые операции

16.11.2020 18:23:29 | Автор: admin

В середине июле этого года мы рассказывали о том, что была представлена бета-версия Proxmox Backup Server (PBS). В день холостяков, 11.11.2020 в 11:11, Proxmox Server Solutions GmbH опубликовали релиз версии 1.0.1, что не прошло незамеченным. Взглянем детально, как использовать PBS и для чего он подходит.

Основной упор при создании PBS был сделан на совместимость и удобство работы с Proxmox VE (PVE). Разработчики постарались максимально упростить процесс интеграции и сделать так, чтобы все элементы интерфейса и подход к управлению резервным копированием были интуитивно понятны пользователям PVE.

Прежде всего установим Proxmox Backup Server. С момента выхода beta-версии инсталлятор остался точно таким же.

Доступные варианты файловых систем в инсталляторе

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

Внешний вид веб-интерфейса управления

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

Главное не забыть обновления


Чтобы потом не было мучительно больно получать ошибки вида HTTP Error 404 Not Found: Path '/fixed_index' not found при создании заданий бэкапа, следует озаботиться обновлением серверов PVE и PBS до актуальных версий. Если у вас есть платная подписка на Enterprise-репозиторий, то просто обновляете дистрибутивы командой:

apt update && apt full-upgrade

Если подписки нет ничего страшного. Пропишем в систему no-subscription репозиторий и обновимся с него.

nano /etc/apt/sources.list.d/pve-enterprise.list

Закомментируем строку платного репозитория символом # и добавим следующую строку.

Для Proxmox Backup Server:

deb http://download.proxmox.com/debian/pbs buster pbs-no-subscription

Для Proxmox Virtual Environment:

deb http://download.proxmox.com/debian/pve buster pve-no-subscription

Выходим Ctrl + X и отвечаем y. Теперь можно обновить пакеты вышеуказанной командой и приступить к интеграции PBS.

Добавляем PBS-сервер в Proxmox VE


Перед тем как добавлять сервер резервного копирования в среду виртуализации Proxmox VE, потребуется выполнить ряд предварительных действий непосредственно на сервере Proxmox Backup Server.

Создание пользователей


Управление пользователями в Proxmox Backup Server

Перед тем как переходить к бэкапам, нужно первым делом сконфигурировать доступы. Советуем сразу зайти в Configuration Access Control и создать пользователей для хранилища. Для демонстрации мы изначально создали пользователя test@pbs, которого станем использовать для подключения. Обратите внимание, что при вводе имени пользователя часть '@pbs' обязательна, в противном случае будет выдаваться ошибка о неверно введенных данных.

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

Создание Datastore и указание прав доступа


Управление дисками в Proxmox Backup Server

Заходим в раздел Administration Storage / Disks. Выбираем нужный диск и инициализируем его нажатием кнопки Initialize Disk with GPT. Теперь переходим в раздел Directory Create:Directory и создаем директорию для хранения данных. Здесь указываем имя репозитория и абсолютный путь к созданной директории. Если поставить галочку Add as Datastore, то новый репозиторий сразу будет подключен как сущность для хранения данных.


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

Сохранение отпечатка пальца сервера


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

Заходим в Administration Shell и снимаем отпечаток пальца сервера:

proxmox-backup-manager cert info | grep Fingerprint

Ответом на команду будет строка вида:

Fingerprint (sha256):bb:fb:13:0f:f7:59:df:32:f0:bf:70:38:22:f8:22:93:05:2f:22:80:bc:71:07:cc:8d:1f:6e:f8:0f:da:bf:73

В дальнейшем мы будем использовать этот отпечаток для установки соединения.

Добавление сервера в роли хранилища


Увы, на данный момент нет способа добавить новое хранилище с типом pbs непосредственно из веб-интерфейса Proxmox VE. Так что воспользуемся консолью и проделаем следующие шаги. Добавляем наш Datastore командой:

pvesm add pbs PVE_STORAGE_NAME --server PBS_SERVER_ADDRESS --datastore STORAGE_NAME

Немного разберем, что делает эта команда:

  • pvesm add pbs добавление хранилища (Storage в терминологии PVE);
  • PVE_STORAGE_NAME это имя будет отображаться в веб-интерфейсе PVE и может отличаться от имени хранилища;
  • --server PBS_SERVER_ADDRESS указываем хостнейм или IP-адрес сервера PBS (при необходимости можно указать и другой порт подключения через --port);
  • --datastore STORAGE_NAME тут указываем имя существующего datastore на сервере PBS.

pvesm set PVE_STORAGE_NAME --username test@pbs --password PASSWORD

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

pvesm set PVE_STORAGE_NAME --fingerprint bb:fb:13:0f:f7:59:df:32:f0:bf:70:38:22:f8:22:93:05:2f:22:80:bc:71:07:cc:8d:1f:6e:f8:0f:da:bf:73

Так выглядит правильно подключенное хранилище сервера PBS

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

Бэкап LXC-контейнера


Тестовый контейнер с Ubuntu

Для теста мы из стандартного шаблона создали и запустили контейнер СТ100 с запущенной внутри операционной системой Ubuntu 16.04. Теперь переходим в раздел Backup, выбираем нужный Storage и нажимаем кнопку Backup Now. Выбираем тип резервного копирования (об этом можно детально прочитать в одной из предыдущих статей) и выполняем резервное копирование.

Успешно выполненный бэкап из web-интерфейса PVE

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

Успешно выполненный бэкап из web-интерфейса PBS

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


Сделать бэкап это лишь половина успеха. Гораздо важнее из него восстановиться. Удаляем наш LXC-контейнер с Ubuntu и попробуем выполнить процедуру восстановления. Для этого в веб-интерфейсе PVE переходим на наш Storage в раздел Content и выбираем файл бэкапа.

Выбор опций восстановления

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

Контейнер восстановлен и запущен

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

Бэкап виртуальной машины


Процедура бэкапа полноценной виртуальной машины ничем не отличается от процедуры бэкапа контейнера, разве что времени занимает больше. Мы для теста создали машину с ID 100 и развернули на ней Ubuntu 16.04, после чего выполнили резервное копирование.

Успешно выполненный бэкап виртуальной машины из веб-интерфейса PVE

Со стороны Proxmox Backup Server это выглядело следующим образом:

Успешно выполненный бэкап виртуальной машины из веб-интерфейса PBS

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

Бэкап данных с любого Linux-хоста


Помимо виртуальных машин и контейнеров, заявлено, что Proxmox Backup Server позволяет бэкапить любые Linux-хосты целиком. Проверим это на практике. Будет использован тот же PBS-сервер. Для корректного выполнения нам потребуется на бэкапируемом хосте выполнить ряд дополнительных действий по установке агента под названием proxmox-backup-client. В роли тестовой машины у нас будет компьютер с той же самой Ubuntu 16.04.

Утилиты proxmox-backup-client в репозиториях Ubuntu нет, поэтому для начала добавим 3 репозитория. Два из них нужны для разрешения зависимостей утилиты, а еще один содержит нужный нам клиент:

sudo nano /etc/apt/sources.list

В конец добавляем строки:

deb http://ftp.debian.org/debian buster main contribdeb http://ftp.debian.org/debian buster-updates main contribdeb http://download.proxmox.com/debian/pbs buster pbs-no-subscription

Выходим из редактора Ctrl + X и отвечаем y на вопрос о сохранении данных. Вытягиваем и устанавливаем ключики репозиториев:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 7BF2812E8A6E88E0

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 04EE7237B7D453EC

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com DCC9EFBF77E11517

Обновляем список источников приложений:

sudo apt update

Устанавливаем бэкап-клиент:

sudo apt install proxmox-backup-client

Осталось лишь выполнить бэкап. Для примера мы забэкапим корневую директорию нашей тестовой машины:

sudo proxmox-backup-client backup root.pxar:/ --repository PBS_IP_ADDRESS:DATASTORE_NAME

Успешно выполненный бэкап хоста

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


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

Пример скачивания отдельного файла из бэкапа

Заключение


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

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

Подробнее..

Перевод Как уменьшить количество обращений к DockerHub из инфраструктуры CICD при помощи кэширования образов Docker?

10.11.2020 10:22:20 | Автор: admin


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


24 августа 2020 года Docker объявили об изменениях в условиях обслуживания и переходе к ограничениям в зависимости от потребляемого объема. Эти ограничения скорости загрузки образов контейнера вступили в силу 1 ноября 2020 года. Для анонимных пользователей запросы на включение теперь ограничены сотней на шесть часов. Для авторизованных пользователей лимит составит двести запросов на включение за шесть часов.
Члены международного сообщества DevOps привыкли полагаться на Docker как на неотъемлемую часть процессов CI/CD. Поэтому неудивительно, что клиенты стали обращаться в GitLab за пояснениями, как ограничения скорости Docker повлияют на производственные процессы CI/CD.


Используйте зеркало реестра


Можно использовать функцию Зеркало реестра, чтобы определить количество запросов на включение образов, создаваемых для DockerHub. Когда зеркало настроено и GitLab Runner дает команду Docker включать образы, Docker сначала проверит зеркало. Если конкретный образ включается впервые, то будет установлено соединение с DockerHub. В последующие обращения этот образ будет браться с зеркала вместо DockerHub. Здесь более подробно разобрано, как это работает.


Если вы пользователь или клиент GitLab SaaS


Для общих раннеров на GitLab.com мы применяем зеркало образов DockerHub от Google. Это значит, что новый порядок включения образов не повлияет на задачи CI для общих пользователей GitLab.com. Мы продолжаем следить за влиянием, которые оказывают внесенные Docker изменения.


Если вы самостоятельно размещаете раннеры GitLab


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


Запустите зеркало реестра


Далее следуйте инструкции из документации GitLab:
1.Войдите в систему на выделенном компьютере, на котором будет работать прокси-сервер реестра контейнеров.


2.Проверьте, чтобы на компьютере был установлен Docker Engine.


3.Создайте новый реестр контейнеров:


docker run -d -p 6000:5000 \    -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \     --restart always \     --name registry registry:2

Можно изменить номер порта (6000), чтобы открыть реестр на другом порту. Таким образом сервер запустится с http. Если хотите включить TLS (https), следуйте инструкции из официальной документации.


4.Проверьте IP-адрес сервера:


hostname --ip-address

Желательно выбрать IP-адрес частной сети. Частная сеть обычно самое быстрое решение для внутренней коммуникации между компьютерами одного провайдера (DigitalOcean, AWS, Azure и т.д.). Как правило, трафик частной сети не учитывается в общем трафике.


5.Реестр Docker теперь доступен по MY_REGISTRY_IP:6000


Настройте Docker для использования


В конце надо так настроить dockerd, чтобы он использовал ваше зеркало, когда запускает docker pull.


Docker


Запускаем сервис dockerd руками, добавляя параметр --registry-mirror, либо вносим правки в файл /etc/docker/daemon.json и добавьте ключ и элемент registry-mirrors, чтобы не делать это руками каждый раз при перезапуске сервиса.


{  "registry-mirrors": ["http://registry-mirror.example.com"]}

docker-machine


Обновите файл конфигурации раннера GitLabconfig.toml, чтобы установить engine-registry-mirror в настройках MachineOptions.


Docker-in-Docker для построения образов Docker


В зависимости от конфигурации можно по-разному этого достигнуть. В нашей документации можно найти развернутый список.


Проверьте, что все работает


Убедитесь, что Docker настроен так, чтобы использовать зеркало


Если вы запустите docker info, где dockerd настроен для использования зеркала, на выходе вы должны увидеть следующее:


... Registry Mirrors:  http://registry-mirror.example.com ...

Проверьте каталог реестра


Реестр API Docker может показать вам, какой репозиторий он кешировал локально.
Поскольку мы впервые запустили docker pull node с dockerd, настроенным для использования зеркала, мы можем увидеть его, перечислив репозитории.


curl http://registry-mirror.example.com/v2/_catalog{"repositories":["library/node"]}

Проверьте журналы реестра


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


...time="2020-10-30T14:02:13.488906601Z" level=info msg="response completed" go.version=go1.11.2 http.request.host="192.168.1.79:6000" http.request.id=8e2bfd60-db3f-49a3-a18f-94092aefddf9 http.request.method=GET http.request.remoteaddr="172.17.0.1:57152" http.request.uri="/v2/library/node/blobs/sha256:8c322550c0ed629d78d29d5c56e9f980f1a35b5f5892644848cd35cd5abed9f4" http.request.useragent="docker/19.03.13 go/go1.13.15 git-commit/4484c46d9d kernel/4.19.76-linuxkit os/linux arch/amd64 UpstreamClient(Docker-Client/19.03.13 \(darwin\))" http.response.contenttype="application/octet-stream" http.response.duration=6.344575711s http.response.status=200 http.response.written=34803188172.17.0.1 - - [30/Oct/2020:14:02:07 +0000] "GET /v2/library/node/blobs/sha256:8c322550c0ed629d78d29d5c56e9f980f1a35b5f5892644848cd35cd5abed9f4 HTTP/1.1" 200 34803188 "" "docker/19.03.13 go/go1.13.15 git-commit/4484c46d9d kernel/4.19.76-linuxkit os/linux arch/amd64 UpstreamClient(Docker-Client/19.03.13 \\(darwin\\))"time="2020-10-30T14:02:13.635694443Z" level=info msg="Adding new scheduler entry for library/node@sha256:8c322550c0ed629d78d29d5c56e9f980f1a35b5f5892644848cd35cd5abed9f4 with ttl=167h59m59.999996574s" go.version=go1.11.2 instance.id=f49c8505-e91b-4089-a746-100de0adaa08 service=registry version=v2.7.1172.17.0.1 - - [30/Oct/2020:14:02:25 +0000] "GET /v2/_catalog HTTP/1.1" 200 34 "" "curl/7.64.1"time="2020-10-30T14:02:25.954586396Z" level=info msg="response completed" go.version=go1.11.2 http.request.host="127.0.0.1:6000" http.request.id=f9698414-e22c-4d26-8ef5-c24d0923b18b http.request.method=GET http.request.remoteaddr="172.17.0.1:57186" http.request.uri="/v2/_catalog" http.request.useragent="curl/7.64.1" http.response.contenttype="application/json; charset=utf-8" http.response.duration=1.117686ms http.response.status=200 http.response.written=34

Альтернативы зеркалам DockerHub


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


Существуют различные способы аутентификации с помощью DockerHub на GitLab CI. Они все подробно задокументированы. Ниже несколько примеров:


1.Предоставлена переменная DOCKER_AUTH_CONFIG;


2.Файл config.json, размещенный в директории $HOME/.docker пользователя, запускающего процесс GitLab Runner.


3.Запустите docker login, если вы используете последовательность Docker-in-Docker.


Подводим итог


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


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

Подробнее..

Продвинутые абстракции Kubernetes Job, CronJob

05.11.2020 04:10:16 | Автор: admin


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


Job: сущность для разовых задач


Job (работа, задание) это yaml-манифест, который создаёт под для выполнения разовой задачи. Если запуск задачи завершается с ошибкой, Job перезапускает поды до успешного выполнения или до истечения таймаутов. Когда задача выполнена, Job считается завершённым и больше никогда в кластере не запускается. Job это сущность для разовых задач.


Когда используют Job


При установке и настройке окружения. Например, мы построили CI/CD, который при создании новой ветки автоматически создаёт для неё окружение для тестирования. Появилась ветка в неё пошли коммиты CI/CD создал в кластере отдельный namespace и запустил Job тот, в свою очередь, создал базу данных, налил туда данные, все конфиги сохранил в Secret и ConfigMap. То есть Job подготовил цельное окружение, на котором можно тестировать и отлаживать новую функциональность.


При выкатке helm chart. После развёртывания helm chart с помощью хуков (hook) запускается Job, чтобы проверить, как раскатилось приложение и работает ли оно.


Таймауты, ограничивающие время выполнения Job


Job будет создавать поды до тех пор, пока под не завершится с успешным результатом. Это значит, что если в поде есть ошибка, которая приводит к неуспешному результату (exit code не равен 0), то Job будет пересоздавать этот под до бесконечности. Чтобы ограничить перезапуски, в описании Job есть два таймаута: activeDeadlineSeconds и backoffLimit.


activeDeadlineSeconds это количество секунд, которое отводится всему Job на выполнение. Обратите внимание, это ограничение не для одного пода или одной попытки запуска, а для всего Job.


Например, если указать в Job, что activeDeadlineSeconds равен 200 сек., а наше приложение падает с ошибкой через 5 сек., то Job сделает 40 попыток и только после этого остановится.


backoffLimit это количество попыток. Если указать 2, то Job дважды попробует запустить под и остановится.


Параметр backoffLimit очень важен, потому что, если его не задать, контроллер будет создавать поды бесконечно. А ведь чем больше объектов в кластере, тем больше ресурсов API нужно серверам, и что самое главное: каждый такой под это как минимум два контейнера в остановленном состоянии на узлах кластера. При этом поды в состоянии Completed или Failed не учитываются в ограничении 110 подов на узел, и в итоге, когда на узле будет несколько тысяч контейнеров, докер-демону скорее всего будет очень плохо.


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


Удаление Job


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


В Kubernetes есть специальный TTL Controller, который умеет удалять завершенные Job вместе с подами. Вот только он появился в версии 1.12 и до сих пор находится в статусе alpha, поэтому его необходимо включать с помощью соответствующего feature gate TTLAfterFinished.


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


spec:  ttlSecondsAfterFinished: 100

Манифест


Посмотрим на пример Job-манифеста.


apiVersion: batch/v1kind: Jobmetadata:  name: hellospec:  backoffLimit: 2  activeDeadlineSeconds: 60  template:    spec:      containers:      - name: hello        image: busybox        args:         - /bin/sh        - -c        - date; echo Hello from the Kubernetes cluster      restartPolicy: Never

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


В спецификации указаны таймауты и темплейт пода, который будет запускаться. Опции backoffLimit: 2 и activeDeadlineSeconds: 60 значат, что Job будет пытаться выполнить задачу не более двух раз и в общей сложности не дольше 60 секунд.


template это описание пода, который будет выполнять задачу; в нашем случае запускается простой контейнер busybox, который выводит текущую дату и передаёт привет из Kubernetes.


Практические примеры


kubectl apply -f job.yaml

И посмотрим, что получилось.


k get pod -w

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


Статистику по Job можно посмотреть следующей командой.


kubectl get job

Видим, что завершились все задания, время выполнения 5 секунд.


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


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


Команда для удаления:


kubectl delete job hello

Что будет, если сломать Job


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


Поправим yaml: добавим в темплейт контейнера exit 1. То есть скажем Jobу, чтобы он завершался с кодом завершения 1. Для Kubernetes это будет сигналом о том, что Job завершился неуспешно.


    containers:      - name: hello        image: busybox        args:         - /bin/sh        - -c        - date; echo Hello from the Kubernetes cluster; exit 1      restartPolicy: Never

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



В статистике подов видим, что создано три пода, у каждого статус Error. Из статистики Job следует, что у нас создан один Job и он не завершился.



Если посмотреть описание, то увидим, что было создано три пода, и Job завершился, потому что был достигнут backoffLimit.



Обратите внимание! В yaml лимит равен 2. То есть, если следовать документации, Job должен был остановиться после двух раз, но мы видим три пода. В данном случае после выполнения двух раз значит 3 попытки. Когда мы проделываем то же самое на интенсиве с сотней студентов, то примерно у половины создаётся два пода, а у оставшихся три. Это надо понять и простить.


Проверка ограничения по времени


Сделаем бесконечный цикл и посмотрим, как работает ограничение по времени activeDeadlineSeconds.


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


    containers:      - name: hello        image: busybox        args:         - /bin/sh        - -c        - while true; do date; echo Hello from the Kubernetes cluster; sleep 1; done      restartPolicy: Never

Под запустился.



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


Через 60 секунд под оказывается в статусе Terminating (иногда это происходит через 10 сек).



Вспомним, как в Kubernetes реализована концепция остановки подов. Когда приходит время остановить под, то есть все контейнеры в поде, контейнерам посылается sigterm-сигнал и Kubernetes ждёт определённое время, чтобы приложение внутри контейнера отреагировало на этот сигнал.
В нашем случае приложение это простой bash-скрипт с бесконечным циклом, реагировать на сигнал некому. Kubernetes ждёт время, которое задано в параметре graceful shutdown. По дефолту 30 секунд. То есть если за 30 секунд приложение на sigterm не среагировало, дальше посылается sigkill и процесс с pid 1 внутри контейнера убивается, контейнер останавливается.


Спустя чуть более 100 секунд под удалился. Причем ничего в кластере не осталось, потому что единственный способ остановить что-то в контейнере это послать sigterm и sigkill. После этого приходит garbage collector, который удаляет все поды в статусе Terminating, чтобы они не засоряли кластер.


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



Поле restartPolycy


При проверке backoffLimit поды у нас перезагружались. При этом в манифесте указан параметр restartPolycy: Never. Но когда мы смотрели, как работает опция backoffLimit, поды перезагружались. Здесь нет противоречия: если вы посмотрите на весь yaml-файл, то заметите, что этот параметр относится не к Job, а к спецификации контейнера, который запускается внутри пода.


apiVersion: batch/v1kind: Jobmetadata:  name: hellospec:  backoffLimit: 2  activeDeadlineSeconds: 60  template:    spec:      containers:      - name: hello        image: busybox        args:         - /bin/sh        - -c        - date; echo Hello from the Kubernetes cluster      restartPolicy: Never

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


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


Если вы укажете только backoffLimit, но забудете указать restartPolicy, то Job будет выполняться бесконечно.
Поэтому в Job надо всегда указывать:
  • backoffLimit (количество попыток),
  • activeDeadlineSeconds (общее время),
  • restartPolycy: Never (сказать kubelet, чтобы он никогда не перезапускал контейнер в поде; если контейнер в поде упал, то и сам под считается упавшим, то есть завершённым. Пусть Job-контроллер разбирается, что произошло).

Инструкция по Jobам в документации Kubernetes


CronJob: создание объектов Job по расписанию


Job позволяет выполнить разовые задачи, но на практике постоянно возникает потребность выполнять что-то по расписанию. И вот здесь Kubernetes предлагает CronJob.


CronJob это yaml-манифест, на основании которого по расписанию создаются Jobы, которые в свою очередь создают поды, а те делают полезную работу.


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


В манифесте CronJob указывают расписание и ещё несколько важных параметров.


  • startingDeadlineSeconds,
  • concurrencyPolicy.

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


  • successfulJobsHistoryLimit,
  • failedJobsHistoryLimit.

Посмотрим на манифест CronJob и поговорим о каждом параметре подробнее.


apiVersion: batch/v1beta1kind: CronJobmetadata:  name: hellospec:  schedule: "*/1 * * * *"  concurrencyPolicy: Allow  jobTemplate:    spec:      backoffLimit: 2      activeDeadlineSeconds: 100      template:        spec:          containers:          - name: hello            image: busybox            args:            - /bin/sh            - -c            - date; echo Hello from the Kubernetes cluster          restartPolicy: Never

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


concurrencyPolicy этот параметр отвечает за одновременное выполнение заданий. Бывает трёх видов: Allow, Forbid, Replace.


Allow позволяет подам запускаться. Если за минуту Job не отработал, все равно будет создан ещё один. Одновременно могут выполняться несколько Jobов.


Например, если один Job выполняется 100 сек., а Cron выполняется раз в минуту, то запускается Job, выполняется 61 сек., в это время запускается ещё один Job. В итоге в кластере одновременно работают два Joba, которые выполняют одну и ту же работу. Возникает положительная обратная связь: чем больше Jobов запущено, тем больше нагрузка на кластер, тем медленнее они работают, тем дольше они работают и тем больше одновременных подов запускается в итоге всё застывает под бешеной нагрузкой.


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


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


jobTemplate это шаблон, из которого создаётся объект Job. Ну а всё остальное мы уже видели в манифесте Job.


Применим манифест.


kubectl apply -f cronjob.yaml

Посмотрим, что получилось:


k get cronjobs.batch

Увидим название CronJob, расписание, параметр запуска, количество активных Jobов и сколько времени они работают.



Раздел Suspend временная приостановка CronJob. В данном случае указано значение False. Это значит, что CronJob выполняется. Можно отредактировать манифест и поставить опцию True, и тогда он не будет выполняться, пока мы его снова не запустим.


Active сколько Jobов создано, Last Schedule когда последний раз исполнялся.


Теперь можно посмотреть статистику по Jobам и подам.


kubectl get job

Видно, что создан один Job.


kubectl get pod

Под создан, он выполнил полезную работу.



Что получается: CronJob создал Job, Job создал под, под отработал, завершился всё здорово.


Ещё раз посмотрим на CronJob:



Last Schedule был 19 секунд назад. Если посмотреть на Job, то увидим, что у нас появился следующий Job и следующий под.


Возникает вопрос: а что будет, если CronJob отработает хотя бы пару недель? Неужели у нас в кластере будет столько же Jobов и подов в статусе Completed, сколько в этой паре недель минут?


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


Снова откроем манифест и посмотрим, что было добавлено:


k get cronjobs.batch hello -o yaml



Появились опции failedJobHistorLimit со значением 1 и successfulJobHistoryLimit со значением 3. Они отвечают за количество Jobов, которые остаются одновременно в кластере. То есть CronJob не только создаёт новые Jobы, но и удаляет старые.


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


И на сладкое про startingDeadlineSeconds


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


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


Если параметр startingDeadlineSeconds не указан в манифесте:
CronJob контроллер при создании Job смотрит на время последнего запуска значение LastscheduleTime в status: и считает, сколько времени прошло с последнего запуска. И если это время достаточно велико, а точнее за этот промежуток времени CronJob должен был отработать 100 раз или больше, но у нее этого не получилось:


  • например конкурент полиси стоит форбид, крон запускается раз в минуту, и один из запусков подзавис и работал 2 часа, то есть 120 минут;
  • или у нас один мастер в кластере, который упал на пару часов.

В этом случае происходит нечто странное: CronJob перестает работать, новые Jobы больше не создаются. Сообщение об этом приходит в Events, но хранится там недолго. Для восстановления работы приходится удалять CronJob и создавать его заново.


И еще более странное:
Если установлен параметр startingDeadlineSeconds, то поведение немного меняется. 100 пропущенных запусков должны уложиться в количество секунд, указанных в этом параметре. т. е. если в расписании стоит выполняться раз в минуту, а startingDeadlineSeconds меньше 6000 секунд, тогда CronJob будет работать всегда, но в этом случае при политике Allow возможен одновременный запуск множества Job.


И наконец, любопытный side-эффект:
Если установить опцию startingDeadlineSeconds равной нулю, Jobы вообще перестают создаваться.


Если вы используете опцию startingDeadlineSeconds, указывайте её значение меньше, чем интервал выполнения в расписании, но не ноль.
Применяйте политику Forbid. Например, если было пропущено 5 вызовов и наступило очередное время исполнения, то контроллер не будет 5 раз запускать пропущенные задачи, а создаст только один Job. Это логичное поведение.

Особенность работы CronJob


Цитата из документации Kubernetes:


A cron job creates a job object about once per execution time of its schedule. We say "about" because there are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare, but do not completely prevent them. Therefore, jobs should be idempotent.


Вольный перевод на русский:


CronJob создаёт объект Job примерно один раз на каждое время исполнения по расписанию. Мы говорим примерно, потому что иногда бывают случаи, когда создаются два Jobа одновременно или ни одного. Мы делаем всё, чтобы сделать подобные случаи как можно более редкими, но полностью избежать этого не получается. Следовательно, Jobы должны быть идемпотенты.


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


В общем, используйте CronJob на свой страх и риск.


В качестве альтернативы CronJob можно использовать под, в котором запущен самый обычный crond. Без выкрутасов. Старый добрый cron работает без проблем, и мы всегда знаем, что задачи будут выполнены один раз. Надо только побеспокоиться, чтобы внутри пода с кроном не выполнялись одновременно несколько задач.


Изучить продвинутые абстракции и попрактиковаться в работе с Kubernetes можно с помощью видеокурса Kubernetes База. В октябре 2020 мы обновили курс, подробности здесь.


Автор статьи: Сергей Бондарев практикующий архитектор Southbridge, Certified Kubernetes Administrator, один из разработчиков kubespray с правами на принятие pull request.

Подробнее..

Политики хранения Veeam BampR, бэкапы, цепочки и магнитные ленты

03.11.2020 14:09:04 | Автор: admin
В предыдущей части мы разобрали, как работает политика хранения для заданий первоначального бэкапа и создания его архивной копии. В этой части мы продолжим начатое и рассмотрим хранение на магнитных лентах.

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

При написании этого текста я буду исходить, что читатель ознакомился с режимами работы бэкапа из предыдущей части, а также читал статью про тейпы в Veeam Backup & Replication 9.5 Update 4. Для интересующихся темой могу также порекомендовать статью от наших тестировщиков.

Как и ранее, информация актуальна для версии VBR 10. Если вы используете более старую версию (или более новую...), ожидайте возможные отличия в деталях.




Backup to tape + Стандартный медиа пул


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


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

На содержимое кассет будут влиять настройки Media set и Retention. Медиа сет это последовательная серия кассет, где новая кассета не берется, пока предыдущая не записана полностью. Пока медиа сет открыт, в него могут писать разные задания, причем как Backup to tape, так и File to tape. Когда медиа сет закрывается на кассете, то дозаписать ее уже нельзя, сколько бы на ней ни оставалось свободного места. Можно только переписать ее заново, удалив предыдущее содержимое.



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



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

Второй вариант закрывать предыдущий медиа сет и создавать новый по расписанию (3). Например, можно выставить создание на 0.00 понедельника. Тогда в условном месяце медиа сеты могут выглядеть так:



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



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

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

Опция Export current media set upon job completion закроет медиа сет и переместит использованные кассеты в слот импорта/экспорта. Оттуда их можно взять и перенести в укромное место на хранение.



Следующий интересующий нас шаг визарда называется Retention. Тут возможны такие варианты:

Не сохранять данные вообще (1) это опция для самых отважных, VBR позволяется сразу после сессии взять ту же кассету и перетереть все содержимое. Учтите, что в рамках единой сессии VBR перетирать кассеты не будет. Встречались запросы на такую реализацию: если задание записало кассеты 1, 2 и 3 и места не хватило, то VBR не должен ждать новую кассету, а брать снова первую и писать поверх только что записанного. Ретеншена же нет, а там разберемся! Но это заведет нас в логическую ловушку если скопированный файл исчез с кассеты, но остался на репозитории, мы должны его скопировать снова, перетерев уже следующий, и так далее. Так что всему все-таки должна быть мера, и было решено выставить небольшое ограничение.

Никогда не перезаписывать (3) полная противоположность. Задание само никогда не перепишет кассету. Однако ее можно стереть или пометить как свободную вручную. Если нужна гарантия, что данные нельзя удалить, то используйте кассеты WORM (write once read many) и соответствующие медиа пулы. Там ретеншен вообще нельзя установить, потому что с WORM это не имеет смысла.

Наконец, самый рациональный вариант выставить ретеншен на определенное количество дней (2).



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



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

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

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

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

Схожая проблема имеется и с переписыванием кассеты, содержащей начальную часть цепочки (например, VBK). Это может случиться по ряду причин:
  • Даже если ретеншен тейпового задания не короче исходного, но на кассетах хранится длинная цепь инкрементов, то переписывание старой кассеты с VBK убьет всю остальную цепь.
  • Поскольку тейповые задания можно настроить на использование отдельных медиа пулов для полных бэкапов и инкрементов, есть риск не уследить и выставить нужный ретеншен только для одного из медиа пулов (в таких случаях опять же медиа пул для полных бэкапов лучше от греха подалее выставить на ретеншен подлиннее. Рекомендация от RnD срок хранения данных на кассетах должен быть минимум в два раз дольше срока хранения данных на репозиториях).
  • Наконец, по недосмотру данные с кассеты могут быть уничтожены пользователем вручную.

Рассмотрим, как это выглядит в консоли (пример интерфейса смотрите на скриншоте выше). Когда у кассеты заканчивается ретеншен, ее статус будет показываться как Expired. Это еще ничего не означает, все бэкапы на кассете останутся доступными. Если необходимо, можно даже изменить ретеншен медиа пула и B&R спросит, следует ли применить настройки к текущим кассетам. Отвечаете да и кассета больше не Expired. Но Expired кассета может быть переписана в любой момент, а если это произойдет, то сохраненные на ней бэкапы исчезнут. Может возникнуть такая ситуация:



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

Что касается пользовательских операций с кассетами, тут есть несколько вариантов. Если кассета была отмечена как свободная (mark as free), перемещена в другой пул или же удалена из каталога, то бэкапы исчезнут из консоли. К счастью, такая ситуация обратима достаточно каталогизировать (catalog) кассету. VBR прочтет ее содержимое, найдет файлы и поместит их обратно куда надо. А вот если кассету стерли (erase), то это уже не поможет, так как при этом перетирается заголовок.

Возможна еще одна крайне неприятная ситуация. Если VBR записывает файл на кассету и на ней заканчивается место, то остатки файла будут записаны на следующую. Таким образом, один файл может быть размазан по двум и более кассетам. Естественно, стирание/переписывание даже одной кассеты повреждает файл и делает его бесполезным. В свойствах (properties) кассеты вы увидите следующее:



Наконец, расскажу о редком (к счастью), но тоже встречающимся сценарии. Допустим, сисадмину нужно срочно восстановиться с кассеты, но VBR выдает следующую ошибку: Cannot use tape ХХХХХХХ: unknown media (possibly in use by another application). Инженер техподдержки проверяет бесконечные репорты и логи, из которых следует что после записи бэкапов действий с кассетой не было. Сисадмин гарантирует, что кассета лежала у него под подушкой все это время и никто ее не трогал. Как Виму доказать свою невиновность? С помощью специальной утилиты инженер техподдержки считает с кассеты первые несколько сотен килобайт, в которых хранится заголовок, и откроет файл с помощью hex-редактора. И вместо ожидаемого VEEAM увидит там Symantec или нечто схожее. Ой.

Настройка задания


Создав медиа пул, разберемся с заданиями. Тейповые задания можно настроить копировать только полные бэкапы (VBK) или же как полные, так и инкрементальные (VIB). Копия полного бэкапа включена всегда (нужно только выбрать медиа пул), копия инкрементов включается на шаге Incremental backup (опять же, нужно выбрать тот же либо отдельный медиа пул):



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

Forward incremental


При таком исходном задании цепочка копируется на ленту 1 к 1 (или максимально близко к этому).

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



Из этого принципа есть одно исключение опция Process latest full backup chain only:



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



Forever forward incremental


В первый запуск на ленту записывается вся цепочка VBK и его VIBы (из этого правила есть одно исключение, о нем будет сказано чуть ниже). В последующие копируются только созданные инкрементальные точки. Однако, бесконечно так продолжаться не может: исходное задание держит общее количество точек под контролем путем объединения VBK и VIBов, но для цепочки на ленте такое невозможно. Чтобы не оказаться в ситуации, когда для восстановления нужно будет скопировать с кассет VBK и немыслимое количество инкрементов, был придуман виртуальный полный бэкап. Для его настройки на шаге Media Pool нужно кликнуть по кнопке Schedule



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



Обратите внимание на следующие свойства виртуального бэкапа:
  • Виртуальный VBK создается только для заданий, работающих в бесконечно-инкрементальном режиме. Для других типов исходных заданий эта настройка просто игнорируется.
  • Бэкап можно назначить на день, когда задание не работает вовсе. Это будет отмечено, и в день запуска задание скопирует созданные с последнего запуска инкременты, а также синтезирует пропущенный VBK из прошлого (используя вовсе не машину времени, а инкремент соответствующего дня).
  • Если было пропущено несколько запланированных VBK, то скопируется только последний.

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



  • Уже упомянутая опция Process latest full backup chain only работает и тут. Если ее включить, тейповое задание будет копировать только точки после последнего виртуального VBK. Используя пример выше, разница будет следующей:



  • В начале я сказал, что в первый запуск тейповая джоба перенесет бэкапную цепочку как она есть. Я умолчал про один факт в первый запуск может быть сделан и виртуальный VBK. Дело в том, что расписание виртуального VBK работает и при первой синхронизации если оно попадает на какой-то день в прошлом, то задание попытается синтезировать VBK. Приведу пример: исходное задание успело создать цепочку с VBK в понедельник и VIB со вторника по пятницу. Тейповое задание настроено создавать виртуальный VBK в четверг, опция process latest full backup отключена. В таком случае при первой синхронизации будет скопирована полностью цепочка, а в четверг вместо копии VIB будет синтезирован VBK. Если опция process latest full backup включена, то будет синтезирован только VBK четверга и скопирован VIB пятницы.
  • Существует еще один сценарий, когда задание может начать копировать цепочку заново. Это происходит, если VBK на репозитории становится новее, чем виртуальный VBK на ленте. Возьмем такой пример: виртуальный VBK создается раз в два месяца, а изначальное задание настроено хранить 30 точек и работает ежедневно. Из-за того, что на репозитории старые VIB постоянно объединяются с VBK, через некоторое время полная точка на репозитории станет новее, чем хранящаяся на ленте. Как следствие, VBK и его VIBы будут внепланово скопированы на кассету.

Reverse incremental


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


Backup copy


Без GFS ретеншена такие задания работают в бесконечно-инкрементальном режиме, поэтому бэкап на ленты следует уже рассмотренной схеме. Единственная особенность при использовании классического режима BCJ с интервалом синхронизации (periodic copy/pruning) последняя точка в цепочке считается незавершенной и скопирована быть не может, поэтому тейповое задание всегда будет чуть отставать от исходного. В случае же использования новой немедленной копии и эта разница исчезает.

Backup copy с синтетическим GFS


Синтетический GFS ретеншен особых сложностей не добавляет. По умолчанию тейповое задание будет копировать как основную цепочку, так и GFS точки (это помимо синтезирования виртуальных полных бэкапов). Если столько полных точек на кассетах вам не нужно на помощь снова приходит известная нам опция Process latest full backup chain only. При ее включении GFS точки будут игнорироваться исходя из логики, что создаваемый с задержкой синтетический GFS никак не может считаться latest. Использование немедленной копии описанную схему не меняет.

Backup copy с активным GFS


По внешним признакам BCJ с активным GFS работает в режиме forward incremental: тут есть периодический полный бэкап, а ретеншен применяется удалением старых точек. Но для тейповых заданий оно продолжает быть бесконечно-инкрементальным, поэтому виртуальные полные точки тут будут продолжать создаваться согласно расписанию. Можно их использовать, чтобы дополнительно разделить длинную инкрементальную цепочку (если GFS точки не создаются очень часто). Если этого не требуется, то просто выставьте виртуальный VBK создаваться пореже (планировщик позволяет выставить интервал на 1 раз в год).

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

Включение Process latest full backup chain only в таких условиях ничего не поменяет. Поэтому возьмем другой пример. Пусть тейповое задание работает раз в неделю по воскресеньям, и опция Process latest full backup chain only будет включена. В этом случае ситуация будет следующей:


Backup to tape + GFS медиа пул


Для начала я еще раз напомню о рекомендации прочесть статью про тейпы в VBR 9.5 U4, где объясняется общий принцип работы тейпового GFS. Уже прочли? Тогда поехали.

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


Каждый включенный GFS интервал создает свой медиа сет. На вкладке Advanced можно настроить VBR дозаписывать кассеты (галочка append), что где-то аналогично опции always continue из обычных медиа пулов. Иначе медиа сет будет создаваться для каждой сессии.

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

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

File to tape


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

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

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

Типовые сценарии


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

Сценарий 1


Исходное задание:
Исходное задание работает в инкрементальном режиме с бэкапом каждую ночь и с полным бэкапом в понедельник. Задание настроено хранить 14 точек.

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

Настройки:
Раз тейповое задание должно работать по выходным, пусть оно запускается в воскресенье после того, как будет создан бэкап. Таким образом за сессию оно скопирует VBK и 6 VIB, созданных за прошедшую неделю. Поскольку иметь разный ретеншен для полных и инкрементальных бэкапов не нужно, то можно использовать единый медиа пул. Если у библиотеки есть слот экспорта/импорта, можно воспользоваться опцией export current media set медиа сет будет закрыт, а в понедельник работник просто заберет кассеты из слота. Если такого слота нет, то нужно выставить создание нового медиа сета в настройках пула, а работнику нужно уметь читать, чтобы понять какие кассеты пора забрать. На последней из использованных кассет скорее всего останется свободное место, но что поделаешь. Наконец, ретеншен. Поскольку кассеты не дозаписываются, то можно просто выставить ретеншен на месяц, по прошествии которого кассеты можно загрузить в библиотеку и использовать заново.

Сценарий 2


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

Исходное задание:
Исходное задание работает в бесконечно-инкрементальном режиме с бэкапом каждую ночь. Задание настроено хранить 14 точек.

Задача:
Хранить не меньше месяца бэкапов на кассетах. Кассеты остаются в библиотеке и переписываются после истечения ретеншена.

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

Допустим, это невозможно. Что тогда? Почему бы нам не попробовать использовать GFS медиа пул с дневным медиа сетом? Прежде всего, уясним что тип цепочки на кассетах будет forward incremental, а значит если мы хотим месяц бэкапов на кассетах, то по факту нам нужно держать цепочку длиннее.

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

Сценарий 3


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

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

Настройки:
Раз уж нам нужны только полные бэкапы, то копию инкрементальных бэкапов можно отключить совсем. Для медиа пула настроим создавать медиа сет каждую сессию, а ретеншен выставим на не переписывать кассеты (для гарантии сохранности данных стоило бы использовать WORM, но нам таких не завезли). Осталось настроить само тейповое задание. Эта часть зависит от задания исходного:
  • Исходное задание делает полный бэкап каждый день. Возможно, не самый рациональный вариант, но тут ничего особо думать не надо тейповое задание должно запускаться после исходного каждый день. Оно скопирует VBK этого дня.
  • Исходное задание работает в бесконечно-инкрементальном режиме. Тейповое задание также должно запускаться после исходного (и в рамках одних суток!), но нам также необходимо включить виртуальный полный бэкап на каждый день. Кстати, в десятой версии этот метод может быть самым быстрым при создании виртуального VBK благодаря асинхронному чтению.
  • Исходное задание работает в реверсивно-инкрементальном режиме. Опять же, тейповое задание просто должно работать после исходного. Виртуальный бэкап не требуется, будет скопирован просто последний VBK.
  • Наконец, с Backup copy нам нужно, чтобы исходное задание (исходное-исходное, а не копия) работало каждый день, а BCJ должно работать в режиме немедленной копии, иначе последнюю точку нельзя будет использовать. В остальном настройки должны быть аналогичны как с работой с бесконечно-инкрементальным заданием.

Заключение


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

Я бы хотел поблагодарить своих коллег Loxmatiymamont, lyapkost, polarowl, которые оказали неоценимую помощь на каждом этапе подготовки этой серии.
Подробнее..

Приглашаем на митап Apache Kafka в вопросах и ответах 17 ноября в 1900

12.11.2020 06:13:44 | Автор: admin


17 ноября в 19:00 мск проведем митап по Apache Kafka. Приглашаем экспертов и слушателей.


Ключевые темы:


  • Kafka VS RabbitMQ,
  • Что такое Kafka и чем она не является?
  • Где ее применение обосновано, а где нет?
  • Как правильно эксплуатировать Kafka? Как мониторить?
  • Особенности разработки приложения для работы с Kafka.

Эксперты:



Ведущий:


Марсель Ибраев, СТО Слёрм.


Принимаем заявки на участие от инженеров с успешным опытом Apache Kafka в продакшене.


Что от эксперта НЕ нужно:


  • готовить доклад, презентацию, кейс;
  • раскрывать секретные данные компании.

Чего ждём от эксперта:


  • истории из опыта,
  • желание заявить о себе и компании,
  • большой опыт в настройке Apache Kafka,
  • умение высказывать и аргументировать своё мнение.

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


Регистрация

Подробнее..

Из песочницы Как поменять сертификаты для связки VMware Vcenter Server, Replication Server и Site Recovery Manager

13.11.2020 00:08:03 | Автор: admin
Всем привет!

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

  • VMware Vcenter Server 6.7
  • VMware Replication Server 8.3
  • VMware Site Recovery Manager 8.3

Для этого нам понадобятся:

  • Сертификаты
  • Putty
  • Немного терпения

Подготовка сертификатов, я буду использовать рядовой windows server 2019 с ролью Служба сертификатов Active Directory и openssl v1.1.1h

Скачать можно тут

1. Создание сертификатов


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

Подготовим запросы к центру сертификации.

Я дал имена типа FQDN:

  • Vcenter Server имеет имя vc.home.local и ip 192.168.233.11
  • VMware Replication Server я назвал как vr.home.local и ip 192.168.233.12
  • VMware Site Recovery Manage также srm.home.local и ip 192.168.233.13

Для этих имен будем готовить запросы и закрытые ключи в программе openssl. Для этого изготовим небольшой конфигурационный файл vc.cfg с содержимым. Далее для каждого нового сервера я буду менять содержимое этого файла подставляя имена серверов и ip адреса:

[req]default_bits = 2048distinguished_name = req_distinguished_namereq_extensions = v3_reqprompt = no[req_distinguished_name]countryName = RUstateOrProvinceName = ROlocalityName = RnDorganizationName = HOMEcommonName = vc.home.local (меняем)emailAddress = root@home.local[v3_req]basicConstraints = CA:FALSEkeyUsage = digitalSignature, keyEncipherment, keyAgreementsubjectAltName = @alt_names[alt_names]DNS.1 = vc.home.local (меняем)IP.2 = 192.168.233.11 (меняем)

Далее используем openssl

1.1 Делаем vc.home.local

openssl req -batch -new -newkey rsa:2048 -nodes -keyout vc.home.local.key -out vc.home.local.req -config vc.cfg

1.2 Меняем имена и ip сервера в vc.cfg и выпускаем ключ и запрос для vr.home.local

openssl req -batch -new -newkey rsa:2048 -nodes -keyout vr.home.local.key -out vr.home.local.req -config vc.cfg

1.3 Меняем имена и ip сервера в vc.cfg и выпускаем ключ и запрос для srm.home.local

openssl req -batch -new -newkey rsa:2048 -nodes -keyout srm.home.local.key -out srm.home.local.req -config vc.cfg

1.4 Дополнительно понадобятся сертификаты для служб vcenter (vpxd, vsphere-webclient, vpxd-extension)
делаем их командой:

openssl req -new -newkey rsa:2048 -nodes -keyout vpxd.key -out vpxd.req

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



Генерация ключа и запроса на сертификат


Теперь все запросы и ключи готовы приступим к выдаче сертификата. Переходим в центр выдачи сертификатов. Запускаем консоль Центр сертификации.



Далее нажимаем правой кнопкой мышки (пкм) на корне сервера и выбираем выдать новый запрос.



Выбираем наш файл запроса, с расширением req.

Переходим в меню Запросы в ожидании. Если у вас там пусто, нажмите F5 и обновиться окно. Далее жмем пкм, и выбираем Выдать:



Далее переходим в меню Выданные сертификаты и открываем наш сертификат.



Далее нам нужно сохранить его на диск. Для этого переходим во вкладку Состав и нажимаем кнопку Копировать в файл. Далее появиться визард для сохранения файлы, нам нужно выбрать Base64 и имя файла в данном случае vpxd.crt:



Сохранение сертификата.

Повторяем процедуру выдачи для всех наших сертификатов/

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



И это еще не все для сервера VMware Replication Server и VMware Site Recovery Manager. Нам понадобиться контейнер сертификата и ключа. pfx файл, сделать его очень легко, нам понадобиться закрытый ключи и файл сертификата:

openssl pkcs12 -export -out vr.home.local.pfx -inkey vr.home.local.key -in vr.home.local.crt

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

2. Начнем менять с Vcenter


Для этого мы заходим в раздел администрирования, и переходим в раздел сертификаты. Логинимся администратором.



Раздел для управления сертификатами.

Далее попав в панель управления первым делом добавим корневой сертификат или Trusted Root Certificates. Прокручиваем в самый конец и жмем ADD. Выбираем наш сертификат ca.crt



Add Trusted Root Certificates

Далее меняем текущие сертификаты через пункт меню Replace:



Выбираем сертификаты которые мы создали для vcenter:
Для служб мы выбираем сертификаты служб созданных в пункте 1.4

Для сертификатов __MACHINE_CERT и machine сертификат vc.home.local, созданный в пункте 1.1



Мы заменили все сертификаты, которые нам доступны из панели управления. Если у вас
конфигурация, в которой отсутствую компоненты VMware Replication Server и VMware Site Recovery Manager, то на этом можно поставить точку и после перезагрузки сервера наслаждаться работой VCentre. Если вы используете автономный сервер по выдаче сертификатов, советую делать сертификаты на 10 лет и более. Если вы покупаете то тут смотреть по обстоятельствам.

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

3. Меняем сертификат на сервере VMware Replication Server


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

/usr/bin/enable-sshd.sh

После этого можно подключиться к серверу через putty.

Все root ca сертификаты лежать в контейнере jks по пути /opt/vmware/hms/security/hms-truststore.jks

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

/opt/vmware/hms/bin/hms-configtool -cmd list | grep keystore

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

/usr/java/default/bin/keytool -import -trustcacerts -alias root -file /root/ca.crt -keystore /opt/vmware/hms/security/hms-truststore.jks -storepass тут пароль который мы узнали

Далее на запрос добавления говорим yes. Все, мы успешно добавили наш корневой сертификат.

Заходим в панель управления сервером по адресу vr.home.local:5480

Переходим во вкладку Configuration, поле Upload PKCS12 (*.pfx) file
выбираем наш pfx файл. жмем upload and install



конфигурация vr сервера.

После рестарта веб сервера и логина, пытаемся сохранить конфигурацию кнопкой Save and Restart Service:



И получаем ошибку:

Unhandled exception com.vmware.vim.vmomi.client.exception.SslException: javax.net.ssl.SSLException: Certificate thumbprint mismatch, expected:

Сервер нам говорит что отпечатки сертификатов служб вцентра не совпадают.

Открываем putty и подключаемся к нашему вцентру vc.home.local

Запускаем bash командой shell:



Переходим в каталог:

cd /usr/lib/vmidentity/tools/scripts/

И смотрим состояние данной службы:

./lstool.py list --url https://localhost/lookupservice/sdk --no-check-cert --ep-type com.vmware.cis.cs.identity.sso 2>/dev/null



Если открыть в текстовом редакторе наш сертификат vc.home.local.crt, и сравнить, то окажется что сертификаты разные. Дело в том что веб интерфейс вцентра меняет не все сертификаты.

Копируем содержимое сертификата в фаил /tmp/old.crt, не забываем что содержимое сертификата должно быть между тегов -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----

Должно получиться вот так:



Теперь открываем в текстовом редакторе наш новый сертификат вцентра vc.home.local.crt
и копируем его на vc в фаил /tmp/new.crt

Далее выясняем хэш sha1 файла /tmp/old.crt, он там понадобиться чтобы заменить старые сертификаты на новый.

openssl x509 -in /tmp/old.crt -noout -fingerprint -sha1

Далее запускаем скрипт по замене:

./ls_update_certs.py --url https://vc.home.local/lookupservice/sdk --fingerprint 86:0D:BB:---ВАШ ХЭШ----:C7:0E:D1:3E:17:39 --certfile /tmp/new.crt --user administrator@home.local --password ВашПароль

В конце работы скрипта в отчете будет количество замененных сертификатов.

После этого переходим на vr.home.local:5480 и сохраняем конфигурацию. Если вы сделали все правильно сервер должен успешно сохранить конфигурацию и запустить службу vr сервера.



3. Замена сертификата на VMware Site Recovery Manage


На этом сервере все делается из веб интерфейса в меню Certificate.

Заходим в административную панель srm.home.local:5480

  1. Добавляем наш root ca кнопкой ADD
  2. Меняем текущий сертификат кнопкой CHANGE



На этом мы закончили смену всех сертификатов.

Всем спасибо!
Подробнее..

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

05.11.2020 12:07:06 | Автор: admin
Подняв сервер, можно сразу поставить одну из стандартных ОС, которые предлагает хостер. Но есть и другой вариант загрузить собственный образ ISO и установить из него произвольную ОС и любой софт на свой выбор.



Это реально очень удобно. Мы можем поставить на сервер ParrotOS со всеми утилитами для пентестинга, готовый файл-сервер или любую ОС, даже Android или MacOS. Можно поставить специально подготовленную систему, настроенную именно для наших задач.

Зачем это нужно? Вот несколько примеров.

Установка системы из ISO самый эффективный метод, если для сервера требуется нестандартное программное обеспечение и ОС. Всё-таки не каждому требуется именно типовая установка Nginx/Apache и стандартный набор программ из стека LAMP/LEMP/LEPP. Кому-то сервер нужен для других целей. Здесь много вариантов. Скажем, мы хотим запустить игровой сервер, медиасервер, групповой чат или набор утилит для пентестинга, то есть тестирования веб-сервисов на предмет уязвимостей, чтобы сообщить о них владельцу сервиса и, например, получить положенное вознаграждение по программе bug bounty.

Пентестинг


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

Для пентестинга лучше всего подходят операционные системы вроде Kali Linux и ParrotOS. Соответственно, их удобнее всего устанавливать из образов ISO.

Kali Linux


Kali Linux включает инструменты для следующих задач:

  • Обратная разработка (реверс-инжиниринг). Средства для отладки программ и реверс-инжиниринга исполняемых файлов.
  • Стресс-тестирование. Инструменты для стресс-тестирования сетей и веб-сервисов. По сути это DDoS системы, но не с целью обвалить её, а с благими намеренями выяснить, какую нагрузку система способна выдержать.
  • Взлом оборудования. Инструменты для работы с Android и Arduino.
  • Судебная экспертиза (форензика). Инструменты для цифровой криминалистики. Они позволяют создавать образы дисков, проводить анализ образов памяти и извлекать файлы.

Для упрощения пентестинга в системе есть категория Top 10 Security Tools (Топ-10 инструментов безопасности). В эту категорию входят aircrackng, burp-suite, hydra, john, maltego, metasploit, nmap, sqlmap, wireshark и zaproxy. Это самые известные и эффективные инструменты.

Например, Metasploit фреймворк с огромной коллекцией эксплоитов для всех известных уязвимостей, швейцарский нож пентестера. Nmap идеальная программа для сканирования портов. Wireshark лучший снифер и анализатор сетевого трафика. John the Ripper известный инструмент для брутфорса паролей, и так далее. Всё это поставляется в комплекте Kali Linux, так что ничего не нужно инсталлировать вручную. Всего в комплект входит более 600 предустановленных хакерских приложений. Это удобно. Хотя, в принципе, ничто не мешает установить любые нужные программы в любом другом дистрибутиве Linux.

Свежие образы Kali Linux генерируются каждую неделю и выкладываются на официальной странице.

Как вариант: Parrot OS


Дистрибутив Parrot OS на базе Debian служит той же цели, что и Kali Linux. Это своего рода портативная лаборатория для всех операций, связанных с ИБ, от пентестинга до форензики и стресс-тестирования, но при этом позиционируется также для разработчиков программного обеспечения с упором на безопасность и приватность.

Kali Linux и Parrot OS во многом похожи, но отличаются системными требованиями (320 МБ ОЗУ для Parrot OS, 1 ГБ для Kali Linux), внешним видом (MATE и KDE у Parrot OS против GNOME у Kali Linux) и набором хакерских инструментов. В Parrot OS есть всё то же, что и в Kali Linux, плюс дополнительно собственные инструменты, такие как AnonSurf (удаление всех своих следов из браузера) и Wifiphisher (установка поддельной точки доступа WiFi для обмана окружающих устройств). По производительности Parrot OS тоже выигрывает, особенно на слабой конфигурации, где Kali Linux начинает заметно лагать.

Различные варианты образов ISO и докер-контейнеры с Parrot OS выкладываются здесь.

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

Игровой сервер


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

Например, игра Counter-Strike Global Offensive самый популярный в мире шутер. Есть несколько причин для установки собственного приватного сервера. Здесь вы можете ограничить круг игроков, полностью исключить читеров. И самое главное вы устанавливаете собственные правила игры.

CSGO Server устанавливается на Linux, на Windows 10 или другую систему. Но может быть удобнее сделать ISO, где всё уже установлено, включая SteamCMD, консольный клиент Steam, который является обязательным условием для установки сервера CSGO. Так что если вы всё-таки устанавливаете CSGO сразу на сервер, то сначала нужно поставить SteamCMD. Если подготовить образ ISO со всем необходимым, то в дальнейшем его можно использовать многократно, накатывая на разные серверы.

Некоторые хостеры предлагают уже готовые серверы CS. Их можно арендовать как с оплатой за слоты, так и с оплатой за ресурсы (профессиональные тарифы игровых VDS/VPS).

Или взять Minecraft. Да, это детская игра, но она входит в пятёрку самых популярных онлайн-игр в мире. Для Minecraft-серверов создана специальная MineOS Turnkey, которая распространяется в виде ISO. Хотя всё необходимое программное обеспечение можно установить отдельно на существующий сервер BSD/Linux, но гораздо приятнее сразу накатить систему со всем необходимым. Система изначально сконфигурирована и оптимизирована под эту задачу: здесь есть инструмент администрирования сервера, управление резервными копиями, продвинутые инкрементальные бэкапы игрового мира (резервное копирование rdiff с использованием алгоритма rsync), загрузка пользовательского интерфейса и серверных модов (vanilla, bukkit и др.) одним щелчком мыши.




MineOS

MineOS Turnkey сделана на основе известной системы Turnkey Linux.

Turnkey Linux


Turnkey Linux библиотека готовых системных образов на базе Debian 8 ("Jessie"). Turnkey переводится под ключ, то есть всё включено. В каждый образ изначально интегрированы лучшие компоненты свободного программного обеспечения. В результате получаются безопасные и простые в использовании решения образы ISO для любых нужд, какие только могут понадобиться.


Каталог образов ISO на сайте Turnkey

Debian крупнейший дистрибутив GNU/Linux, в состав которого входит 37 500 пакетов опенсорсных программ. Однако большая часть этих программ малоизвестны, потому что не включены по умолчанию в состав стандартных дистрибутивов. Turnkey ставит своей миссией изменить это.

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

Turnkey это более 100 готовых к использованию образов. Все они поддерживают автоматическое ежедневное обновление с последними патчами безопасности, резервное копирование и восстановление одной кнопкой: система сохраняет изменения в файлах, БД и управлении пакетами в зашифрованном хранилище, из которого серверы могут быть автоматически восстановлены. Инструмент для резервного копирования TKLBAM встроен в ядро системы Turnkey Core.

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

Все образы легковесные (от 150 МБ), тщательно собраны с нуля с минимально необходимым набором компонентов, чтобы обеспечить наиболее эффективное потребление ресурсов, эффективность и безопасность. Во всех релевантных образах SSL работает из коробки на бесплатных сертификатах Let's Encrypt.

Вот некоторые образы из коллекции Turnkey:

  • Стек LAMP (408 МБ VM, 378 МБ ISO). Типичный комплект Linux, Apache, MariaDB (вместо MySQL), PHP/Python/Perl.
  • NGINX PHP FastCGI (404 МБ VM, 373 МБ ISO). Альтернативный стек для веб-сервера.
  • WordPress (425 МБ VM, 392 МБ ISO). Одна из лучших платформ для публикации блога с тысячами доступных плагинов на любой вкус.
  • Ghost (740 МБ VM, 582 МБ ISO). Ещё одна опенсорсная платформа для публикации блогов, с красивым оформлением, простая в использовании и бесплатная, отличается высокой скоростью. Приложение написано на Node.js, клиент администрирования на фреймворке Ember.js, а темы на движке Handlebars.js.


    Ghost
  • ZoneMinder (531 МБ VM, 483 МБ ISO). Система видеонаблюдения для дома, офиса или любого места. Использует лучший софт, совместим с любыми камерами. Подходит для систем любого размера. Продвинутое распознавание движения и объектов в реальном времени (системы EventServer и zmMagik).
  • Файл-сервер (508 МБ VM, 461 МБ ISO). Простой в использовании файл-сервер, совместимое с Windows общее хранилище файлов с веб-менеджером. Полностью готовый файл-сервер поддерживает протоколы передачи файлов SMB, SFTP, NFS, WebDAV и rsync. Возможно как приватное хранилище файлов, так и общедоступное на публичном хостинге. Работает на основе Samba и WebDAV CGI.


    Файл-сервер (File Server)
  • Nextcloud (639 МБ VM, 558 МБ ISO). Хранение файлов, фотогалерей, календаря и многого другого. Сервер доступен с любого устройства через интернет. Тоже можно установить или в локальной сети с доступом через интернет, или на публичном сервере.


    Nexctcloud
  • GitLab (1,1 ГБ VM, 1,0 ГБ ISO). Единый сервер для всего жизненного цикла разработки программного обеспечения. От планирования проекта и управления исходным кодом до CI/CD, мониторинга и безопасности. GitLab предоставляет собой управление версиями на основе Git, упакованное с полным набором инструментов DevOps. По сути, что-то вроде GitHub, но на своём сервере и с более продвинутым функционалом.
  • Медиасервер (648 МБ VM, 587 МБ ISO). Полностью настроенный медиасервер индексирует все ваши домашние видео, музыку и фотографии, затем автоматически транскодирует на лету и транслирует этот контент для воспроизведения на любом устройстве. На сервере работает Jellyfish с веб-приложением для управления файлами, система совместима с Windows и различными протоколами передачи данных, включая SFTP, rsync, NFS и WebDAV. Как и в случае с обычным файл-сервером (см. выше), здесь файлами можно управлять как в приватном, так и в публичном хранилище, то есть транслировать видео для всех желающих в интернете, насколько выдержит аппаратная часть сервера.
  • MySQL (398 МБ VM, 368 МБ ISO). Известная опенсорсная СУБД, которая сейчас принадлежит корпорации Oracle. Это быстрый, стабильный, надёжный, простой в использовании и многопоточный сервер баз данных SQL. Строго говоря, на самом деле на сервере фактически работает MariaDB, типичная замена для MySQL, хотя у неё есть некоторые функции, которые отсутствуют у MySQL, так что можно мигрировать с MySQL на MariaDB, но зачастую невозможно вернуться обратно.
  • Торрент-сервер (607 МБ VM, 549 МБ ISO). Файловый сервер с интегрированным общим доступом к файлам. Файлы добавляются в список загрузки через простой веб-интерфейс, который позволяет удалённо управлять сервером. Особенно полезно для централизации общего доступа к файлам в общей сети. Включает антивирусный сканер.

    Пожалуй, этот образ лучше подходит для установки в локальной сети вместе с медиасервером, чтобы скачивать фильмы и сериалы из торрентов, сохранять их в хранилище и транслировать на все телевизоры, ноутбуки и смартфоны в доме.
  • phpBB (416 МБ VM, 384 МБ ISO). Самое популярное в мире опенсорсное решение для веб-форумов. Основано на модулях. Высокий уровень безопасности, многоязычный интерфейс и продвинутая административная панель с настройками всех функций форума.
  • Zen Cart (416 МБ VM, 384 МБ ISO). Сервер для управления интернет-магазином. Поддержка разных языков и валют.
  • AVideo (672 МБ VM, 616 МБ ISO), бывшее название YouPHPTube. Опенсорсный сервер для видеотрансляций, созданный по образцу YouTube, Vimeo и т. д. С помощью AVideo вы можете поднять собственный сайт с видеороликами, а также транслировать видео в прямом эфире. Среди некоторых функций импорт и кодирование видео с других сайтов непосредственно из интернета, поддержка мобильных устройств через адаптивный гибридное приложение, которое позволяет непосредственно транслировать видео с телефона через сервер на широкую аудиторию.
  • Mattermost (622 МБ VM, 569 МБ ISO). Опенсорсная альтернатива Slack на своём хостинге. Объединяет обмен сообщениями и файлами, работает на ПК и мобильных устройствах, встроенное архивирование и поиск. Mattermost из коробки интегрируется с целым рядом других веб-приложений и расширяется модулями, так что вы можете создавать кастомные функции поверх ядра на Golang/React.


Это лишь несколько примеров специализированных образов ISO из коллекции Turnkey. Загружаете такой образ на свой сервер, устанавливаете систему из него и у вас сразу есть настроенное приложение со всеми необходимыми компонентами.



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

Подробнее..

AMD EPYC GENOA на архитектуре Zen 4 уже в 2022 году и слухи про SMT4

16.11.2020 14:12:10 | Автор: admin
Только-только компания AMD анонсировала пользовательские процессоры линейки Ryzen на своей новой архитектуре Zen 3 и еще готовит соответствующие серверные анонсы, как в сети появилась информация уже о следующем поколении серверных процессоров компании AMD EPYC GENOA на Zen 4.



Речь идет не только о процессорах с комплектацией до 96 ядер, но и о сокетах нового поколения AM5, TR5 (HEDT-платформа), а также SP5 и SP6 (серверная платформа). Также говорится о поддержке PCI-Express 5.0 и памяти DDR5. Пока информация циркулирует в сети на уровне слухов, но учитывая то, как развивается потребительский сегмент AMD, их попытка отвоевать позиции на серверном рынке вопрос времени. Так, EPYC MILAN на Zen 3, согласно инсайдерской информации, будет минимум на 20% производительнее предыдущего поколения процессоров AMD архитектуры Zen 2 ROME.

Возможный путь к лидерству AMD это увеличение числа потоков на ядро. Это момент, который может переломить тренды на серверном рынке. Именно поэтому активно ходят разговоры о внедрении компанией AMD в свои серверные процессоры поколения Zen 4 технологии SMT4. Речь идет об одновременной обработке четырех потоков, вместо ставших стандартом двух потоков на ядро. Стоит отметить, что в процессорах EPYC MILAN технологии SMT4 почти гарантированно не будет.

Если говорить о сокетах, то из слухов становится понятно, что AMD выжала из платформы AM4 все, что смогла: в этом коду компания сделала огромный подарок потребителям, не обновляя сокет под Ryzen 5xxx и обеспечив обратную совместимость новых десктопных процессоров с уже существующим сокетом. Тут можно вспомнить бесконечные изменения сокетов у Intel, коих за последние четыре года вышло как минимум три: LGA 1151, LGA 1151 v2 и LGA 1200.

В 2022 году на смену A4 придет сокет A5 и, хочется надеяться, что он проживет так же долго, как и A4. Также грядут и обновления серверных сокетов: мы перейдем с Socket SP4 и Socket SP4r2 на SP5 и SP6. Скорее всего, обе модели выйдут одновременно и будут подходить для одного и того же поколения EPYC GENOA с той же разницей, что и сокеты SP4 и SP4r2: первые предназначены для однопоточных, а вторые для двухпоточных процессоров линейки EPYC ROME. Если предположить, что AMD все же внедрит SMT4, то SP4 будет работать, соответственно, с однопоточными и двухпоточными процессорами, а SP4r2 с четырехпоточными моделями.

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

Однако в случае процессорного сегмента мы имеем дело с более монолитными системами, которые, чаще всего, заточены на работу с каким-то одним тяжелым программным комплексом. Тут SMT4 может хорошо себя показать, особенно в вычислениях. При этом не не просто теоретические выкладки: SMT4 и даже SMT8 практически древняя система, которой пользовались еще двадцать лет назад. Пик развития многопоточности пришелся на начало 2010-х годов, когда у IBM еще было собственно производство серверов для бизнеса.

Вот спецификации IBM Power S822LC последнего сервера от IBM этой линейки на собственном процессоре IBM POWER8 Core 2014 года выпуска:


С полной документацией по серверу IBM можно ознакомиться вот тут (PDF)

Из таблицы видно, что у POWER8 Core была переменная многопоточность, от режима одно ядро-один поток и до режима восьми потоков на логическое ядро процессора. Официальные частоты POWER8 Core на ядро составляют от 2,5 до 5 ГГц. При этом серверы IBM на POWER8 имели еще и 16 сокетов SMP (симметричная многопроцессорная обработка) что позволяло уже тогда объединять в вычислительный кластер полтора десятка серверов.



Стоит отметить, что серверы IBM были весьма специфичным и узким решением для крупного корпоративного бизнеса и научных вычислений. Собственно, с ростом AWS и Azure, они были выдавлены из этого сегмента и IBM Power S822LC стал последним продуктом компании в этой линейке.

Нужно сказать, что сейчас практически захватившие серверный рынок процессоры от Intel линейки Xeon тоже не работают с режимом SMT4. Если мы говорим о процессорах для науки то есть о монструозных решениях по 32-72 ядер серии Phi, например, об Intel Xeon Phi Processor 7295 с 72 ядрами и стоимостью в ~6200$ на момент релиза, то мы вообще не имеем многопоточности. По официальной спецификации у этого процессора 72 ядра и 72 потока.

Более популярные Intel Xeon E работают в режиме SMT2 два потока на ядро. Это касается практически всех популярных серверных процессоров Intel, выпущенных с 2013 года, начиная с серии E5-V2. Если приводить конкретный пример два потока уже было в крайне популярной рабочей лошадке в лице процессора Intel Xeon E5-2680V2, который активно используется до сих пор.

Если прогнозы и данные инсайдеров подтвердятся, то в ближайшие пять лет нас может ожидать частичный передел серверного рынка. AMD активно развивается в десктопном направлении, сейчас начинает давить на серверный сегмент. Intel планирует анонсы серверных процессоров этой весной, но не факт, что они будут намного мощнее новых MILAN, а тем более и грядущих GENOA. Синие до сих пор испытывают значительные трудности с литографией и не могут толком опуститься ниже техпроцесса в 14 нм, кое-как запустив производство на 10 нм ноутбучных процессоров.



P.S. На правах рекламы хотим предложить специально для читателей Хабра честную скидку в 10% на любые тарифы нашего хостинга intesect.host. Скидка действует во всех дата-центрах. Предложение действительно с 16 по 22 ноября включительно.

Промокод при покупке: habr

Подробнее..

Lenovo ThinkAgile VX VMware vSAN ЦОД в коробке

20.11.2020 16:08:20 | Автор: admin
Еще один тяжеловес сервер VX3520-G, основной задачей которого является графический VDI.

Этот сервер выполнен в 2U корпусе, поддерживает до 2-х процессоров Intel Xeon Scalable 2-го поколения и 3ТБ RAM. На передней панели предусмотрено 16 отсеков для дисков SAS/SATA 2,5 дюйма, 2 БП сзади, 2 или 4 встроенных порта 10 GbE и 6 PCIe слотов, но это все не главное.

Главное в этом сервере это наличие графических адаптеров NVIDIA. Графическая подсистема поддерживает следующие конфигурации:

  • До 2-х адаптеров NVIDIA Tesla M10, M60, MI25, или V340;
  • До 3-х адаптеров NVIDIA Quadro P620 или Tesla P4000, V100;
  • До 4-х адаптеров NVIDIA Tesla T4.

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

Следующий сервер в модельном ряду VX5520. Это сервер в корпусе 2U, который предназначен для работы с большим объемом данных. По начинке он очень похож на предыдущий сервер из модельного ряда, но основное отличие от VX3520-G это то, что сервер VX5520 заточен под объем, а не под графику.




Естественным продолжением модельного ряда являются два сервера, которые также нацелены на высокую производительность это VX7320-N и VX7520.

VX7320-N это одноюнитовый сервер высокой производительности. Так же, как и в предыдущих моделях, поддерживается работа одного или двух процессоров Intel Xeon Scalable 2-го поколения и до 3 ТБ оперативной памяти. В передней панели поддерживается установка 10 NVMe U2 дисков для обеспечения ультравысоких нагрузок. На задней панели, как и в других моделях, предусмотрены отказоустойчивые блоки питания, опциональная LOM-карта для 10-гигабитных портов и 3 PCI-e разъема.




Финальная модель VX-серии VX7520, которая является улучшенной версией VX7320-N с точки зрения дисковой подсистемы.




Этот сервер 2U, выполненный на аналогичной предыдущим серверам платформе, позволяет установить 24 SAS SSD или NVMe диска 2.5 дюйма, тем самым получив максимальную производительность дисковой подсистемы. Как и в других двухюнитовых моделях, в нём предусмотрена LOM-карта для 10-гигабитного Ethernet + 6 PCI-e слотов для дополнительных карт.

С детальными техническими характеристиками всех моделей серверов VX можно ознакомиться по ссылке: https://lenovopress.com/ds0023_RU.pdf

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

  1. Непосредственно сам сервер VX-серии;
  2. Установленные и преднастроенные VMware ESXi и VMware vSAN;
  3. Специализированная поддержка Lenovo ThinkAgile Advantage;
  4. Стандартная гарантийная поддержка Lenovo 3 года с заменой оборудования в рабочее время на следующий рабочий день.

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

В данный компания Lenovo готова предоставить серверы VX-серии в демо-доступ, чтобы заказчики смогли по достоинству оценить все возможности современных гиперконвергентных систем. Записаться на демо можно по ССЛКЕ.

А если вы хотите узнать еще больше о гиперконвергентной платформе Lenovo на базе VMware vSAN, то записывайтесь на наш вебинар 26 ноября 2020 года ЗДЕСЬ.
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru