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

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

Как убрать назойливое предупреждение о сертификате для RDP

02.07.2020 12:23:15 | Автор: admin

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

Все, кто хоть раз пользовался RDP, видели эту надпись.


В руководстве приведены готовые команды для пущего удобства. Скопировал, вставил и заработало.

Так вот, это окно можно в принципе пропустить, если выдать сертификат подписанный сторонним, трастовым центром сертификации. В данном случае, Lets Encrypt.

1. Добавляем А запись




Просто добавляем A запись и вписываем в неё IP адрес сервера. На этом работа с доменом окончена.

2. Качаем WinAcme


Качаем WinAcme с их сайта. Архив лучше всего распаковать туда, куда вы не доберетесь, исполняемые файлы и скрипты вам еще пригодятся в будущем для автоматического обновления сертификата. Лучше всего вытряхнуть архив в C:\WinAcme\.

3. Открываем 80 порт




Авторизация вашего сервера осуществляется по http, поэтому нам нужно открыть 80 порт. Для этого введите в Powershell команду:

New-NetFirewallRule -DisplayName 80-TCP-IN -Direction Inbound -Protocol TCP -Enabled True -LocalPort 80

4. Разрешаем выполнение скриптов


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



Перед запуском WinAcme нам нужно разрешить выполнение двух скриптов. Для этого двойным кликом запустите PSRDSCerts.bat из папки со скриптами.

5. Устанавливаем сертификат




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

C:\Winacme\wacs.exe --target manual --host VASHDOMAIN.RU --certificatestore My --installation script --installationsiteid 1 --script "Scripts\ImportRDListener.ps1" --scriptparameters "{CertThumbprint}"

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

Готово! Вы великолепны и избавились от надоедливой ошибки.

А какие системные ошибки раздражают вас?

Подробнее..

Прокладываем L2 туннели в OpenVPN

03.07.2020 12:17:33 | Автор: admin

Недавно меня попросили разобраться в настройке L2 туннеля для моста между двумя удалёнными локальными сетями, и я был поражён, насколько мало удобных решений мне удалось найти. Раньше я не интересовался этой темой и наивно полагал, что любой адекватный VPN-протокол умеет ловить широковещательные пакеты и пересылать их по обычному L3 туннелю. К сожалению, доступных из коробки универсальных решений нет. Есть несколько протоколов и инструментов для них, большинство из которых работает в очень ограниченных условиях или вовсе объявлено deprecated. Самым приятным вариантом я поделюсь дальше.

Почему именно L2?


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

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

Технологии


Их много, и они все работают со странностями и ограничениями:

  • Например, протокол Layer 2 Tunneling Protocol (L2TP) должен, судя по названию, обеспечивать поддержку OSI L2 и в том числе проброс broadcast'a. Но нет, общепринятая связка L2TP + IPsec не позволяет бриджевать сети на уровне L2!
  • PPTP стал мемом из-за крупных уязвимостей, сейчас кое-как починен, но к L2 уже не имеет отношения.
  • MPLS жутко запутанный промышленный протокол на основе меток. Изучить его сложно, а поднять можно только на специализированном железе или RouterOS (с ограничениями, куда ж без них).
  • PPPoE и феерический PPPoEoE тоже работают, но на проприетарных железках. Режим PPPoE вообще есть на многих роутерах, но как его правильно готовить известно по большей части только на фирменном оборудовании типа Cisco.
  • EoIP должен быть стать тем самым L2VPN made right, но он тоже работает только на микротиках, что существенно сужает круг применения. Как и PPTP, использует GRE, не проходит через NAT.

И тут я с удивлением обнаружил, что настоящий Ethernet Bridging умеет OpenVPN!

Мы часто пользуемся личным или рабочим VPNом, у многих он вообще включён на постоянной основе для обхода блокировок (хотя эта тенденция идёт на спад после снятия блокировки Telegram). В своих рабочих задачах я тоже постоянно пользуюсь удаленными хостами для разработки, и почти всегда использую OpenVPN. Долгое время я не понимал, зачем нужна связка OpenVPN Access Server + OpenVPN Connect на клиенте. Для моих задач мне всегда хватало классической версии с ручной правкой конфигов, и выделенные админки и GUI казались неуместными в стройном тонком клиенте. Но оказалось, что для настройки бриджа интерфейс гораздо удобнее чем простыни конфигов в терминале, хотя и с ним не всё идеально.

Настройка


Дело в том, что Access Server (AS) выходил как платный и довольно дорогой продукт, поэтому в него старательно напихали всевозможных плюшек, лишь бы купили. Таким образом в веб-админке появился подпункт меню, позволяющий выбрать режим сети (L2 bridging/L3 routing), а через какое-то время тихонько был оттуда выпилен по всё той же причине это никому не нужно. Тем не менее, сам функционал бриджинга и соответствующие скрипты не удаляли и их по-прежнему можно настроить.

Установка


Нам потребуется сервер или виртуальная машина. Образ для неё находится на странице загрузки, а мы будем дальше разбирать кейс с установкой на сервер под Ubuntu 18.04:

apt update && apt -y install ca-certificates wget net-tools gnupgwget -qO - https://as-repository.openvpn.net/as-repo-public.gpg | apt-key add -echo "deb http://as-repository.openvpn.net/as/debian bionic main">/etc/apt/sources.list.d/openvpn-as-repo.listapt update && apt -y install openvpn-as

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

+++++++++++++++++++++++++++++++++++++++++++++++Access Server 2.8.4 has been successfully installed in /usr/local/openvpn_asConfiguration log file has been written to /usr/local/openvpn_as/init.logAccess Server Web UIs are available here:Admin  UI: https://185.209.31.165:943/adminClient UI: https://185.209.31.165:943/+++++++++++++++++++++++++++++++++++++++++++++++

Сразу нужно указать пароль для админской учётки:

passwd openvpn

Затем можно открывать админку в браузере (на :943/admin, как указано выше), логиниться под пользователем openvpn с указанным паролем и настраивать сервер.



AS бесплатна для использования двумя пользователями, дальше можно добавлять только за $18/месяц за одного пользователя, так что лучше сразу спроектировать свои процессы под использование туннеля двумя клиентами.

Возвращаем бриджинг


cd /usr/local/openvpn_as/scripts./sacli --key "von.general.osi_layer" --value "2" ConfigPut./sacli start

Если всё прошло успешно, в выведенном json'е будет такое:

{ "errors": {}, "last_restarted": "Thu Jul  2 00:07:37 2020", "service_status": {   "api": "on",   "auth": "on",   "bridge": "on",        ...    }}

В админке статус OSI Layer: 3 (routing/NAT) поменяется на 2 (bridging)

NB: в последних версиях может оставаться информация о L3 при включённом bridge. Почему не разбирался, безопасные в этом плане версии около 2.4

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



После успешного подключения и бриджевания клиентов, будет доступен L2-туннель с TCP/UDP трафиком. Клиенты могут выступать натом для внутренней сети, это всё тоже настраивается в админке.

Подробнее..

Recovery mode Улучшение параметров безопасности SSL-соединения в Zimbra Collaboration Suite Open-Source Edition

26.06.2020 14:09:33 | Автор: admin
Надежность шифрования является одним из наиболее важных показателей при использовании информационных систем для бизнеса, ведь ежедневно они участвуют в передаче огромного количества конфиденциальной информации. Общепринятым средством оценки качества SSL-соединения является независимый тест от Qualys SSL Labs. Поскольку данный тест может запустить кто угодно, для SaaS-провайдеров особенно важно, чтобы оценка в этом тесте была максимальной. О качестве SSL-соединения заботятся не только SaaS-провайдеры, но и обычные предприятия. Для них данный тест является отличной возможностью выявить потенциально уязвимые места и заблаговременно закрыть все лазейки для киберпреступников.

image

В Zimbra OSE допустимо использовать два вида SSL-сертификатов. Первый это самоподписанный сертификат, который автоматически добавляется при установке. Этот сертификат бесплатен и не ограничен по времени использования, а значит идеально подойдет для тестирования Zimbra OSE или ее использования исключительно в рамках внутренней сети. Однако при входе в веб-клиент пользователи будут видеть предупреждение от браузера, что данный сертификат ненадежен, и тест от Qualys SSL Labs ваш сервер однозначно провалит.

Второй это коммерческий SSL-сертификат, подписанный удостоверяющим центром. Такие сертификаты без проблем воспринимается браузерами и обычно используются при коммерческой эксплуатации Zimbra OSE. Сразу после корректной установки коммерческого сертификата Zimbra OSE 8.8.15 показывает оценку A в тесте от Qualys SSL Labs. Это отличный результат, но наша цель достигнуть результата A+.





Для того, чтобы достичь максимальной оценки в тесте от Qualys SSL Labs при использовании Zimbra Collaboration Suite Open-Source Edition необходимо выполнить ряд шагов:

1. Увеличение параметров протокола Диффи-Хеллмана

По умолчанию во всех компонентах Zimbra OSE 8.8.15, которые используют OpenSSL, значение параметров протокола Диффи-Хеллмана составляет 2048 бит. В принципе, этого более чем достаточно для получения оценки А+ в тесте от Qualys SSL Labs. Однако, в том случае, если вы обновляетесь с более старых версий, значение параметров может оказаться ниже. Поэтому рекомендуется после завершения обновления выполнить команду zmdhparam set -new 2048, которая повысит параметры протокола Диффи-Хеллмана до приемлемых 2048 бит, а при желании при помощи этой же команды можно повысить значение параметров до 3072 или 4096 бит, что с одной стороны приведет к увеличению времени генерации, однако с другой стороны положительно скажется на уровне безопасности почтового сервера.

2. Включение рекомендованного списка используемых шифров

По умолчанию Zimbra Collaborataion Suite Open-Source Edition поддерживает широкий спектр сильных и слабых шифров, при помощи которых шифруются данные проходящие по защищенному соединению. Однако использвоание слабых шифров является серьезным минусом при проверке безопасности SSL-соединения. Для того, чтобы этого избежать, необходимо настроить список используемых шифров.

Для этого следует воспользоваться командой zmprov mcf zimbraReverseProxySSLCiphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4'.

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

В том случае, если этот список вас по тем или иным причинам не устраивает, можно удалить из него ряд слабых шифров с помощью команды zmprov mcf +zimbraSSLExcludeCipherSuites. Так, например, команда zmprov mcf +zimbraSSLExcludeCipherSuites TLS_RSA_WITH_RC4_128_MD5 +zimbraSSLExcludeCipherSuites TLS_RSA_WITH_RC4_128_SHA +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_RC4_128_MD5 +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_RC4_128_SHA +zimbraSSLExcludeCipherSuites TLS_ECDHE_RSA_WITH_RC4_128_SHA, которая полностью исключит использование шифров RC4. Так же можно поступить и с шифрами AES и 3DES.

3. Включение HSTS

Включенные механизмы принудительного включения шифрования соединения и восстановления сеанса TLS также являются обязательными условиями для получения высшего балла в тесте от Qualys SSL Labs. Для их включения необходимо ввести команду zmprov mcf +zimbraResponseHeader Strict-Transport-Security: max-age=31536000. Данная команда добавит необходимый заголовок в конфигурацию, а для вступления новых настроек в силу придется перезагрузить Zimbra OSE с помощью команды zmcontrol restart.

Уже на этом этапе тест от Qualys SSL Labs будет демонстрировать оценку A+, однако если вы захотите дополнительно улучшить безопасность вашего сервера, можно предпринять еще ряд мер.



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

zmlocalconfig -e ldap_starttls_supported=1
zmlocalconfig -e zimbra_require_interprocess_security=1
zmlocalconfig -e ldap_starttls_required=true


Для включения принудительного шифрования нужно ввести:

zmprov gs `zmhostname` zimbraReverseProxyMailMode
zmprov ms `zmhostname` zimbraReverseProxyMailMode https

zmprov gs `zmhostname` zimbraMailMode
zmprov ms `zmhostname` zimbraMailMode https

zmprov gs `zmhostname` zimbraReverseProxySSLToUpstreamEnabled
zmprov ms `zmhostname` zimbraReverseProxySSLToUpstreamEnabled TRUE


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



Таким образом, следуя нашим рекомендациям можно не только добиться высочайшей оценки в тесте на безопасность SSL-соединения, но и значительно повысить безопасность работы всей инфраструктуры Zimbra OSE.

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

Check Point SandBlast Agent. Что нового?

30.06.2020 14:13:12 | Автор: admin


Мы уже опубликовали огромное кол-во обучающих материалов по Check Point. Однако, тема защиты рабочих станций с помощью Check Point SandBlast Agent пока освещена крайне плохо. Мы планируем исправиться и в ближайшее время создать обучающие курсы по этому продукту, который является одним из лидеров сегмента EDR несколько лет подряд. А пока, делимся информацией о новых возможностях агента, которые появились в версии E83.10. Спойлер появилась бета версия под LINUX и новая облачная управлялка.

Новые функции


Все улучшения версии E83.10 можно найти в sk166979. Там много значимой информации, но мы лучше пройдемся по новым функциям.

Новый облачный менеджмент портал


Check Point уже долгое время развивает концепт Infinity, где ключевую роль играет централизованное управление через облачный портал portal.checkpoint.com. На текущий момент есть огромное кол-во сервисов, доступных через этот портал:

  • CloudGuard SaaS
  • Smart-1 Cloud
  • Infinity SOC
  • CloudGuard Connect
  • Threat Hunting
  • SandBlast Mobile
  • и многое другое

И вот теперь есть доступ к облачной упралялке SandBlast агентами:



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

URL Filtering


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

  • Security
  • Productivity loss
  • Legal Liability & Regulatory compliance
  • Bandwidth consumption
  • General use

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

  • Аддон для браузера доступен только для Google Chrome. Поддержка других браузеров ожидается в ближайшее время.
  • Функция URL Filtering пока доступна только через облачный менеджмент. Вот так выглядит интерфейс:



Также стоит отметить, что появилась новая функция Anti-Credential Theft Pass-the-Hash attack Protection. Но о ней мы подробно расскажем наверно уже в рамках будущего курса.

Новые платформы для SandBlast Agent


SandBlast теперь нативно поддерживает работу как в persistent VDI, так и в non-persistent. Но важнее другое. Наконец появилась бета версия SandBlast Agent-а для Linux систем. Вот небольшая демонстрация, где за одно показывается интеграция с Check Point Threat Hunting:



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

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

Ключевые улучшения агента


Вот несколько ключевых изменений и улучшений SandBlast Agent-а версии E83.10:

Threat prevention
  • Behavioral Guard now protects against the Pass The Hash technique for credential theft. Credential Dumping is new, as of the previous release.
  • Fixes an issue where Anti-Ransomware does not detect a potential attack when the user is not logged in.
  • Fixes Anti-Ransomware false positives due to user profile deletions.
  • Fixes multiple rare cases of false positives in Anti-Ransomware.
  • Fixes an issue where out of memory errors occur when the log lists a very large number of backups.
  • When you disable Anti-Ransomware, the backup driver no longer operates.
  • Improves performance as Forensics now stores fewer named objects, such as mutexes and events.
  • Improves the performance of Forensics, Behavioral Guard and Threat Hunting with enhancements to our Registry Operation exclusion algorithms that reduce the number of recorded registry operations.
  • Resolves an issue where an Anti-Malware scheduled scan occurs, even if it is not in the policy.
  • Resolves an Anti-Malware icon scaling issue.
  • Resolves a possible issue where the Anti-Malware process crashes as it shuts down.


Data and Access Control
  • Resolves client network issues after a Firewall driver uninstallation failure.
  • Resolves a rare issue where an added Firewall blade gets stuck in the Initializing state.
  • Resolves a possible upgrade issue where the Firewall blade does not start due to a WatchDog failure.
  • Resolves a rare issue where the Firewall policy is Not Set in the client after the policy download from the server.
  • Resolves a possible issue where the Disk Encryption process crashes during shutdown.
  • Resolves a removable media icon blink issue for an encrypted partition when Media Scan is enabled.
  • Improves the work with non-UTF-8 applications. Users can toggle UTF-8 support.
  • Fixes active File Transfer Protocol (FTP) traffic blocks on a standalone VPN client with Firewall.
  • Includes stability and quality fixes. Supports all the features of previous releases.


Installation & Infrastructure
  • Resolves a possible issue where uninstalling the Endpoint removes components that are necessary for other applications.
  • Resolves a possible issue where the uninstall fails after the user turns off Network Protection.
  • Resolves a possible issue where the Endpoint Security Client does not run correctly after an operating system upgrade.
  • Resolves a rare issue where the client uninstall fails with Error 1921: Service Check Point Endpoint Agent (CPDA) could not be stopped.
  • Resolves a rare issue where an upgrade that uses Dynamic Package continuously loops after a download fails to resume.
  • The pre-boot language selection choice is now correct after a language update in Windows.
  • Fixes an incompatibility issue with Sophos Antivirus, which could not install on a machine with Endpoint Security Client on it.
  • Resolves a rare User Interface (UI) issue where a malware resolution is not shown to a user.
  • Resolves a client LogViewer issue, where it only shows log records that match the latest log schema.
  • On the Endpoint Security Client screen, the Overview list now shows Anti-Bot and URL Filtering instead of Anti-Bot.
  • The client User Interface (UI) is no longer shown during manual upgrades.
  • Resolves URL infections report issues in the User Interface (UI) so that the infections records are not permanent in the client and server UIs.
  • Anti-Bot and URL Filtering policy now translates to all supported languages.
  • Improves the performance of the Endpoint Security core driver to reduce CPU consumption.



Вместо заключения


Уверен будет интересна статья про форензику, которую может предоставлять SandBlast Agent. Как уже было упомянуто, мы планируем публикацию новых обучающих материалов, поэтому следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Кроме того, в ближайшее время состоится несколько полезных вебинаров по Check Point:


Успейте зарегистрироваться!
Подробнее..

Перевод Руководство по анализу Sysmon-угроз, часть 1

30.06.2020 16:15:52 | Автор: admin


Эта статья является первой частью серии по анализу Sysmon-угроз. Все остальные части серии:

Часть 1. Знакомство с анализом логов Sysmon (мы тут)
Часть 2. Использование данных из Sysmon событий для выявления угроз
Часть 3. Углубленный анализ Sysmon-угроз с помощью графов

Если вы занимаетесь информационной безопасностью, наверняка вам часто приходится разбираться в происходящих атаках. Если у вас уже намётанный глаз, вы можете поискать нестандартную активность в сырых необработанных логах скажем, PowerShell-скрипт с запущенной командой DownloadString или VBS-скрипт, притворяющийся Word-файлом, просто пролистывая последнюю активность в журнале событий Windows. Но это реально большая головная боль. К счастью, Microsoft создал Sysmon, делающий анализ атак куда более простым.

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

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


Часть 1: Знакомство с анализом логов Sysmon


Что поможет разобраться в сложностях журнала событий? В конечном итоге SIEM. Она производит нормализацию событий и упрощает их последующий анализ. Но нам не обязательно заходить так далеко, по крайне мере первое время. В начале для понимания принципов SIEM достаточно будет попробовать замечательную бесплатную утилиту Sysmon. И с ней на удивление легко работать. Так держать, Microsoft!

Какие есть возможности у Sysmon?


Если кратко полезная и читабельная информация о процессах (см. картинки ниже). Вы обнаружите кучу полезных деталей, которых нет в журнале событий Windows, но самое главное следующие поля:
  • ID процесса (в десятичной форме, а не hex!)
  • ID родительского процесса
  • Командную строку процесса
  • Командную строку родительского процесса
  • Хэш образа файла
  • Имена образов файла

Sysmon устанавливается одновременно и как драйвер устройства, и как служба подробнее здесь. Её ключевым преимуществом является возможность анализа логов из нескольких источников, корреляция информации и вывод результирующих значений в одну папку журнала событий, находящуюся по пути Microsoft -> Windows -> Sysmon -> Operational. В моих собственных расследованиях логов Windows, от которых волосы встают дыбом, мне постоянно приходилось переключаться между, скажем, папкой с логами PowerShell, и папкой Безопасность, пролистывая журналы событий в героический попытке как-то сопоставить значения между ними. Это ни разу не легкая задача, и как я потом понял, лучше было сразу запастись аспирином.

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

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


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

У профессионального ИТ-специалиста с пониманием основ хакинга должна вызвать подозрение командная строка. Использование cmd.exe для последующего запуска другой команды с перенаправлением вывода в файл со странным названием это явно похоже на действия софта по контролю и управлению command-and-control (C2): таким способом создаётся псевдо-шелл с помощью служб WMI.
Теперь давайте взглянем на эквивалент записи из Sysmon, обратив внимание на то, сколько дополнительной информации она нам даёт:

Возможности Sysmon на одном скриншоте: детальная информация о процессе в читабельной форме


Возможности Sysmon на одном скриншоте: детальная информация о процессе в читабельной форме


Вы не только видите командую строку, но и имя файла, путь до исполняемого приложения, что Windows знает об этом (Windows Command Processor), идентификатор родительского процесса, командная строка родителя, запустившего cmd-шелл, а также реальное имя файла родительского процесса. Всё в одном месте, наконец-то!
Из лога Sysmon мы можем сделать вывод, что с высокой долей вероятности эта подозрительная командная строка, которую мы видели в сырых логах, не является результатом нормальной работы сотрудника. Скорее наоборот, она была сгенерирована C2-подобным процессом wmiexec, как я упоминал ранее и была напрямую порождена процессом WMI службы (WmiPrvSe). Теперь у нас есть индикатор того, что удалённый злоумышленник или инсайдер пробует корпоративную инфраструктуру на зуб.

Представляем Get-Sysmonlogs


Конечно замечательно, когда Sysmon располагает логи в одном месте. Но, наверное, было бы ещё лучше, если бы мы могли получить доступ к индивидуальным полям лога программным способом например, через команды PowerShell. В этом случае можно было бы написать небольшой PowerShell-скрипт, который бы автоматизировал поиск потенциальных угроз!
Не у меня первого возникла такая идея. И хорошо, что в некоторых постах форумов и GitHub проектах уже объяснено, как использовать PowerShell для парсинга Sysmon-лога. В моём случае мне хотелось избежать необходимости написания отдельных строк парсинг-скрипта для каждого поля Sysmon. Поэтому я использовал принцип ленивого человека и, как мне кажется, в результате придумал что-то интересное.
Первым важным моментом является возможность команды Get-WinEvent читать Sysmon логи, фильтровать нужные события и выводить результат в PS переменную, как здесь:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}


Если вы захотите самостоятельно проверить работу команды, то через отображение контента в первом элементе массива $events, $events[0].Message, на выходе можно получить серию текстовых строк с очень простым форматом: имя поля Sysmon, двоеточие и затем само значение.

Ура! Вывод Sysmon лога в готовый под JSON формат


Ура! Вывод Sysmon лога в готовый под JSON-формат


Вы думаете о том же, о чём и я? Приложив ещё немного усилий, можно сконвертировать вывод в отформатированную под JSON-строку и затем загрузить её напрямую в PS-объект с помощью мощной команды ConvertFrom-Json .
Я покажу PowerShell-код для конвертации он очень простой в следующей части. А пока что давайте глянем, что может делать моя новая команда под названием get-sysmonlogs, которую я установил как PS-модуль.
Вместо углубления в анализ логов Sysmon через неудобный интерфейс журнала событий, мы можем без усилий искать инкрементальную активность непосредственно из PowerShell-сессии, а также использовать PS-команду where (алиас ?) для сокращения результатов выдачи:

Список cmd-шеллов, запущенных через WMI. Анализ угроз задёшево с помощью нашей собственной команды Get-Sysmonlogs


Список cmd-шеллов, запущенных через WMI. Анализ угроз задёшево с помощью нашей собственной команды Get-Sysmonlogs


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

Sysmon и анализ графов


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

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

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

Перевод Высокопроизводительный TSDB benchmark VictoriaMetrics vs TimescaleDB vs InfluxDB

26.06.2020 12:10:59 | Автор: admin

VictoriaMetrics, TimescaleDB и InfluxDB были сравнены в предыдущей статье по набору данных с миллиардом точек данных, принадлежащих 40K уникальным временным рядам.


Несколько лет назад была эпоха Zabbix. Каждый bare metal сервер имел не более нескольких показателей использование процессора, использование оперативной памяти, использование диска и использование сети. Таким образом метрики с тысяч серверов могут поместиться в 40 тысяч уникальных временных рядов, а Zabbix может использовать MySQL в качестве бэкенда для данных временных рядов :)


В настоящее время один node_exporter с конфигурациями по умолчанию предоставляет более 500 метрик на среднем хосте. Существует множество экспортеров для различных баз данных, веб-серверов, аппаратных систем и т. д. Все они предоставляют множество полезных показателей. Все больше и больше приложений начинают выставлять различные показатели на себя. Существует Kubernetes с кластерами и pod-ами, раскрывающими множество метрик. Это приводит к тому, что серверы выставляют тысячи уникальных метрик на хост. Таким образом, уникальный временной ряд 40K больше не является высокой мощностью. Он становится мейнстримом, который должен быть легко обработан любой современной TSDB на одном сервере.


Что такое большое количество уникальных временных рядов на данный момент? Наверное, 400К или 4М? Или 40м? Давайте сравним современные TSDBs с этими цифрами.


Установка бенчмарка


TSBS это отличный инструмент бенчмаркинга для TSDBs. Он позволяет генерировать произвольное количество метрик, передавая необходимое количество временных рядов, разделенных на 10 флаг -scale (бывший -scale-var). 10 это количество измерений (метрик), генерируемых на каждом хосте, сервере. Следующие наборы данных были созданы с помощью TSBS для бенчмарка:


  • 400K уникальный временной ряд, 60 секунд интервал между точками данных, данные охватывают полные 3 дня, ~1.7B общее количество точек данных.


  • 4M уникальный временной ряд, интервал 600 секунд, данные охватывают полные 3 дня, ~1.7B общее количество точек данных.


  • 40M уникальный временной ряд, интервал 1 час, данные охватывают полные 3 дня, ~2.8 B общее количество точек данных.



Клиент и сервер были запущены на выделенных экземплярах n1-standard-16 в облаке Google. Эти экземпляры имели следующие конфигурации:


  • vCPUs: 16


  • ОЗУ: 60 ГБ


  • Хранение: стандартный жесткий диск емкостью 1 ТБ. Он обеспечивает пропускную способность чтения/записи 120 Мбит/с, 750 операций чтения в секунду и 1,5К операций записи в секунду.



TSDBs были извлечены из официальных образов docker и запущены в docker со следующими конфигурациями:


  • VictoriaMetrics:


    docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics
    

  • Значения InfluxDB (- e необходимы для поддержки высокой мощности. Подробности смотрите в документации):


    docker run -it --rm -p 8086:8086 \-e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 \-e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g \-e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 \-v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb
    

  • TimescaleDB (конфигурация была принята из этого файла):



MEM=`free -m | grep "Mem" | awk {print $7}`let "SHARED=$MEM/4"let "CACHE=2*$MEM/3"let "WORK=($MEM-$SHARED)/30"let "MAINT=$MEM/16"let "WAL=$MEM/16"docker run -it  rm -p 5432:5432 \--shm-size=${SHARED}MB \-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data \timescale/timescaledb:latest-pg10 postgres \-cmax_wal_size=${WAL}MB \-clog_line_prefix="%m [%p]: [%x] %u@%d" \-clogging_collector=off \-csynchronous_commit=off \-cshared_buffers=${SHARED}MB \-ceffective_cache_size=${CACHE}MB \-cwork_mem=${WORK}MB \-cmaintenance_work_mem=${MAINT}MB \-cmax_files_per_process=100

Загрузчик данных был запущен с 16 параллельными потоками.


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


400К уникальных временных рядов


Давайте начнем с простых элементов 400К. Результаты бенчмарка:


  • VictoriaMetrics: 2,6М точек данных в секунду; использование оперативной памяти: 3 ГБ; окончательный размер данных на диске: 965 МБ


  • InfluxDB: 1.2M точек данных в секунду; использование оперативной памяти: 8.5 GB; окончательный размер данных на диске: 1.6 GB


  • Timescale: 849K точек данных в секунду; использование оперативной памяти: 2,5 ГБ; окончательный размер данных на диске: 50 ГБ



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


Ниже приведены графики использования процессора (CPU) для каждого из TSDBs во время бенчмарка:



Выше скриншот: VictoriaMetrics Загрузка CPU при тесте вставки для уникальной метрики 400K.



Выше скриншот: InfluxDB Загрузка CPU при тесте вставки для уникальной метрики 400K.



Выше скриншот: TimescaleDB Загрузка CPU при тесте вставки для уникальной метрики 400K.


VictoriaMetrics использует все доступные vCPUs, в то время как InfluxDB недостаточно использует ~2 из 16 vCPUs.


Timescale использует только 3-4 из 16 vCPUs. Высокие доли iowait и system на TimescaleDB графике временных масштабов указывают на узкое место в подсистеме ввода-вывода (I/O). Давайте посмотрим на графики использования пропускной способности диска:



Выше скриншот: VictoriaMetrics Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.



Выше скриншот: InfluxDB Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.



Выше скриншот: TimescaleDB Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.


VictoriaMetrics записывает данные со скоростью 20 Мбит/с с пиками до 45 Мбит/с. Пики соответствуют большим частичным слияниям в дереве LSM.


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


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


Давайте посмотрим на графики использования ввода-вывода (I/O):



Выше скриншот: VictoriaMetrics Использование ввода-вывода при тесте вставки для 400K уникальных метрик.



Выше скриншот: InfluxDB Использование ввода-вывода при тесте вставки для 400K уникальных метрик.



Выше скриншот: TimescaleDB Использование ввода-вывода при тесте вставки для 400K уникальных метрик.


Теперь ясно, что TimescaleDB достигает предела ввода-вывода, поэтому он не может использовать оставшиеся 12 vCPUs.


4M уникальные временные ряды


4M временные ряды выглядят немного вызывающе. Но наши конкуренты успешно сдают этот экзамен. Результаты бенчмарка:


  • VictoriaMetrics: 2,2М точек данных в секунду; использование оперативной памяти: 6 ГБ; окончательный размер данных на диске: 3 ГБ.


  • InfluxDB: 330К точек данных в секунду; использование оперативной памяти: 20,5 ГБ; окончательный размер данных на диске: 18,4 ГБ.


  • TimescaleDB: 480K точек данных в секунду; использование оперативной памяти: 2,5 ГБ; окончательный размер данных на диске: 52 ГБ.



Производительность InfluxDB упала с 1,2 млн точек данных в секунду для 400К временного ряда до 330 тыс. точек данных в секунду для 4M временного ряда. Это значительная потеря производительности по сравнению с другими конкурентами. Давайте посмотрим на графики использования процессора, чтобы понять первопричину этой потери:



Выше скриншот: VictoriaMetrics Использование CPU при тесте вставки для уникального временного ряда 4M.



Выше скриншот: InfluxDB Использование CPU при тесте вставки для уникального временного ряда 4M.



Выше скриншот: TimescaleDB Использование CPU при тесте вставки для уникального временного ряда 4M.


VictoriaMetrics использует почти всю мощность процессора (CPU). Снижение в конце соответствует оставшимся LSM слияниям после вставки всех данных.


InfluxDB использует только 8 из 16 vCPUs, в то время как TimsecaleDB использует 4 из 16 vCPUs. Что общего у их графиков? Высокая доля iowait, что, опять же, указывает на узкое место ввода-вывода.


TimescaleDB имеет высокую долю system. Полагаем, что высокая мощность привела ко многим системным вызовам или ко многим minor page faults.


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



Выше скриншот: VictoriaMetrics Использование полосы пропускания диска для вставки 4M уникальных метрик.



Выше скриншот: InfluxDB Использование полосы пропускания диска для вставки 4M уникальных метрик.



Выше скриншот: TimescaleDB Использование полосы пропускания диска для вставки 4M уникальных метрик.


VictoriaMetrics достигали предела 120 МБ/с в пик, в то время как средняя скорость записи составляла 40 МБ/с. Вероятно, во время пика было выполнено несколько тяжелых слияний LSM.


InfluxDB снова выжимает среднюю пропускную способность записи 200 МБ/с с пиками до 340 МБ/с на диске с ограничением записи 120 МБ/с :)


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


Давайте посмотрим на графики использования IO:



Выше скриншот: VictoriaMetrics Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.



Выше скриншот: InfluxDB Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.



Выше скриншот: TimescaleDB Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.


Графики использования IO повторяют графики использования полосы пропускания диска InfluxDB ограничен IO, в то время как VictoriaMetrics и TimescaleDB имеют запасные ресурсы ввода-вывода IO.


40М уникальные тайм серии


40М уникальные временные ряды были слишком большими для InfluxDB :(


Результаты бечмарка:


  • VictoriaMetrics: 1,7М точек данных в секунду; использование оперативной памяти: 29 ГБ; использование дискового пространства: 17 ГБ.


  • InfluxDB: не закончил, потому что для этого требовалось более 60 ГБ оперативной памяти.


  • TimescaleDB: 330К точек данных в секунду, использование оперативной памяти: 2,5 ГБ; использование дискового пространства: 84GB.



TimescaleDB показывает исключительно низкое и стабильное использование оперативной памяти 2,5 ГБ столько же, сколько и для уникальных метрик 4M и 400K.


VictoriaMetrics медленно увеличивались со скоростью 100 тысяч точек данных в секунду, пока не были обработаны все 40М метрических имен с метками. Затем он достиг устойчивой скорости вставки 1,5-2,0М точек данных в секунду, так что конечный результат составил 1,7М точек данных в секунду.


Графики для 40М уникальных временных рядов аналогичны графикам для 4М уникальных временных рядов, поэтому давайте их пропустим.


Выводы


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


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


  • Узкое место ввода-вывода действительно существует, особенно в хранилищах без SSD, таких как виртуализированные блочные устройства облачных провайдеров.


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



Загрузите односерверный образ VictoriaMetrics и попробуйте его на своих данных. Соответствующий статический двоичный файл доступен на GitHub.


Подробнее о VictoriaMetrics читайте в этой статье.


Обновление: опубликована статья, сравнивающая производительность вставки VictoriaMetrics с InfluxDB с воспроизводимыми результатами.


Обновление#2: Читайте также статью о вертикальной масштабируемости VictoriaMetrics vs InfluxDB vs TimescaleDB.


Обновление #3: VictoriaMetrics теперь с открытым исходным кодом!


Телеграм чат: https://t.me/VictoriaMetrics_ru1

Подробнее..

Прячем RDP и быстро помогаем пользователям

30.06.2020 10:05:46 | Автор: admin
Дорогой читатель! Нам не терпится познакомить тебя с одной уникальной и полезной возможностью нашей системы управления ИТ инфраструктурой, которая делает трудолюбивых пользователей счастливыми, а лентяев и прогульщиков несчастными. За подробностями приглашаем по кат.

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

Подход Veliam к предоставлению удаленного доступа


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

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

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

Удаленный доступ обычных сотрудников


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

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

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


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

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

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


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

Удаленное подключение пользователя


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

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

Удаленная работа с Veliam доступна пользователям с любым компьютером и доступом в интернет. В ближайшее время мы готовимся выпустить коннектор для операционной системы MacOS. В данный момент он существует только для ОС Windows.

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

Удаленный доступ к серверам


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

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

Удаленное подключение к серверу


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

Удаленное подключение к серверу из заявки


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

Helpdesk система


Рассмотрим отдельно HelpDesk систему, которая вкупе с быстрым удаленным доступом, в том числе к компьютеру из заявки, делает систему Veliam целостным продуктом для управлением всей ИТ инфраструктурой.

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

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


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

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


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


Работа технической поддержки с заявками


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


Внимание! Интересная возможность. Саппорт может сразу же из заявки подключиться к пользователю по VNC, в том случае, если у обоих он установлен в системе. У сотрудника server, у тех. поддержки viewer. Как обычно, соединение происходит через облако Veliam, так что не нужно дополнительно ничего настраивать для сетевой связности.

Прямое подключение из заявки


Помимо этого присутствует типовой набор возможностей классической HelpDesk системы. Заявку можно:

  1. отложить на какой-то срок;
  2. закрыть;
  3. изменить исполнителя;
  4. перенести в другой проект;
  5. написать сообщение пользователю;
  6. приложить файл и т.д.

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

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

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

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

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

Recovery mode От стартапа до тысяч серверов в десятке ЦОД. Как мы гнались за ростом Linux инфраструктуры

03.07.2020 20:16:17 | Автор: admin
Если ваша IT инфраструктура растёт слишком быстро, вы рано или поздно столкнётесь с выбором линейно увеличивать людские ресурсы на её поддержку или начинать автоматизацию. До какого-то момента мы жили в первой парадигме, а потом начался долгий путь к Infrastructure-as-Code.



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

В целом, можно сказать, что наша команда поставляет для компании 2 продукта. Первый это инфраструктура. Почта должна ходить, DNS работать, а контроллеры домена пускать вас на сервера, которые не должны падать. IT ландшафт компании огромен! Это business&mission critical системы, требования по доступности некоторых 99,999. Второй продукт сами сервера, физические и виртуальные. За существующими нужно следить, а новые регулярно поставлять заказчикам из множества подразделений. В этой статье я хочу сделать акцент на том, как мы развивали инфраструктуру, которая отвечает за жизненный цикл серверов.

Начало пути

В начале пути наш стек технологий выглядел так:
ОС CentOS 7
Контроллеры домена FreeIPA
Автоматизация Ansible(+Tower), Cobbler


Всё это располагалось в 3х доменах, размазанных на нескольких ЦОДах. В одном ЦОД офисные системы и тестовые полигоны, в остальных ПРОД.

Создание серверов в какой-то момент выглядело так:



В шаблоне VM CentOS minimal и необходимый минимум вроде корректного /etc/resolv.conf, остальное приезжает через Ansible.

CMDB Excel.

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

Поначалу мы даже пытались делать какой-то configuration management в Cobbler. Но со временем это стало приносить проблемы с переносимостью конфигураций как в другие ЦОД, так и в Ansible код для подготовки VM.

Ansible в то время многие из нас воспринимали как удобное расширение Bash и не скупились на конструкции с использованием shell, sed. В общем Bashsible. Это в итоге приводило к тому, что, если плейбук по какой-либо причине не отрабатывал на сервере, проще было удалить сервер, поправить плейбук и прокатить заново. Никакого версионирования скриптов по сути не было, переносимости конфигураций тоже.

Например, мы захотели изменить какой-то конфиг на всех серверах:

  1. Изменяем конфигурацию на существующих серверах в логическом сегменте/ЦОД. Иногда не за один день требования к доступности и закон больших чисел не позволяет применять все изменения разом. А некоторые изменения потенциально деструктивны и требуют перезапуск чего-либо от служб до самой ОС.
  2. Исправляем в Ansible
  3. Исправляем в Cobbler
  4. Повторяем N раз для каждого логического сегмента/ЦОД

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

  • Рефакторинг ansible кода, конфигурационных файлов
  • Изменение внутренних best practice
  • Изменения по итогам разбора инцидентов/аварий
  • Изменение стандартов безопасности, как внутренних, так и внешних. Например, PCI DSS каждый год дополняется новыми требованиями

Рост инфраструктуры и начало пути

Количество серверов/логических доменов/ЦОД росло, а с ними количество ошибок в конфигурациях. В какой-то момент мы пришли к трём направлениям, в сторону которых нужно развивать configuration management:

  1. Автоматизация. Насколько возможно, нужно избегать человеческого фактора в повторяющихся операциях.
  2. Повторяемость. Управлять инфраструктурой намного проще, когда она предсказуема. Конфигурация серверов и инструментов для их подготовки должна быть везде одинаковой. Это так же важно для продуктовых команд приложение должно гарантированно после тестирования попадать в продуктивную среду, настроенную аналогично тестовой.
  3. Простота и прозрачность внесения изменений в configuration management.

Осталось добавить пару инструментов.

В качестве хранилища кода мы выбрали GitLab CE, не в последнюю очередь за наличие встроенных модулей CI/CD.

Хранилище секретов Hashicorp Vault, в т.ч. за прекрасное API.

Тестирование конфигураций и ansible ролей Molecule+Testinfra. Тесты идут намного быстрее, если подключаете к ansible mitogen. Параллельно мы начали писать собственную CMDB и оркестратор для автоматического деплоя (на картинке над Cobbler), но это уже совсем другая история, о которой в будущем расскажет мой коллега и главный разработчик этих систем.

Наш выбор:

Molecule + Testinfra
Ansible + Tower + AWX
Мир Серверов + DITNET(Собственная разработка)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault




Кстати про ansible роли. Сначала она была одна, после нескольких рефакторингов их стало 17. Категорически рекомендую разбивать монолит на идемпотентные роли, которые можно потом запускать отдельно, дополнительно можно добавить теги. Мы роли разбили по функционалу network, logging, packages, hardware, molecule etc. А вообще, придерживались стратегии ниже. Не настаиваю на том, что это истина в единственной инстанции, но у нас сработало.

  • Копирование серверов из золотого образа зло!

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

    1. Оставьте /etc/sysctl.conf пустым, настройки должны лежать только в /etc/sysctl.d/. Ваш дефолт в один файл, кастом для приложения в другой.
    2. Используйте override файлы для редактирования systemd юнитов.
  • Шаблонизируйте все конфиги и подкладывайте целиком, по возможности никаких sed и его аналогов в плейбуках
  • Рефактория код системы управления конфигурациями:

    1. Разбейте задачи на логические сущности и перепишите монолит на роли
    2. Используйте линтеры! Ansible-lint, yaml-lint, etc
    3. Меняйте подход! Никакого bashsible. Нужно описывать состояние системы
  • Под все Ansible роли нужно написать тесты в molecule и раз в день генерировать отчёты.
  • В нашем случае, после подготовки тестов (которых больше 100) нашлось около 70000 ошибок. Исправляли несколько месяцев.


Наша реализация

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



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

Вариантов создания серверов тоже много. Мы в итоге выбрали кастомные скрипты на питоне. А для CI ansible:

- name: create1.yml - Create a VM from a template  vmware_guest:    hostname: "{{datacenter}}".domain.ru    username: "{{ username_vc }}"    password: "{{ password_vc }}"    validate_certs: no    cluster: "{{cluster}}"    datacenter: "{{datacenter}}"    name: "{{ name }}"    state: poweredon    folder: "/{{folder}}"    template: "{{template}}"    customization:      hostname: "{{ name }}"      domain: domain.ru      dns_servers:        - "{{ ipa1_dns }}"        - "{{ ipa2_dns }}"    networks:      - name: "{{ network }}"        type: static        ip: "{{ip}}"        netmask: "{{netmask}}"        gateway: "{{gateway}}"        wake_on_lan: True        start_connected: True        allow_guest_control: True    wait_for_ip_address: yes    disk:      - size_gb: 1        type: thin        datastore: "{{datastore}}"      - size_gb: 20        type: thin        datastore: "{{datastore}}"

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

  • 17 ansible-ролей для настройки сервера. Каждая из ролей предназначена для решения отдельной логической задачи (логирование, аудит, авторизация пользователей, мониторинг и т.д.).
  • Тестирование ролей. Molecule + TestInfra.
  • Собственная разработка: CMDB + Оркестратор.
  • Время создания сервера ~30 минут, автоматизировано и практически не зависит от очереди задач.
  • Одинаковое состояние/именование инфраструктуры во всех сегментах плейбуки, репозитории, элементы виртуализации.
  • Ежедневная проверка состояния серверов с генерацией отчётов о расхождениях с эталоном.

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

Dell EMC PowerStore коротко о нашей новейшей СХД корпоративного класса

07.07.2020 12:09:02 | Автор: admin
Совсем недавно наша компания представила новый продукт Dell EMC PowerStore. Это универсальная платформа с ориентированным на производительность дизайном, обеспечивающим многомерное масштабирование, постоянное сокращение данных (компрессия и дедупликация) и поддержку носителей нового поколения. PowerStore использует микросервисную архитектуру, передовые технологии хранения и интегрированное машинное обучение.

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




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


  • Современная микросервисная архитектура. Система базируется на контейнерной архитектуре, когда отдельные компоненты ОС выделяются в отдельные микросервисы. Микросервисная архитектура обеспечивает переносимость функций и быстрое внедрение нового функционала. Такая архитектура позволяет быстро адаптировать ранее написанный функционал на новую платформу т.к. микросервисы автономны и не влияют друг на друга, микросервисная архитектура позволяет обеспечить более высокую надежность работы всей системы по сравнению с монолитной архитектурой. Например, обновление микрокода часто затрагивает только отдельные модули, а не всю систему (или ее ядро) и, как следствие, проходит более гладко.
  • Использование передовых технологий хранения данных. Поддержка памяти Storage Class Memory (SCM) Intel Optane и NVMe All-Flash позволяет устранить узкие места в системе и существенно увеличить производительности и сократить время отклика системы.
  • Непрерывное сокращение объема данных на лету. Всегда включенные механизмы компрессии и дедупликации данных, позволяют уменьшить объёмы, занимаемые данными внутри системы и оптимизировать хранение. Это позволяет сократить затраты на приобретение и эксплуатацию системы и повысить эффективность работы.
  • Гибкая масштабируемость решения. Архитектура решений Dell EMC PowerStore поддерживает как вертикальное, так и горизонтальное масштабирование, благодаря чему вы можете эффективно планировать расширение инфраструктуры наращивая ёмкость или вычислительные ресурсы независимо друг от друга.
  • Встроенные механизмы защиты данных. Системы PowerStore обладают широким спектром встроенных механизмов защиты данных от мгновенных снимков и репликации до шифрования данных и интеграции с антивирусными программами. Система также широко интегрируется с внешними решениями, как от Dell Technologies, так и от других производителей.
  • AppsON. Благодаря интегрированному в систему гипервизору VMware ESX заказчики могут запускать пользовательские виртуальные машины непосредственно внутри системы.
  • Интеграция с VMware. PowerStore предназначен для глубокой интеграции с VMware vSphere. Интеграция включает поддержку VAAI и VASA, уведомления о событиях, управление снимками, vVols, а также обнаружение и мониторинг виртуальных машин в PowerStore Manager.
  • Унифицированный доступ к данным. PowerStore обеспечивает хранение данных приложений в различных форматах, от физических и виртуальных томов до контейнеров и традиционных файлов благодаря возможности работы по множеству протоколов блочных, файловых и VMware vSphere Virtual Volumes (vVols). Эта способность обеспечивает высокую гибкость данной системы и позволяет ИТ-отделам упростить и консолидировать инфраструктуру.
  • Простой, современный интерфейс управления. Интерфейс управления системой PowerStore Manager разрабатывался на основе требований наших заказчиков к простоте управления системой. Это web-интерфейс, запускающийся на контроллерах системы PowerStore. Доступен по протоколу HTML5 и не требует установки дополнительных плагинов.
  • Программируемая инфраструктура. Упрощает разработку приложений и сокращает сроки их развёртывания с нескольких дней до нескольких секунд благодаря интеграции с VMware и поддержке ведущих сред управления и оркестрации, включая Kubernetes, Ansible и VMware vRealize Orchestrator.
  • Интеллектуальная автоматизация. Встроенные алгоритмы машинного обучения автоматизируют трудоемкие рабочие процессы: такие как начальное планирование и размещение томов, миграция данных, балансирование нагрузки и устранение проблем
  • Аналитическая информация об инфраструктуре. Программное обеспечение Dell EMC CloudIQ для мониторинга и анализа хранилищ сочетает в себе преимущества машинного обучения и человеческого интеллекта для анализа производительности и ёмкости систем в режиме реального времени, а также хранения исторических данных, чтобы получить единое представление об инфраструктуре Dell EMC. Компания Dell Technologies планирует интегрировать CloudIQ с полным портфелем своих решений для еще более глубокой аналитики.

Платформа представлена двумя типами систем:

  1. PowerStore T выступает в качестве классической СХД.
  2. PowerStore X выступает как гиперконвергентное решение, позволяющее запускать виртуальные машины заказчика, совмещенное с выделенной, классической СХД.

Благодаря интегрированным возможностям VMware ESXi, модели PowerStore X предоставляют возможность размещать приложения с интенсивным вводом-выводом непосредственно внутри системы PowerStore. При использовании встроенных механизмов VMware (vMotion) обеспечивается возможность перемещения приложений между системой хранения PowerStore и внешними решениями. Встроенный гипервизор VMware ESXi запускает приложения заказчиков вместе с операционной системой PowerStore в виде виртуальных машин VMware. Этот инновационный дизайн идеально подходит для приложений с большим объёмом хранилища, обеспечивая дополнительные вычислительные и высокопроизводительные хранилища для существующей среды или любого сценария, в котором плотность, производительность и доступность являются основными факторами.

Явными примерами, когда AppsON идеально решает задачи наших заказчиков, являются:

  • Выделенная инфраструктура для одного приложения. Например, для базы данных, которой требуется выделенный сервер, СХД, а также какая-то дополнительная обвязка, например, для резервного копирования. В этом случае вы можете купить одну единственную систему PowerStore которая закроет все задачи, т.к. само приложение и сервер резервного копирования можно развернуть в рамках узла PowerStore без необходимости в дополнительной инфраструктуре.
  • ROBO (удаленные филиалы и офисы). Многие заказчики сталкиваются с задачей в каком-то виде реплицировать инфраструктуру основного ЦОД на периферию, чтобы обеспечить работу удаленных филиалов своих компаний. Раньше приходилось для этого покупать отдельные сервера, СХД, коммутаторы для их соединения, а также ломать голову на тему того, как защитить инфраструктуру и самое главное данные. Мы предлагаем, как и в предыдущем примере, пойти по пути консолидации инфраструктуры в рамках одного решения Dell EMC PowerStore. Вы получите полностью готовую инфраструктуру в рамках шасси в 2U, состоящую из пары отказоустойчивых серверов, соединенных с высокоскоростной СХД.

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



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

  • Традиционный апгрейд младших моделей до старших позволяет избегать лишних инвестиций на этапе закупки системы: нет необходимости сразу покупать дорогое решение, потенциал которого в полной мере раскроется только через несколько лет. Процедура апгрейда это штатная замена одних контроллеров на другие, она выполняется без остановки доступа к данным.
  • Благодаря правильно выбранной архитектуре систему можно будет модернизировать до нового поколения, что позволит поддерживать её в актуальном состоянии и увеличить срок эксплуатации.
  • Есть способ заложить возможность модернизации системы на этапе закупки. Для этого существует специальная опция Anytime Upgrade, которая позволяет либо актуализировать систему за счёт модернизации её до нового поколения, либо модернизировать систему до более старшей и более производительной модели.

Лицензирование


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

Оптимизация физического объема данных


Dell EMC PowerStore включает несколько методов повышения эффективности хранения данных за счёт сокращения используемого данными физического объёма:

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

Динамические пулы


Dell EMC PowerStore оснащается системой RAID на основе экстентов для обработки сбоев дисков. Большое количество элементов RAID представляет собой единое логическое пространство, формирующее пул, с которым работает конечный пользователь.

Архитектура динамический RAID обеспечивает 5 основных преимуществ:

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



High availability


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

NVMe SCM


Носители хранения данных SCM (Storage Class Memory) это высокопроизводительные энергонезависимые накопители, созданные на основе технологии Intel Optane. Накопители NVMe SCM имеют меньшую задержку и улучшенную производительность по сравнению с другими SSD. NVMe это протокол, который позволяет осуществлять доступ напрямую через шину PCIe. NVMe разработан с учетом низкой задержки высокопроизводительных носителей. Накопители NVMe SCM служат уровнем хранения для PowerStore, используются для пользовательских данных или метаданных. На данный момент доступны объёмы в 375 и 750 ГБ.

NVMе NVRAM


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

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

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



Кластеризация


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



Кластеризация устройств Dell EMC PowerStore даёт много преимуществ.

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

PowerStore Manager


PowerStore Manager предоставляет администраторам СХД простой и интуитивно понятный интерфейс для настройки и управления кластером. Он основан на HTML5, не требует установки дополнительного программного обеспечения на клиенте и помогает выполнить следующие задачи:

  • Начальная настройка нового узла PowerStore.
  • Добавление или удаление узлов из существующего кластера.
  • Управление ресурсами кластера.

мкость кластера является агрегацией ёмкостей отдельных узлов кластера. Статистика по экономии доступна для всего кластера целиком.

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

Вместо заключения


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

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

Капля в море Запуск Drupal в Kubernetes

26.06.2020 20:05:42 | Автор: admin

image


Я работаю в компании Initlab. Мы специализируемся на разработке и поддержке Drupal проектов. У нас есть продукт для быстрого создания Ecommerce решений, основанный на Drupal. В 2019 году мы начали решать задачу построения масштабируемой и отказоустойчивой инфраструктуры для нашего продукта.


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


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


Drupal и Docker


image


Drupal и Docker могут работать вместе и хорошим примером тут служат локальные среды разработки, построенные вокруг Docker, такие как Docksal, Ddev, Lando и DrupalVM. Но локальные среды разработки, в которых кодовая база Drupal в основном монтируется, как том в контейнер Docker, сильно отличаются от рабочей среды, где цель состоит в том, чтобы вместить как можно большую часть кода в stateless контейнер.


В Kubernetes все, или почти все приложения вынуждены работать, как 12-факторное приложение и при развертывании Drupal в Kubernetes необходимо это учитывать.


Что такое 12 Factor Apps?


image


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


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


Но 12-факторное приложение это приложение, которое облегчает развертывание и управление в масштабируемой среде:


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

Условия размещения Drupal в Kubernetes


Чтобы превратить приложение или веб-сайт на Drupal в более безликое 12-факторное приложение, необходимо соблюсти пять главных условий:


  1. База данных должна быть постоянной. Данные должны сохраняться между запусками контейнеров.
  2. Каталог файлов Drupal должен быть постоянным, масштабируемым и общим для всех веб-контейнеров.
  3. Установка Drupal и агрегация CSS и JS должны иметь возможность сохранять данные в каталогах с файлами Drupal-сайта.
  4. Настройки Drupal settings.php и другие важные настройки должны настраиваться установкой значений переменных среды.
  5. Задание cron в Drupal следует запускать через Drush, чтобы иметь возможность запускать его наиболее эффективным и масштабируемым образом.

Выполнение условий размещения Drupal в Kubernetes


1. База данных


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


Управляемый сервис баз данных


Самый простой и наиболее часто применяемый способ использование сервиса управляемых баз данных: AWS RDS Aurora или Cloud SQL в Google Cloud. В этом случае, мы можем подключить свой сайт на Drupal напрямую к управляемой базе данных.


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


Docker образ mysql


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


MySQL Operator


Проект MySQL Operator предназначен для упрощения процесса размещения базы в кластере. Не работает в последних версиях kubernetes, начиная с 1.16. Кроме того, в каждой версии Kubernetes могут вноситься значительные изменения в API, из-за чего проект требуется адаптировать к новым версиям, что разработчики не всегда успевают делать.


Percona XtraDB Cluster Operator


Альтернатива MySQL Operator это решение Percona XtraDB Cluster Operator. Percona XtraDB Cluster объединяет в себе Percona Server для MySQL, работающий с механизмом хранения XtraDB, и Percona XtraBackup с библиотекой Galera, для обеспечения синхронной multi-master репликации.


image


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


Helm chart для MariaDB


Более простым для запуска базы данных в кластере Kubernetes может быть использование Helm chart для MariaDB, которое позволяет развернуть в Kubernetes реплицированный кластер MariaDB. В данном кластере развертывается один master, а остальные slave контейнеры, с которых возможно чтение данных. В отличии от multi-master репликации, при отказе master контейнера будет остановке сервиса, на время запуска нового мастера.


PostgreSQL


Если рассматривать СУБД PostgreSQL, то существует проект Stolon облачный менеджер для обеспечения высокой доступности кластера PostgreSQL.


При деплое баз данных под MySQL или PostgreSQL, в Kubernetes, нужно где-то сохранять файлы с фактическими данных. Наиболее распространенный способ подключить Kubernetes PV (Persistent Volume) к контейнеру MySQL.


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


2. Каталог файлов Drupal


Drupal должен иметь возможность записи в файловую систему внутри кодовой базы в нескольких случаях:


  • Когда во время установки Drupal перезаписывается файл settings.php.
  • Когда во время установки Drupal не проходит предварительную проверку установщика, если каталог сайта (например sites/default) не доступен для записи.
  • Если при создании кеша тем Drupal требуется доступ на запись в каталог публичных файлов, чтобы он мог хранить сгенерированные файлы Twig и PHP.
  • Если используется агрегация CSS и JS, Drupal требуется доступ на запись в каталог публичных файлов, чтобы он мог хранить сгенерированные файлы js и css.

Существует несколько вариантов решения этих задач.


NFS


Самое простое решение всех этих задач, позволяющее Drupal масштабировать и запускать более одного экземпляра Drupal это использовать NFS для папки файлов Drupal (например sites/default/files). Однако легче не значит лучше. У NFS есть свои особенности:


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

Облачное хранилище совместимое с S3


Можно использовать сервис хранения типа Amazon S3 в качестве общедоступной файловой системы для своего Drupal сайта, что снизит затраты на поддержку хранилища и повысит его надежность. Для интеграции S3 хранилища с drupal можно использовать, например, модуль S3FS.


Распределенные файловые системы


Также можно использовать распределенные файловые системы, такие как Gluster или Ceph. Однако тут увеличивается сложность поддержки таких решений, которые можно решить в Kubernetes с помощью проекта rook.


Проект Rook


image


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


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


Rook управляет несколькими решениями для хранения, предоставляя общую платформу для всех из них. Rook гарантирует, что все они будут хорошо работать в Kubernetes:


  • Ceph
  • EdgeFS
  • CockroachDB
  • Cassandra
  • NFS
  • Yugabyte DB

3. Установка Drupal


image


Сделать файл settings.php доступным для записи во время установки более сложная задача, особенно если вам нужно установить Drupal, а затем развернуть новый образ контейнера ( что произойдет со всеми записанными значениями settings.php? Они будут удалены при перезапуске контейнера! ). Поэтому решение данной задачи получило отдельный пункт описания особенностей запуска Drupal в Kubernetes.


Пользователи могут устанавливать Drupal через веб-интерфейс мастера установки или автоматически через Drush. В любом случае Drupal во время установки, если еще не установлены все правильные переменные в settings.php, добавляет некоторые дополнительные конфигурации к файлу sites/default/settings.php или создает этот файл, если его не существует.


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


// Config sync directory.$config_directories['sync'] = '../config/sync';// Hash salt.$settings['hash_salt'] = getenv('DRUPAL_HASH_SALT');// Disallow access to update.php by anonymous users.$settings['update_free_access'] = FALSE;// Other helpful settings.$settings['container_yamls'][] = $app_root . '/' . $site_path . '/services.yml';// Database connection.$databases['default']['default'] = [  'database' => getenv('DRUPAL_DATABASE_NAME'),  'username' => getenv('DRUPAL_DATABASE_USERNAME'),  'password' => getenv('DRUPAL_DATABASE_PASSWORD'),  'prefix' => '',  'host' => getenv('DRUPAL_DATABASE_HOST'),  'port' => getenv('DRUPAL_DATABASE_PORT'),  'namespace' => 'Drupal\Core\Database\Driver\mysql',  'driver' => 'mysql',]

В данном примере используются переменные окружения (например: DRUPAL_HASH_SALT) с функцией PHP getenv() вместо "жестко" заданных значений в файле. Это позволяет контролировать настройки, которые Drupal использует как при установки, так и для новых контейнеров, которые запускаются после установки Drupal.


В файле Docker Compose, чтобы передать переменные, указываются директива environment для контейнера web/Drupal следующим образом:


services:  drupal:    image: drupal:latest    container_name: drupal    environment:    DRUPAL_DATABASE_HOST: 'mysql'    [...]    DRUPAL_HASH_SALT: 'fe918c992fb1bcfa01f32303c8b21f3d0a0'

А в Kubernetes, когда создаете Drupal Deployment, передать переменные среды можно с помощью envFrom и ConfigMap (предпочтительно), также можно напрямую передавать переменные среды в спецификации контейнера:


---apiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: drupal  [...]spec:  template:    [...]    spec:    containers:        - image: {{ drupal_docker_image }}        name: drupal        envFrom:        - configMapRef:            name: drupal-config        env:            - name: DRUPAL_DATABASE_PASSWORD            valueFrom:                secretKeyRef:                name: mysql-pass                key: drupal-mysql-pass

Приведенный выше фрагмент манифеста предполагает, что уже в kubernetes есть ConfigMap с именем drupal-config содержащей все DRUPAL_* переменные, кроме пароля к базе данных, а также секрет, названный mysql-pass, с паролем в ключе drupal-mysql-pass.


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


4. Конфигурация Drupal, управляемая средой


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


5. Выполнение заданий Cron Drupal в Kubernetes


image


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


Внутри Kubernetes не нужно настраивать crontab ни на один из узлов Kubernetes, работающих с сайтами Drupal. И хотя может быть внешняя система, например Jenkins, запускающая задания cron на Drupal сайте, гораздо проще просто запускать Cron Drupal как Kubernetes CronJob, в идеале в том же пространстве имен Kubernetes, что и Drupal.


Самый надежный способ запуска Drupal cron через Drush, но запуск отдельного контейнера Drush через CronJob означает, что CronJob должен запланировать сложный контейнер, работающий как минимум на PHP и Drush. Поды CronJob должны быть максимально легкими, чтобы их можно было планировать на любом системном узле и запускать очень быстро (даже если ваш контейнер Drupal еще не был загружен на этот конкретный узел Kubernetes).


Cron Drupal поддерживает запуск путем посещения URL-адреса, и это самый простой вариант для работы с Kubernetes. Пример настройки CronJob:


---apiVersion: batch/v1beta1kind: CronJobmetadata:  name: drupal-cron  namespace: my-drupal-sitespec:  schedule: "*/1 * * * *"  concurrencyPolicy: Forbid  jobTemplate:    spec:    template:        spec:        containers:        - name: drupal-cron            image: byrnedo/alpine-curl:0.1            args:            - -s            - http://www.my-drupal-site.com/cron/cron-url-token        restartPolicy: OnFailure

URL drupal_cron_url зависит от сайта и можно его найти, посетив страницу /admin/config/system/cron. Убедитесь, что в настройках cron для Run cron every установлено значение Never, чтобы cron запускался только через CronJob Kubernetes.


Можно использовать byrnedo/alpine-curl образ докера, который является чрезвычайно легким всего 5 или 6 МБ так как он основан на Alpine Linux. Большинство других контейнеров, которые есть на базе Ubuntu или Debian, имеют размер, по крайней мере, 30-40 МБ (так что они будут использовать гораздо больше времени, чтобы загрузить первый раз, когда CronJob запускается на новом узле).


Заключение


Мы рассмотрели особенности размещения Drupal проектов в Kubernetes. В продолжении этой статьи детально рассмотрим как мы запустили наш продукт в кластере Kubernetes.

Подробнее..

Перевод Остановитесь!!! Вам не нужны микросервисы

29.06.2020 04:15:17 | Автор: admin

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


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


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


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

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


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


Честно говоря, широкие возможности модульной разработки были где-то далеко от меня, и я просто добавил дополнительный уровень сложности, будучи невежественным разработчиком, скрывавшимся от DevOps. Спустя пять лет я уже работаю с совершенно новым продуктом и другими людьми. У меня куча проблем, возникших из-за плохо разработанных микросервисов, приправленных тактикой девопсов-любителей (девляпсов?, прим. переводчика). Пелена довольно скоро спала, обнажив хрупкость микросервисов. Также я начал смотреть на всю эту архитектуру более опытным взглядом. Было поздно, но лучше поздно, чем никогда.


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


Ваше приложение достаточно большое, чтобы дробить его на микросервисы?


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



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


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


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


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



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


Есть ли транзакции, распределенные между сервисами?


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


Cервисы REST не имеют состояния по определению, а также не должны участвовать в транзакциях, которые проходят по нескольким сервисам. В мире высокой производительности двухфазный коммит (2PC) ненужное зло. Шаблон SAGA добавляет еще один уровень сложности, к которому вы не будете готовы.


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

Возможно ли иметь распределенные по сервисам транзакции?


Да, конечно.


Стоит ли делать цепочку действий поверх сервисов без состояния (stateless)?


Возможно, не стоит!!


Есть ли нужда в частом общении между сервисами?


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


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


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


Кое-что ещё


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

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

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


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


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


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


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


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


  • Устаревшая кодовая база давайте будем честными. Для большинства из нас работа с устаревшей кодовой базой это повседневная деятельность. Это хлеб с маслом большинства организаций. Быстро меняющиеся технологические достижения ставят нас впереди всех, но и в то же время они изолируют нас от устаревшей кодовой базы. Вы уверены, что только что разработанный фреймворк, использующий RabbitMQ, хорошо работает с устаревшим приложением, работающим на AIX?


  • Устранение неполадок каждый сервис будет иметь свой собственный набор файлов журналов для анализа. Больше сервисов = больше файлов.



Заключение


Я здесь, чтобы сказать "Не используйте микросервисы"?


Конечно же, нет!!


Микросервисы заслужили известность. Они решили проблемы, которые считались неразрешимыми. История Netflix по применению микросервисов вдохновила многих. И список определенно не останавливается на Netflix. Uber, SoundCloud и гигантский Amazon вот некоторые примеры, которые у всех на слуху. И не думайте, что истории успеха ограничиваются только потребительскими приложениями. Я имел непосредственный опыт работы с американским гигантом здравоохранения и был очарован возможностями дизайна, каждый раз, когда открывал исходный код.


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


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


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

Подробнее..

Публичная и приватная сеть в Windows 10

27.06.2020 14:19:52 | Автор: admin
Публичная и приватная сеть в Windows 10

Цель публикации: Показать как поменять публичную сеть на приватную и наоборот в Windows 10. Для чего это нужно? В зависимости от того какой тип сети у вас установлен применяются различные правила брандмауэра.

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

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

Для начала вам нужно установить разрешения для изменения типа сети.

1. Выберите кнопку поиск в Windows и наберите secpol.msc
2. Щелкните правой кнопкой мышки на наибольшем соответствии
3. Выберите пункт Запуск от имени администратора



4. Выберите пункт меню действие действие и показать все сети

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

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

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

Выберите параметры/сеть и интернет/настройка параметров адаптера.
Здесь вы можете выбрать нужный вам адаптер, щелкнуть на нем правой кнопкой мышки и выбрать пункт переименовать.

Другой способ задания параметров сети использование Power Shell.

1. Начните набирать в поиске Windows: Power Shell
2. Выберите пункт наибольшего соответствия правой кнопкой мышки.
3. Выберите в контекстном меню Запуск от имени администратора



Наберите
get-NetConnectionProfile

Будет выведен список профилей сетей.

InterfaceAlias: Имя здесь отображается псевдоним сети.
InterfaceIndex: Номер индекс сети(номер интерфейса)
NetworkCategory: Тип сети показывает тип сети

Как вы можете задать тип сети:

Set-NetConnectionProfile -InterfaceIndex номер_интерфейса -Networkcategory  тип_сети -PassThru

Вместо номер_интерфейса введите номер нужного интерфейса для которого вы хотите поменять тип сети. Вместо тип_сети введите Private для частной сети или Public для публичной сети.

Ключ -PassThru означает вывод результатов изменений на экран. Без этого ключа изменения вступят в силу, но результат не отобразится в окне Power Shell и для проверки вам снова придется набрать:
get-NetConnectionProfile


Надеюсь я все понятно рассказал и вам легко будет настроить свою домашнюю сеть.
Подробнее..

Вечные виртуальные серверы

28.06.2020 22:13:05 | Автор: admin
Меня зовут Леонид, я разработчик сайта Поиск VPS. Как видно из названия, проект специализируется на помощи в поиске виртуальных серверов, поэтому я стараюсь следить за всеми новшествами в этой сфере.

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



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

Все вышеперечисленные маркетинговые приемы имеют одно отличие от вечных серверов: пользователь платит постоянно.

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

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

На данный момент я знаю трех хостеров, которые предоставляют такие вечные серверы, однако уверен, что в будущем их количество будет только расти:
У каждого из этих хостеров есть несколько вечных тарифов на выбор с разным количеством ресурсов и за разные деньги. Самый дешевый вечный тариф предлагает EternalHost за 5990 рублей, он включает в себя 1 ядро процессора, 1 GB оперативной памяти и 16 GB на NVMe SSD накопителе. Аналогичные характеристики предлагают и другие хостеры за исключением объема диска: у VDSina указано 30 GB диска за 8640 рублей, а cPanel Hosting предлагает 10 GB диска за 8800 рублей.

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

Подсчет я вел двумя способами:

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

Результаты следующие:

VDSina

Тариф 8640Р 17820Р 64800Р
Характеристики 30 GB NVMe
1 GB RAM
1 vCPU
40 GB NVMe
2 GB RAM
2 vCPU
80 GB NVMe
8 GB RAM
4 vCPU
Цена (вечная) 8640 руб. 17820 руб. 64800 руб.
Цена за месяц:
у хостера и отношение цен
330 руб.
26.18
630 руб.
28.29
2490 руб.
26.02
Цена за месяц:
минимальная и отношение цен
250 руб.
34.56
327 руб.
54.5
652 руб.
99.39

EternalHost

Тариф Начальный Базовый Премиум
Характеристики 16 GB NVMe
1 GB RAM
1 vCPU
32 GB NVMe
2 GB RAM
2 vCPU
64 GB NVMe
4 GB RAM
3 vCPU
Цена (вечная) 5990 руб. 11990 руб. 23990 руб.
Цена за месяц:
у хостера и отношение цен
350 руб.
17.11
690 руб.
17.38
1390 руб.
17.26
Цена за месяц:
минимальная и отношение цен
170 руб.
35.24
259 руб.
46.29
645 руб.
37.19

cPanel Hosting

Тариф KVM Linux NVMe Start v.6 KVM Linux NVMe v.6 KVM Windows NVMe Start v.6 KVM Windows NVMe v.6
Характеристики 10 GB NVMe
1 GB RAM
1 vCPU
20 GB NVMe
2 GB RAM
2 vCPU
30 GB NVMe
1 GB RAM
1 vCPU
Windows
30 GB NVMe
2 GB RAM
2 vCPU
Windows
Цена (вечная) 8800 руб. 10100 руб. 15660 руб. 23664 руб.
Цена за месяц:
у хостера и отношение цен
250 руб.
35.2
550 руб.
18.36
450 руб.
34.67
680 руб.
34.8
Цена за месяц:
минимальная и отношение цен
139 руб.
63.31
234 руб.
43.16
450 руб.
34.67
630 руб.
37.56
Итак, все хостеры придерживаются тактики взять за сервер как минимум 35 арендных плат за месяц, если сравнивать с самыми низкими ценами на рынке. Таким образом для пользователя ситуация с арендой вечного сервера будет выгодной в том случае, если время его использования будет более, чем 3 года. Однако, по факту это число будет еще больше, так как я не учитываю следующие параметры:

  1. Некоторые хостеры предоставляют скидки при оплате на длительный срок, например, очень часто можно увидеть скидку 10% при оплате на год. Таким образом число ежемесячных платежей увеличивается еще на несколько.
  2. Оплачивая вечный сервер, вы предоставляете хостеру бесплатный кредит без необходимости выплачивать проценты, хотя просто держа эти деньги на вкладе можно зарабатывать еще один-два месяца аренды в год, а вот для хостера это наоборот возможность привлечь инвестиции.
  3. Со временем ресурсы будут дешеветь. Например, если сейчас тариф с 2 GB RAM, 2 ядрами и 40 GB диска стоит от 249 рублей в месяц, то через несколько лет цена может оказаться существенно ниже.

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

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

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

  1. Ресурсов купленного тарифа в какой-то момент может не хватить, а доплатить и перейти на другой тариф хостер может не дать.
  2. Почти уверен, что хостеры не будут позволять переносить такой сервер с аккаунта на аккаунт, поэтому продать вечный сервер скорее всего не получится.
  3. С хостером может что-то случиться, и тогда вряд ли стоит ожидать возврата вложенных денег. Случаев, когда мелкие и не очень хостеры уходят из бизнеса, очень и очень много, особенно большое их количество было в 2019 году.
  4. Вариант, когда хостер внезапно скажет, что сервер перестал быть вечным, я не сильно рассматриваю (хотя и не исключаю такой возможности), так как в этом случае репутация хостера сразу окажется в не слишком хорошем положении.
  5. Хостер может заблокировать сервер по какой-либо причине. Например, сервер взломали и начали рассылать спам. Так как такой сервер не очень маржинальный продукт, то с большой вероятностью хостер на основании своих же правил прекратит предоставление услуги
  6. Хостер может испортиться, и в этом случае переезд к другому хостеру вынудит пользователя платить за новый сервер, хотя вечный сервер все еще работает. Из примеров: техподдержка стала значительно хуже, на хостера постоянно льются DDoS- атаки, сервер работает нестабильно и т.д. В стандартном варианте клиент просто переезжает к другому хостеру, а в случае вечного сервера уплаченные деньги никто не вернет.
  7. Сервер попросту может перестать быть нужным, например, если закроется проект, который был на нем размещен. В случае обычного сервера вы просто перестаете платить, а тут деньги заплачены вперед.

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

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

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

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

XFS, Reflink и Fast Clone. Созданы друг для друга

29.06.2020 10:05:23 | Автор: admin
Как все мы знаем, XFS это высокопроизводительная журналируемая файловая система, созданная в недрах Silicon Graphics. А высокопроизводительная она потому, что способна справляться с множеством параллельных потоков ввода-вывода. Так что если вам интересна файловая система с легко масштабируемой пропускной способностью и не деградирующая от работы с несколькими устройствами одновременно, то вам, однозначно, сюда. Но сегодня мы будем нахваливать не весь XFS, а один конкретный его флаг reflink. Он включает возможность переиспользовать одинаковые блоки данных между файлами, обеспечивая дедупликацию и возможность делать быстрые copy-on-write снапшоты.
Грешновато проходить мимо такой увлекательной функциональности, поэтому сегодня мы посмотрим, как reflink может помочь всем ответственным за бекапы, и что на этой ниве нам может предложить Veeam Backup & Replication 10.



Если сильно не вдаваться в подробности, то reflink для XFS был представлен примерно три года назад. Ничего прорывного в этом событии не было, так как своя реализация у Microsoft была аж с 2012 года (под названием ReFS), а в том или ином виде reflink есть в BTRFS и OCFS2. Возможно, даже в большем количестве файловых систем тут прошу поправить читателей, если незаслуженно кого-то пропустил.

Итак, что же нам, бойцам фронта резервного копирования, с подобных технологий? Конечно же, самое главное это спасение драгоценного места в наших бекапных репозиториях за счёт встроенного в файловую систему механизма дедуплицирования. Это самый первый и очевидный плюс. Менее очевидный повышение быстродействия тяжёлых файловых операций. Если наше приложение умеет работать с reflink, то процедура копирования тяжёлого файла может свестись к обновлению метаданных, без необходимости реально перемещать блоки данных. Что, как вы догадываетесь, на порядки быстрее.
В контексте Veeam это позволило многократно (вы даже себе не представляете, насколько) ускорить такую операцию, как Synthetic Full. Создание синтетики это страшный сон вашего хранилища. Наверняка помните, как любят всякие техноблогеры взять и начать мучать условный винчестер тестом на чтение из произвольных мест, злобно потешаясь над упавшим в пол графиком производительности? А создание синтетического бекапа это не тест, а реальная задача, состоящая из постоянного потока операций чтения и записи из любого места на диске. Если у вас просто упадёт производительность накопителей, это ещё не плохо. Некоторые хранилища могут и просто зависнуть на полуслове.

Соответственно, если нам не надо метаться по всему диску в поисках нужных блоков и копировать их в новое место, а можно просто поправить таблицу метаданных, это даёт невероятный эффект. Поэтому нет ничего странного, что мы в Veeam давно рекомендуем использовать эту возможность, а саму функцию назвали Fast Clone. И, как было уже сказано, изначально Veeam получил поддержку майкрософтовского ReFs. У нас на форуме есть отзыв клиента, которому использование ReFS позволило уместить 99 терабайт реальных данных на 15 терабайт занятого места. И это без использования дорогих дедуплицирующих устройств.
И вот теперь настала пора и XFS получить свою толику славы.

Подготовка

Во-первых, reflink доступен в XFS только в относительно свежих релизах т.к. требует поддержки на уровне ядра. Ваша любимая Ubuntu 16.04 здесь не подойдёт, так что обновляйте до 18.04. Или лучше даже 20.04.
Что ещё? На системе обязательно должна быть включена проверка CRC и очень интересный момент: используемый размер блока данных должен быть в промежутке от 1 KiB до 4 KiB. Технически верхняя граница задаётся размером страниц в памяти (default), хотя можно и больше до 64KiB, но придётся пересобирать ядро. И многие репортят, что такой конфиг нестабилен. Как сказано в официальном мане XFS on Linux can only mount filesystems with pagesize or smaller blocks.
.
Предварительно проверяем, что у нас всё хорошо:

toor@ubuntuxfs:~$ sudo lshw -class disk -class storage -shortH/W path      Device      Class      Description================================================/0/2          scsi0      storage/0/2/0.0.0    /dev/sda   disk       5368MB Virtual Disk/0/2/0.0.2    /dev/sdb   disk       21GB Virtual Disk

А потом создаём нужный раздел командой. Почему именно создаём? Да потому что нельзя включить флаг -reflink на уже созданной файловой системе. Такое вот ограничение от разработчиков.

toor@ubuntuxfs:~$ mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb

И видим примерно такой вывод, где crc=1 и reflink=1, что нам и требуется. Честно говоря, crc=1 выставляется по дефолту, но у нас тут условия лабораторные, так что мы это сделали для наглядности.

meta-data=/dev/sdb               isize=512    agcount=4, agsize=1310720 blks         =                       sectsz=4096  attr=2, projid32bit=1         =                       crc=1        finobt=1, sparse=1, rmapbt=0         =                       reflink=1data     =                       bsize=4096   blocks=5242880, imaxpct=25         =                       sunit=0      swidth=0 blksnaming   =version 2              bsize=4096   ascii-ci=0, ftype=1log      =internal log           bsize=4096   blocks=2560, version=2         =                       sectsz=4096  sunit=1 blks, lazy-count=1realtime =none                   extsz=4096   blocks=0, rtextents=0

Делаем папку для бекапов и монтируем её

toor@ubuntuxfs: mkdir /backupsmount /dev/sdb /backups

А чтобы окончательно убедиться в том, что всё хорошо, смотрим:

toor@ubuntuxfs: df -hT .Filesystem     Type      Size  Used Avail Use% Mounted on/dev/sdb       xfs        20G  17M   20G   1% /backups

Испытания
Теперь давайте в лабораторных условиях проверим, как работает это хвалёный XFS и его reflink. Для это сгенерируем файл с рандомным содержимым с помощью всеми любимого метода перенаправления вывода из urandom

root@ubuntu: dd if=/dev/urandom of=test bs=1M count=1024010240+0 records in10240+0 records out10737418240 bytes (11 GB, 10 GiB) copied, 71.9184 s, 149 MB/s

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

root@ubuntu:/backups# df -hFilesystem      Size  Used Avail Use% Mounted on/dev/sdb         20G   11G  9.9G  51% /backups

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

root@ubuntu: cp -v --reflink=always test test-one'test' -> 'test-one

Проверяем

root@ubuntu:/backups# ls -hsltotal 20G10G -rw-r--r-- 1 root root 10G Jun 17 09:45 test10G -rw-r--r-- 1 root root 10G Jun 17 10:01 test-one

root@ubuntu:/backups# df -hFilesystem      Size  Used Avail Use% Mounted on/dev/sdb         20G   11G  9.9G  51% /backups

Отлично! У нас два файла по десять гигабайт, вместе занимающие одиннадцать. Слава технологиям! Но помним, что так же, как и в случае с ReFS, это всё не проходит даром и требует определённых издержек. В ReFS один блок можно переиспользовать всего 8175 раз. Также и в XFS. Количество зависит от того, сколько записей о клонах мы можем хранить это количество записей inodes. А это уже те самые метаданные. Но есть и хорошие новости: этот размер меняется динамически, и теоретический предел XFS гораздо больше, чем в ReFS.

Давайте ещё посмотрим, как данные расположены на диске

root@ubuntu:/backups# filefrag -v test test-oneFilesystem type is: 58465342File size of test is 10737418240 (2621440 blocks of 4096 bytes) ext:     logical_offset:        physical_offset: length:   expected: flags:   0:        0.. 1048559:         24..   1048583: 1048560:             shared   1:  1048560.. 2097135:    1310733..   2359308: 1048576:    1048584: shared   2:  2097136.. 2621439:    2624013..   3148316: 524304:    2359309: last,shared,eoftest: 3 extents foundFile size of test-one is 10737418240 (2621440 blocks of 4096 bytes) ext:     logical_offset:        physical_offset: length:   expected: flags:   0:        0.. 1048559:         24..   1048583: 1048560:             shared   1:  1048560.. 2097135:    1310733..   2359308: 1048576:    1048584: shared   2:  2097136.. 2621439:    2624013..   3148316: 524304:    2359309: last,shared,eoftest-one: 3 extents found

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

Теперь переходим к практическим упражнениям с Veeam

Практика

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



И главное, не забываем галочку Use Fast Cloning on XFS volumes. Иначе фокус не получится. И проверьте, что по кнопке Advanced все галочки сняты.



Когда мастер закончит свою работу, можно переходить к созданию бекапов. Как вы помните, в начале я говорил про использование заданий с созданием синтетических точек. Поэтому на шаге Storage не забываем выбрать нужный репозиторий, зайти на вкладку Advanced, выбрать Create Synthetic full backups periodically и выбрать, в какие дни они будут создаваться. Обычно мы всем советуем выбирать выходные, так как операции это сложные, и незачем на буднях лишний раз нагружать ваше хранилище.



Также не будет лишним на вкладке Maintenance включить периодический backup health check. Слишком много мы все слышали печальных историй о повреждении данных на системах вроде ReFS и XFS. Да, подобные механизмы уже встроены в саму файловую систему, но если бы они реально работали, мы бы не читали столько увлекательных рассказов про героическое спасение данных. Практика показала, что если у вас RAID с избыточностью, то вы можете спать более-менее спокойно. Если нет, то всё, на что способны эти системы самопроверки это сказать Ой, всё.



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



Приписка [fast clone] означает, что была создана не просто синтетическая точка, а именно с использованием Fast Clone [xfs reflink] для всего содержимого бекапа. Бывает ещё вариант [partial fast clone], когда создаётся смешанная цепочка. Да, мы умеем делать синтетику даже на не выравненных фс. Как и в ReFS, Veeam может клонировать блоки только по границам блоков файловой системы. Поэтому блоки данных бэкапных файлов создаются с выравниванием, равным block_size. Это делается автоматически при создании репозитория и для этого даже есть отдельная галочка в настройках репозитория.
Теперь давайте вернёмся на репозиторий и посмотрим файлы с бекапами. А именно, проверим, из чего состоит последний синтетический .vbk
Вывод реального файла может быть очень большим, поэтому я приведу лишь его начало и конец

root@ubuntu:/backups/Agent Linux/192.168.91.226# filefrag -v Agent\ Linux\ -\ 192.168.91.226D2020-06-18T062036_1F09.vbkFilesystem type is: 58465342File size of Agent Linux - 192.168.91.226D2020-06-18T062036_1F09.vbk is 2430484480 (593380 blocks of 4096 bytes) ext:     logical_offset:        physical_offset: length:   expected: flags:   0:        0..       0:    1777650..   1777650:      1:   1:        1..    4360:    2039034..   2043393:   4360:    1777651:   2:     4361..    5341:    1315106..   1316086:    981:    2043394: shared   3:     5342..    5345:    1986271..   1986274:      4:    1316087:   4:     5346..    5348:    1316091..   1316093:      3:    1986275: shared   5:     5349..    5570:    1986275..   1986496:    222:    1316094: shared   6:     5571..    5603:    1316319..   1316351:     33:    1986497: shared   7:     5604..    5781:    1986497..   1986674:    178:    1316352: shared   8:     5782..    5800:    1974097..   1974115:     19:    1986675: shared   9:     5801..    5872:    1316508..   1316579:     72:    1974116: shared.... 925:   545910..  546109:    2534022..   2534221:    200:    1853810: shared 926:   546110..  546299:    1776748..   1776937:    190:    2534222: shared 927:   546300..  546477:    2534222..   2534399:    178:    1776938: shared 928:   546478..  546623:    1854227..   1854372:    146:    2534400: shared 929:   546624..  547203:    2534400..   2534979:    580:    1854373: shared 930:   547204..  548096:    1855025..   1855917:    893:    2534980: shared 931:   548097..  549585:    2534980..   2536468:   1489:    1855918: shared 932:   549586..  551487:    1857319..   1859220:   1902:    2536469: shared 933:   551488..  551787:    2536469..   2536768:    300:    1859221: shared 934:   551788..  553011:    2037808..   2039031:   1224:    2536769: 935:   553012..  577866:    1929924..   1954778:  24855:    2039032: shared 936:   577867..  578291:    2536769..   2537193:    425:    1954779: shared 937:   578292..  592732:    1954913..   1969353:  14441:    2537194: shared 938:   592733..  593373:    2537194..   2537834:    641:    1969354: shared 939:   593374..  593375:    1777645..   1777646:      2:    2537835: shared 940:   593376..  593379:    1969356..   1969359:      4:    1777647: last,eofAgent Linux - 192.168.91.226D2020-06-18T062036_1F09.vbk: 941 extents found

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

root@ubuntu:/backups/Agent Linux/192.168.91.226# df -h .Filesystem      Size  Used Avail Use% Mounted on/dev/sdb         20G  3.8G   17G  19% /backups

Реально использовано 3,8 Гигабайта. А что же сами файлы?

root@ubuntu:/backups/Agent Linux/192.168.91.226# ls -hsltotal 7.2G 56K -rw-rw-rw- 1 root root  54K Jun 18 13:20 'Agent Linux - 192.168.91.226.vbm'1.8G -rw-r--r-- 1 root root 1.8G Jun 17 13:53 'Agent Linux - 192.168.91.226D2020-06-17T065146_8546.vbk' 63M -rw-r--r-- 1 root root  63M Jun 17 13:57 'Agent Linux - 192.168.91.226D2020-06-17T065727_0228.vib'317M -rw-r--r-- 1 root root 317M Jun 17 14:03 'Agent Linux - 192.168.91.226D2020-06-17T070240_FD8B.vib'383M -rw-r--r-- 1 root root 383M Jun 17 14:09 'Agent Linux - 192.168.91.226D2020-06-17T070826_5860.vib'2.4G -rw-r--r-- 1 root root 2.4G Jun 17 15:04 'Agent Linux - 192.168.91.226D2020-06-18T020624_DF44.vbk'2.3G -rw-r--r-- 1 root root 2.3G Jun 18 13:20 'Agent Linux - 192.168.91.226D2020-06-18T062036_1F09.vbk'

А сами файлы занимают 7,2 Гигабайта. Вот такой вот выигрыш.

На этом задачу показать пользу и выгоду от использования Fast Clone считаю выполненной. Как мы видим, это не только экономия места, хотя сейчас и считается, что проще купить новый сторадж и накидать в него дисков. Это ещё и экономия времени, чтобы попасть в необходимый backup window. Пока скорость обычной синтетики ограничена производительностью дисковой подсистемы, в случае ReFS/XFS это нагрузка больше вычислительная. А с доступностью CPU и RAM ресурсов дела обычно обстоят намного лучше.

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

helpcenter.veeam.com/docs/backup/vsphere/backup_repository_block_cloning.html?ver=100 Про Fast Clone в документации
www.veeam.com/kb3150 Fast Clone и Nutanix Mine
blogs.oracle.com/linux/xfs-data-block-sharing-reflink Отличная статья про XFS и Reflink в блоге Oracle
Подробнее..

Перевод 5 современных альтернатив старым инструментам командной строки Linux

29.06.2020 14:12:48 | Автор: admin
Используя более современные альтернативы наряду со старыми инструментами командной строки, можно получить больше удовольствия и даже повысить производительность труда.



В повседневной работе в Linux / Unix мы используем множество инструментов командной строки например, du для мониторинга использования диска и системных ресурсов. Некоторые из этих инструментов существуют уже давно. Например, top появился в 1984 году, а первый релиз du датируется 1971 годом.
За прошедшие годы эти инструменты были модернизированы и портированы на разные системы, но в целом далеко не ушли от своих первых версий, их внешний вид и usability также сильно не изменились.

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


1. ncdu vs du


NCurses Disk Usage (ncdu) похож на du, но с интерактивным интерфейсом на основе библиотеки curses. ncdu отображает структуру каталогов, которые занимают большую часть вашего дискового пространства.

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

ncdu 1.14.2 ~ Use the arrow keys to navigate, press ? for help--- /home/rgerardi ------------------------------------------------------------   96.7 GiB [##########] /libvirt   33.9 GiB [###       ] /.crc    7.0 GiB [          ] /Projects.   4.7 GiB [          ] /Downloads.   3.9 GiB [          ] /.local    2.5 GiB [          ] /.minishift    2.4 GiB [          ] /.vagrant.d.   1.9 GiB [          ] /.config.   1.8 GiB [          ] /.cache    1.7 GiB [          ] /Videos    1.1 GiB [          ] /go  692.6 MiB [          ] /Documents. 591.5 MiB [          ] /tmp  139.2 MiB [          ] /.var  104.4 MiB [          ] /.oh-my-zsh   82.0 MiB [          ] /scripts   55.8 MiB [          ] /.mozilla   54.6 MiB [          ] /.kube   41.8 MiB [          ] /.vim   31.5 MiB [          ] /.ansible   31.3 MiB [          ] /.gem   26.5 MiB [          ] /.VIM_UNDO_FILES   15.3 MiB [          ] /Personal    2.6 MiB [          ]  .ansible_module_generated    1.4 MiB [          ] /backgrounds  944.0 KiB [          ] /Pictures  644.0 KiB [          ]  .zsh_history  536.0 KiB [          ] /.ansible_async Total disk usage: 159.4 GiB  Apparent size: 280.8 GiB  Items: 561540


По записям можно перемещаться с помощью клавиш со стрелками. Если вы нажмёте Enter, ncdu отобразит содержимое выбранного каталога:

--- /home/rgerardi/libvirt ----------------------------------------------------                         /..   91.3 GiB [##########] /images    5.3 GiB [          ] /media


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

ncdu доступен для многих платформ и дистрибутивов Linux. Например, вы можете использовать dnf для его установки на Fedora непосредственно из официальных репозиториев:

$ sudo dnf install ncdu


2. htop vs top


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

По умолчанию htop выглядит так:



В отличие от top:



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

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

3. tldr vs man


Инструмент командной строки tldr отображает упрощённую справочную информацию о командах, в основном примеры. Его разработало сообщество tldr pages project.

Стоит отметить, что tldr это не замена man. Он по-прежнему является каноническим и наиболее полным инструментом вывода справочных страниц. Однако в некоторых случаях man является избыточным. Когда вам не нужна исчерпывающая информация о какой-либо команде, вы просто пытаетесь запомнить основные варианты её использования. Например, страница man для команды curl содержит почти 3000 строк. Страница tldr для curl имеет длину 40 строк. Её фрагмент выглядит так:

$ tldr curl# curl  Transfers data from or to a server.  Supports most protocols, including HTTP, FTP, and POP3.  More information: <https://curl.haxx.se>.- Download the contents of an URL to a file:  curl http://example.com -o filename- Download a file, saving the output under the filename indicated by the URL:  curl -O http://example.com/filename- Download a file, following [L]ocation redirects, and automatically [C]ontinuing (resuming) a previous file transfer:  curl -O -L -C - http://example.com/filename- Send form-encoded data (POST request of type `application/x-www-form-urlencoded`):  curl -d 'name=bob' http://example.com/form                                                                                            - Send a request with an extra header, using a custom HTTP method:  curl -H 'X-My-Header: 123' -X PUT http://example.com                                                                                  - Send data in JSON format, specifying the appropriate content-type header:  curl -d '{"name":"bob"}' -H 'Content-Type: application/json' http://example.com/users/1234... TRUNCATED OUTPUT


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

Для Fedora tldr был написан на Python. Вы можете установить его с помощью менеджера dnf. Обычно для работы инструмента необходим доступ к интернету. Но клиент Python в Fedora позволяет загружать и кэшировать эти страницы для автономного доступа.

4. jq vs sed/grep


jq это JSON-процессор для командной строки. Он похож на sed или grep, но специально разработан для работы с данными в формате JSON. Если вы разработчик или системный администратор, который использует JSON в повседневных задачах, этот инструмент для вас.

Основное преимущество jq перед стандартными инструментами обработки текста, такими как grep и sed, заключается в том, что он понимает структуру данных JSON, позволяя создавать сложные запросы в одном выражении.

Например, вы пытаетесь найти названия контейнеров в этом файле JSON:

{  "apiVersion": "v1",  "kind": "Pod",  "metadata": {    "labels": {      "app": "myapp"    },    "name": "myapp",    "namespace": "project1"  },  "spec": {    "containers": [      {        "command": [          "sleep",          "3000"        ],        "image": "busybox",        "imagePullPolicy": "IfNotPresent",        "name": "busybox"      },      {        "name": "nginx",        "image": "nginx",        "resources": {},        "imagePullPolicy": "IfNotPresent"      }    ],    "restartPolicy": "Never"  }}


Запустите grep для поиска строки name:

$ grep name k8s-pod.json        "name": "myapp",        "namespace": "project1"                "name": "busybox"                "name": "nginx",


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

Чтобы получить этот же результат с помощью jq, достаточно написать:

$ jq '.spec.containers[].name' k8s-pod.json"busybox""nginx"


Эта команда выдаст вам имена обоих контейнеров. Если вы ищете только имя второго контейнера, добавьте индекс элемента массива в выражение:

$ jq '.spec.containers[1].name' k8s-pod.json"nginx"


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

У jq много функций, но для их описания нужна ещё одна статья. Для получения дополнительной информации обратитесь к странице проекта jq или к tldr.

5. fd vs find


fd это упрощённая альтернатива утилите find. Fd не призван заменить её полностью: в нём по умолчанию установлены наиболее распространённые настройки, определяющие общий подход к работе с файлами.

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

По умолчанию fd выполняет поиск без учёта регистра в текущем каталоге с цветным выводом. Тот же поиск с использованием команды find требует ввода дополнительных параметров в командной строке. Например, чтобы найти все файлы .md (или .MD) в текущем каталоге, нужно написать такую команду find:

$ find . -iname "*.md"


Для fd она выглядит так:

$ fd .md


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

fd доступен для многих дистрибутивов Linux. В Fedora его можно установить так:

$ sudo dnf install fd-find


Необязательно от чего-то отказываться


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



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


Многие наши клиенты уже оценили преимущества эпичных серверов!
Это виртуальные серверы с процессорами AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит оторваться на полную 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Спешите заказать!

Подробнее..

Новый HAProxy Data Plane API два примера программной конфигурации

02.07.2020 10:04:35 | Автор: admin

Новый HAProxy Data Plane API: два примера программной конфигурации


Используйте HAProxy Data Plane API для динамического управления конфигурацией балансировщика нагрузки с помощью HTTP-команд.


Проектирование для высокой доступности почти всегда означает наличие высокого уровня прокси / балансировщика нагрузки. Прокси-сервер предоставляет основные услуги, такие как:


  • обнаружение и удаление неисправных серверов
  • очередь соединений
  • разгрузка шифрования TLS
  • компрессия
  • кэширование

Задача состоит в том, чтобы поддерживать ваши конфигурации в актуальном состоянии, что особенно сложно, поскольку сервисы перемещаются в контейнеры, и эти контейнеры становятся эфемерными. Доступный начиная с HAProxy 2.0 вы можете использовать новый HAProxy Data Plane API (Перевод: http://personeltest.ru/aways/habr.com/ru/post/508132/), который является современным REST API.


HAProxy Data Plane API дополняет гибкий язык конфигурации HAProxy, который предоставляет строительные блоки для определения простых и сложных правил маршрутизации. Это также идеальное дополнение к существующему Runtime API, которое позволяет запускать, останавливать и пропускать трафик с серверов, изменять вес сервера и управлять проверками работоспособности.


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


Управление конфигурацией


Обычно при настройке HAProxy вам нужно вручную отредактировать файл конфигурации /etc/haproxy/haproxy.cfg. Этот файл используется для управления всеми функциями балансировщика нагрузки. Он в основном разделен на frontend разделы, определяющие общедоступные IP-адреса, к которым подключаются клиенты, и backend разделы, содержащие вышестоящие сервера, на которые направляется трафик. Но вы можете сделать гораздо больше, в том числе установить глобальные параметры, влияющие на работающий процесс, установить значения по умолчанию, добавить анализ поведения трафика с помощью таблиц флеш-памяти, прочитать файлы карт, определить правила фильтрации с помощью ACL и многое другое.


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


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


Data Plane API использует Go пакеты config-parser и client-native для парсинга конфигурации HAProxy и вызова команд Runtime API соответственно. Вы можете использовать их в своих собственных проектах для интеграции с HAProxy.


Динамическое конфигурирование HAProxy


С помощью Data Plane API вы можете многое сделать. В этом разделе вы узнаете, как создать backend с серверами и frontend, который направляет трафик на него. Но сначала следуйте официальной документации по установке и настройке API.


После того как он будет установлен и запущен, вызовите GET в конечной точке /v1/services/haproxy/configuration/backends, чтобы увидеть уже определенные разделы backend, например:


$ curl --get --user admin:mypassword \    http://localhost:5555/v1/services/haproxy/configuration/backends

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


Вызовите endpoint /v1/services/haproxy/transactions для создания новой транзакции. Для этого потребуется параметр версии в URL, но командам внутри транзакции он не нужен. Всякий раз, когда вызывается команда POST, PUT или DELETE, должна быть включена версия, которая затем записывается в файл конфигурации HAProxy. Это гарантирует, что если несколько клиентов будут использовать API, они избежать конфликтов. Если версия, которую вы передаете, не соответствует версии, указанной в файле конфигурации, вы получите сообщение об ошибке. При использовании транзакции эта версия указывается заранее при ее создании.


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       http://localhost:5555/v1/services/haproxy/transactions?version=1

Вы найдете идентификатор транзакции в возвращенном документе JSON:


{"_version":5,"id":"9663c384-5052-4776-a968-abcef032aeef","status":"in_progress"}

Затем используйте endpoint /v1/services/haproxy/configuration/backends, чтобы создать новый бэкэнд, отправив идентификатор транзакции в качестве параметра URL:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "test_backend", "mode":"http", "balance": {"algorithm":"roundrobin"}, "httpchk": {"method": "HEAD", "uri": "/", "version": "HTTP/1.1"}}' \            http://localhost:5555/v1/services/haproxy/configuration/backends?transaction_id=9663c384-5052-4776-a968-abcef032aeef

Затем вызовите endpoint /v1/services/haproxy/configuration/servers для добавления серверов в backend:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "server1", "address": "127.0.0.1", "port": 8080, "check": "enabled", "maxconn": 30, "weight": 100}' \       "http://localhost:5555/v1/services/haproxy/configuration/servers?backend=test_backend&transaction_id=9663c384-5052-4776-a968-abcef032aeef"

Затем добавьте frontend с помощью endpoint /v1/services/haproxy/configuration/frontends :


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "test_frontend", "mode": "http", "default_backend": "test_backend", "maxconn": 2000}' \       http://localhost:5555/v1/services/haproxy/configuration/frontends?transaction_id=9663c384-5052-4776-a968-abcef032aeef

У этого frontend еще нет никаких bind операторов. Добавьте одно, используя endpoint /v1/services/haproxy/configuration/binds, как на примере:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "http", "address": "*", "port": 80}' \       "http://localhost:5555/v1/services/haproxy/configuration/binds?frontend=test_frontend&transaction_id=9663c384-5052-4776-a968-abcef032aeef"

Затем, чтобы зафиксировать транзакцию и применить все изменения, вызовите endpoint /v1/services/haproxy/transactions/[transaction ID] с помощью PUT, например:


$ curl -X PUT --user admin:mypassword \       -H "Content-Type: application/json" \       http://localhost:5555/v1/services/haproxy/transactions/9663c384-5052-4776-a968-abcef032aeef

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


frontend test_frontend    mode http    maxconn 2000    bind *:80 name http    default_backend test_backendbackend test_backend    mode http    balance roundrobin    option httpchk HEAD / HTTP/1.1    server server1 127.0.0.1:8080 check maxconn 30 weight 100

Этот балансировщик нагрузки готов принимать трафик и перенаправлять его на вышестоящий сервер.


Поскольку в спецификации Data Plane API используется OpenAPI, его можно использовать для генерации клиентского кода на многих поддерживаемых языках программирования.


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


Другой пример


Вы увидели простоту и мощь HAProxy Data Plane API. С помощью нескольких HTTP-команд вы можете динамически изменять конфигурацию. Давайте рассмотрим другой пример. Мы создадим ACL, который будет проверять имеет ли заголовок Host значение example.com. Если это так, то строка use_backend будет направлена на другой сервер с именем example_servers. Мы также добавим правило http-request deny, которое будет отклонять любые запросы для пути URL /admin.php, если исходный IP-адрес клиента не находится в сети 192.168.50.20/24.


Сначала используйте endpoint /v1/services/haproxy/transactions для создания новой транзакции и получения ее идентификатора:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \        http://localhost:5555/v1/services/haproxy/transactions?version=2{"_version":2,"id":"7d0d6737-655e-4489-92eb-6d29cdd69827","status":"in_progress"}

Затем используйте endpoint /v1/services/haproxy/configuration/backends вместе с идентификатором транзакции, чтобы создать новый backend с именем example_servers:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "example_servers", "mode":"http", "balance": {"algorithm":"roundrobin"}}' \       http://localhost:5555/v1/services/haproxy/configuration/backends?transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827

Используйте endpoint /v1/services/haproxy/configuration/servers для добавления server в backend:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "server1", "address": "127.0.0.1", "port": 8081, "check": "enabled", "maxconn": 30, "weight": 100}' \       "http://localhost:5555/v1/services/haproxy/configuration/servers?backend=example_servers&transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827"

Используйте endpoint /v1/services/haproxy/configuration/acls, чтобы определить ACL с именем is_example, который проверяет, имеет ли заголовок узла значение example.com:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"id": 0, "acl_name": "is_example", "criterion": "req.hdr(Host)", "value": "example.com"}' \       "http://localhost:5555/v1/services/haproxy/configuration/acls?parent_type=frontend&parent_name=test_frontend&transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827"

Используйте /v1/services/haproxy/configuration/backend_switching_rules, чтобы добавить строку use_backend, которая оценивает ACL is_example:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"id": 0, "cond": "if", "cond_test": "is_example", "name": "example_servers"}' \       "http://localhost:5555/v1/services/haproxy/configuration/backend_switching_rules?frontend=test_frontend&transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827"

Используйте endpoint /v1/services/haproxy/configuration/http_request_rules, чтобы добавить правило http-request deny, которое проверяет, является ли путь /admin.php, а исходный IP-адрес клиента не находится в сети 192.168.50.20/24:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"id": 0, "cond": "if", "cond_test": "{ path /admin.php } !{ src 192.168.50.20/24 }", "type": "deny"}' \       "http://localhost:5555/v1/services/haproxy/configuration/http_request_rules?parent_type=frontend&parent_name=test_frontend&transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827"

Затем подтвердите транзакцию, чтобы изменения вступили в силу:


$ curl -X PUT --user admin:mypassword \       -H "Content-Type: application/json" \       http://localhost:5555/v1/services/haproxy/transactions/7d0d6737-655e-4489-92eb-6d29cdd69827

Ваша конфигурация HAProxy теперь выглядит вот так:


frontend test_frontend    mode http    maxconn 2000    bind *:80 name http    acl is_example req.hdr(Host) example.com    http-request deny deny_status 0 if { path /admin.php } !{ src 192.168.50.20/24 }    use_backend example_servers if is_example    default_backend test_backendbackend example_servers    mode http    balance roundrobin    server server1 127.0.0.1:8081 check maxconn 30 weight 100backend test_backend    mode http    balance roundrobin    option httpchk HEAD / HTTP/1.1    server server1 127.0.0.1:8080 check maxconn 30 weight 100

Заключение


В этой статье вы ознакомились с HAProxy Data Plane API, который позволяет полностью настроить HAProxy с использованием современного REST API. Более подробную информацию можно найти в официальной документации (Перевод: http://personeltest.ru/aways/habr.com/ru/post/508132/). У него имеются три мощных функции, которые включают гибкий язык конфигурации HAProxy и API времени выполнения. Data Plane API открывает двери для многостороннего использования, в частности, с использованием HAProxy в качестве уровня прокси в сетке сервиса.


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


Если вам понравилась эта статья и вы хотите быть в курсе похожих тем, подпишитесь на этот блог. Вы также можете подписаться на нас в Твиттере и присоединиться к разговору на Slack. HAProxy Enterprise позволяет легко приступить к работе с Data Plane API, поскольку его можно установить в виде удобного системного пакета. Он также включает в себя надежную и передовую кодовую базу, корпоративный набор дополнений, экспертную поддержку и профессиональные услуги. Хотите узнать больше? Свяжитесь с нами сегодня и скачайте бесплатную пробную версию.


P.S. Телеграм чат HAproxy https://t.me/haproxy_ru

Подробнее..

Перевод Почему в Docker не работает Strace

02.07.2020 10:04:35 | Автор: admin
Когда я редактировала страницу о возможностях контейнеров для журнала How Containers Work, мне потребовалось объяснить, почему в Docker не работает strace. Вот что случалось при запуске strace в Docker-контейнере на моем ноутбуке:

$ docker run  -it ubuntu:18.04 /bin/bash$ # ... install strace ...root@e27f594da870:/# strace lsstrace: ptrace(PTRACE_TRACEME, ...): Operation not permitted

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

docker run --cap-add=SYS_PTRACE  -it ubuntu:18.04 /bin/bash

Но мне было интересно не решить проблему, а разобраться, почему эта ситуация вообще возникает. Так почему же strace не работает, а --cap-add=SYS_PTRACE все исправляет?

Гипотеза 1: У процессов контейнеров нет собственной привилегии CAP_SYS_PTRACE


Так как проблема стабильно решается через --cap-add=SYS_PTRACE, мне всегда казалось, что у процессов контейнеров Docker по определению нет собственной привилегии CAP_SYS_PTRACE, но по двум причинам тут кое-что не сходится.

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

$ getpcaps $$Capabilities for `11589': =

Причина 2: в man capabilities о привилегии CAP_SYS_PTRACE сказано следующее:

CAP_SYS_PTRACE       * Trace arbitrary processes using ptrace(2);

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

Кроме того, я провела еще одну проверку: я запустила Docker контейнер через docker run --cap-add=SYS_PTRACE -it ubuntu:18.04 /bin/bash, затем отменила привилегию CAP_SYS_PTRACE и strace продолжил корректно работать даже без привилегии. Почему?!

Гипотеза 2: Дело в пользовательском пространстве имен?


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

Итак, находится ли процесс в другом пользовательском пространстве имен? Так он выглядит в контейнере:

root@e27f594da870:/# ls /proc/$$/ns/user -l... /proc/1/ns/user -> 'user:[4026531837]'

А так он выглядит на хосте:

bork@kiwi:~$ ls /proc/$$/ns/user -l... /proc/12177/ns/user -> 'user:[4026531837]'

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

Гипотеза 3: Системный вызов ptrace блокируется правилом seccomp-bpf


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

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

Давайте проверим эту гипотезу и посмотрим, сможем ли мы воспользоваться strace в Docker контейнере, если отключим все правила seccomp:

$ docker run --security-opt seccomp=unconfined -it ubuntu:18.04  /bin/bash$ strace lsexecve("/bin/ls", ["ls"], 0x7ffc69a65580 /* 8 vars */) = 0... it works fine ...

Отлично! Все работает, и секрет раскрыт! Вот только

Почему --cap-add=SYS_PTRACE решает проблему?


Мы все еще не объяснили почему --cap-add=SYS_PTRACE решает возникающую проблему с вызовами. Главная страница docker run следующим образом объясняет работу аргумента --cap-add:

--cap-add=[]   Add Linux capabilities

Все это не имеет никакого отношения к правилам seccomp! В чем же дело?

Давайте посмотрим на исходный код Docker.


Если уже и документация не помогает, все что нам остается это погрузиться в исходники.
В Go есть одна приятная особенность: благодаря вендорингу зависимостей в репозитории Go вы через grep можете пройтись по всему репозиторию и найти интересующий вас код. Так что я склонировала github.com/moby/moby и прошерстила его в поисках выражений вида rg CAP_SYS_PTRACE.

На мой взгляд, тут происходит вот что: в имплементации seccomp в контейнере, в разделе contrib/seccomp/seccomp_default.go полно кода, который через правило seccomp проверяет, есть ли у процесса с привилегиями разрешение на использование системных вызовов в соответствии с этой привилегией.

case "CAP_SYS_PTRACE":s.Syscalls = append(s.Syscalls, specs.LinuxSyscall{Names: []string{"kcmp","process_vm_readv","process_vm_writev","ptrace",},Action: specs.ActAllow,Args:   []specs.LinuxSeccompArg{},})


Там еще есть код, который в moby и для profiles/seccomp/seccomp.go, и для seccomp профиля по определению проводит похожие операции, так что, наверное, мы нашли наш ответ!

В Docker --cap-add способен на большее, чем сказано


В итоге, похоже, --cap-add делает не совсем то, что написано на главной странице, и скорее должен выглядеть как --cap-add-and-also-whitelist-some-extra-system-calls-if-required. И это похоже на правду: если у вас есть привилегия в духе CAP_SYS_PTRACE, которая разрешает вам пользоваться системным вызовом process_vm_readv, но этот вызов блокируется профилем seccomp, вам это мало чем поможет, так что разрешение на использование системных вызовов process_vm_readv и ptrace через CAP_SYS_PTRACE выглядит разумно.

Оказывается, strace работает в последних версиях Docker


Для версий ядра 4.8 и выше благодаря этому коммиту в Docker 19.03 наконец-то разрешены системные вызовы ptrace. Вот только на моем ноутбуке Docker все еще версии 18.09.7, и этот коммит, очевидно, отсутствует.

Вот и все!


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

Если вам понравился этот пост, вам может понравиться и мой журнал How Containers Work, на его 24 страницах объясняются особенности ядра Linux по организации работы контейнеров. Там же вы можете ознакомиться с привилегиями и seccomp-bpf.
Подробнее..

Советы и рекомендации по преобразованию неструктурированных данных из логов в ELK Stack используя GROK в LogStash

05.07.2020 14:08:58 | Автор: admin

Структурирование неструктурированных данных с помощью GROK


Если вы используете стек Elastic (ELK) и заинтересованы в сопоставлении пользовательских журналов Logstash с Elasticsearch, то этот пост для вас.



Стек ELK это аббревиатура для трех проектов с открытым исходным кодом: Elasticsearch, Logstash и Kibana. Вместе они образуют платформу управления журналами.


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

Beats появился позже и является легким грузоотправителем данных. Введение Beats преобразовало Elk Stack в Elastic Stack, но это не главное.


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



Grok-это фильтр внутри Logstash, который используется для разбора неструктурированных данных на что-то структурированное и подлежащее запросу. Он находится поверх регулярного выражения (regex) и использует текстовые шаблоны для сопоставления строк в файлах журналов.


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


Без Grok ваши данные журнала Неструктурированы



Без Grok, когда журналы отправляются из Logstash в Elasticsearch и визуализируются в Kibana, они появляются только в значении сообщения.


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


Неструктурированные данные из логов


localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0

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


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


Структурированный вид наших данных


  • localhost == environment
  • GET == method
  • /v2/applink/5c2f4bb3e9fda1234edc64d == url
  • 400 == response_status
  • 46ms == response_time
  • 5bc6e716b5d6cb35fc9687c0 == user_id

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


Шаблоны Grok


Встроенные шаблоны Grok


Logstash поставляется с более чем 100 встроенными шаблонами для структурирования неструктурированных данных. Вы определенно должны воспользоваться этим преимуществом, когда это возможно для общих системных журналов, таких как apache, linux, haproxy, aws и так далее.


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


Кастомные шаблоны Grok


Нужно пробовать, чтобы построить свой собственный шаблон Grok. Я использовал Grok Debugger и Grok Patterns.


Обратите внимание, что синтаксис шаблонов Grok выглядит следующим образом: %{SYNTAX:SEMANTIC}


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



Используя это открытие, я начал создавать свой собственный шаблон на отладчике Grok, используя синтаксис, найденный на странице Github Elastic.



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



Ссылка на отладчик Grok https://grokdebug.herokuapp.com/


Исходный текст:


localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0

Pattern:


%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}

То что получилось в итоге


{  "environment": [    [      "localhost"    ]  ],  "method": [    [      "GET"    ]  ],  "url": [    [      "/v2/applink/5c2f4bb3e9fda1234edc64d"    ]  ],  "response_status": [    [      "400"    ]  ],  "BASE10NUM": [    [      "400"    ]  ],  "response_time": [    [      "46ms"    ]  ],  "user_id": [    [      "5bc6e716b5d6cb35fc9687c0"    ]  ]}

Имея в руках шаблон Grok и сопоставленные данные, последний шаг добавить его в Logstash.


Обновление файла конфигурации Logstash.conf


На сервере, на котором вы установили стек ELK, перейдите к конфигурации Logstash:


sudo vi /etc/logstash/conf.d/logstash.conf

Вставьте изменения.


input {   file {    path => "/your_logs/*.log"  }}filter{  grok {    match => { "message" => "%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}"}  }}output {  elasticsearch {    hosts => [ "localhost:9200" ]  }}

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


sudo service logstash restartsudo service logstash status

Наконец, чтобы убедиться, что изменения вступили в силу, обязательно обновите индекс Elasticsearch для Logstash в Kibana!



С Grok ваши данные из логов структурированы!



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


Попробуйте дать Grok expressions шанс! Если у вас есть другой способ сделать это или у вас есть какие-либо проблемы с примерами выше, просто напишите комментарий ниже, чтобы сообщить мне об этом.


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


Ресурсы


https://www.elastic.co/blog/do-you-grok-grok


https://github.com/elastic/logstash/blob/v1.4.2/patterns/grok-patterns


https://grokdebug.herokuapp.com/

Подробнее..

Готовим PostgreSQL в эпоху DevOps. Опыт 2ГИС. Павел Молявин

07.07.2020 10:10:24 | Автор: admin


Всем привет! Меня зовут Павел! Я работаю в компанию 2ГИС. Наша компания это городской информационный справочник, навигационный сервис. Это очень хорошая штука, которая помогает жить в городе.




Работаю я в подразделении, которое занимается веб-разработкой. Команда моя называется Infrastructure & Operations, сокращенно IO. Мы занимаемся поддержкой инфраструктурой для веб-разработки. Предоставляем свои сервисы командам как сервис и решаем все проблемы внутри нашей инфраструктуры.



Stack, который мы используем, технологии очень разнообразные. В основном это Kubernetes, мы пишем на Golang, на Python, на Bash. Из баз данных мы используем Elasticsearch, используем Cassandra и, конечно, используем Postgres, потому что мы его очень любим, это один из базовых элементов нашей инфраструктуры.



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


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



Начнем с постановки задачи. У нас продуктовые команды пишут приложения. Количество приложений постоянно растет. Приложения раньше мы писали в основном на PHP, Python и на Java Scala. Потихоньку к нам незаметно вползли модные языки типа Golang, без Node.js тоже сейчас никуда, тем более во FrontEnd.


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



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



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



Команды у нас пытались использовать для установки Postgres и его настройки Ansible. Кто-то, более отважный, использовал Chef, у кого был с ним опыт работы.


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


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



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



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



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



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



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



И поскольку мы придерживаемся парадигмы: infrastructure as code, то мы решили, что наше решение будет выглядеть в виде деплоя. Мы решили написать его на общеизвестном в нашем подразделении инструменте. У нас это был Ansible. И еще мы немножко кое-что написали на Python и Bash мы тоже активно используем.


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



И поскольку мы используем корпоративный Gitlab, хотелось, чтобы все это работало через встроенные возможности Gitlab, через continuous integration, continuous delivery. Т. е. чтобы можно было нажать кнопку deploy в репозитории и через некоторое время появлялся бы рабочий кластер.


И теперь мы все эти элементы рассмотрим в отдельности.



Кластер PostgreSQL



  • Мы выбрали PostgreSQL 9.4. Это было примерно 3,5 года назад. Тогда как раз был 9.4 в baseline. 9.6, по-моему, только вышел или его еще не было, я точно не помню. Но мы достаточно быстро наше решение проапгрейдили до 9.6, т. е. оно стало его поддерживать.
  • Для обеспечения репликации мы не стали ничего выдумывать. Выбрали стандартный метод потоковую репликацию. Она наиболее надежная, наиболее известная. С ней особых проблем нет.
  • Для кластеризации мы выбрали менеджер репликации с псевдо HA. Это repmgr от 2ndQuadrant. В защиту repmgr могу сказать. В предыдущие два дня в него летели активно камни, что он не обеспечивает настоящий HA, у него нет фенсинга, но на самом деле за три года эксплуатации я могу сказать, что у нас не было ни одного инцидента, когда переключения failovers произошли неправильно или закончились ошибкой. Т. е. всегда repmgr переключал кластер по делу. Всегда обеспечивал нам надежность. Не без downtime, конечно. Примерно 2 минуты repmgr соображает, что нужно выполнить failover и после этого его выполняет.
  • Для repmgr мы написали кастомный failover_command. Это такая команда, которую repmgr выполняет, когда собирается провести failover, т. е. запромоутить нового мастера. Т. е. запускается специальный скрипт. Он идет на балансировщики, проверяет, что балансировщики работают, что они доступны с нового мастера. И после этого происходит переключение. Т. е. он выполняет failover, переписывает бэкенды на балансировщиках и после этого завершает свою работу. Соответственно, мы получаем нового мастера. И балансировщики подключены к новому мастеру.
  • С репликой в другом ДЦ. У нас основное место присутствия это Новосибирск. Несколько ДЦ в Новосибирске. Но есть площадка в Москве, поэтому нам нужно было обеспечить, чтобы две реплики находились в Москве. Сначала мы их добавили в кластер repmgr.

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



В итоге мы сделали вот такую схему, т. е. мы вытащили из repmgr ноды, которые находятся в Москве. Сделали из них обычный hot standby, не стали ничего выдумывать. Они у нас через restore забирают с бэкап-сервера архивы WALs. Соответственно, проблему лага мы не разрешили. Если у нас на мастере начинается активная работа, то понятно, что реплики в Москве немножко отстают.


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



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



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



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


Эти адреса балансируются в DNS через round robin, т. е. когда приложение подключается к кластеру, они получают либо виртуальный адрес первого балансировщика, либо виртуальный адрес второго балансировщика.


Адреса keepalive у нас получает PgBouncer. Отличный pooler, у нас с ним особых проблем нет. Он работает, не доставляет никаких неприятностей. Но у него есть одна проблема. У него бэкенд может быть только один и он должен смотреть на мастера. Поэтому мы поставили у него на бэкенде Pgpool. Нам он понравился тем, что он знает, где в кластере находится мастер, умеет балансировать запросы на чтение, на slave.



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



Мы избавились от Pgpool. PgBouncer смотреть теперь только на мастер. Деплой проставляет PgBouncerу бэкенд. И failover_command с будущего мастера переключает адрес бэкенда и делает мягкую перезагрузку PgBouncer. И таким образом PgBouncer всегда смотрит на мастер.


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



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


Соответственно, мы сделали такую же пару. Я тут один нарисовал, потому что он уже не влезал. Мы по такому же подобию сделали балансировщики на чтение. Только на бэкенде у PgBouncer поставили HAProxy, который с помощью специально скрипта ходит в кластер и точно знает, где у него находятся slave и отправляет по round robin запросы на них.


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



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



Взяли Barman.


  • Barman у нас делает бэкап базы через cron каждые два дня, когда нагрузка минимальная.
  • Также у нас через archive_command происходит архивация WAL-файлов к Barman, чтобы можно было PITR осуществлять.

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


Недостатки в этой схеме довольно стандартные:


  • Тот же самый archive_command.
  • И требуется очень много места, потому что WAL-файлы мы не сжимаем, потому что экономим процессор, экономим время, чтобы при восстановлении можно было максимально быстро восстановиться.


Мониторинг и логи



  • У нас используется в качестве мониторинга Prometheus. Он использует pool-модель сбора метрик. Т. е. он сам ходит к сервисам и спрашивает их метрики. Соответственно, нам для каждого компонента системы (а это почти все компоненты, которые не умеют отдавать метрики) пришлось найти соответствующий exporter, который будет собирать метрики и отдавать их Prometheus, либо написать самостоятельно.
  • Мы свои exporters пишем на Golang, на Python, на Bash.
  • Мы используем в основном стандартные exporters. Это Node exporter основной системный exporter; Postgres exporter, который позволяет собирать все метрики с Postgres; exporter для PgBouncer мы написали сами на Python. И мы написали еще кастомный Cgroups exporters на Golang. Он нам нужен для того, чтобы четко знать, какое количество ресурсов системных сервер баз данных потратил на обслуживание каждой базы.
  • Собираем мы все системные метрики: это память, процессор, загрузка дисков, загрузка сети.
  • И метрики всех компонентов. В exporterе для Postgres вообще ситуация такая, что вы сами exporterу пишите запросы, которые хотите выполнять в базе. И, соответственно, он вам выполняет их и формирует метрики. Т. е., в принципе, метрики, которые можете добыть из Postgres ограничены только вашей фантазией. Понятно, что нам важно собирать количество транзакций, количество измененных tuples, позицию WAL-файлов для того, чтобы отслеживать постоянно отставание, если оно есть. Обязательно нужно знать, что происходит на балансировщиках. Сколько сессий находятся в каком статусе. Т. е. все-все мы собираем в Prometheus.


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



Как в любой системе мониторинга у нас есть alerts. Alerts в Prometheus занимается AlertManager.



У нас написано большое количество alerts, касательно кластера. Т. е. мы всегда знаем, что у нас начался failover, что failover закончился, что failover закончился успешно или не успешно. И все эти вопросы мы обязательно мониторим. У нас есть alerts, которые либо сигналят нам в почту, либо сигналят в корпоративный Slack, либо звонят по телефону и говорят: Просыпайся, у тебя проблема!.


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


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



С логами у нас не очень богато. У нас в компании используется ELK stack для сбора логов, т. е. мы используем Elasticsearch, Kibana и LogStash. Соответственно, Postgres и все компоненты нашего решения складывают логи на диск в CSV-формате, а с диска их собирает Python Beaver. Есть такой проект. Он их собирает и отдает LogStash. LogStash обогащает какую-то информацию, добавляет информацию к какой команде относится кластер, какой кластер, в общем, вносит какую-то дополнительную информацию.


И после этого в Kibana можно легко логи просматривать и агрегировать, в общем, сортировать и все, что угодно делать.


Также команды нас попросили поставить Pgbadger. Это такая штука, которая позволяет легко и непринужденно анализировать, например, slow логи. Это основное, для чего они хотели эту штуку. Она написана на Perl. Она нам не очень понравилась, потому что под нее нужно было отдельный хост размещать. Мы его в итоге задвинули в Kubernetes. Он у нас работает в Kubernetes. Получает он логи из LogStash. LogStash отдает ему по HTTP логи и в Pgbadger потом можно просматривать, и искать свои медленные запросы. В общем, грустить и выяснять, как это починить.



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


Мы решили написать деплой на Ansible. Хотелось его сделать максимально повторяемым, максимально идемпотентным, чтобы его можно было использовать не только при первоначальном деплое, но и можно было использовать для эксплуатации. Мы хотели автоматизировать все операции, которые могут быть снаружи самого Postgres. В том числе изменение конфигурации в Postgresql.conf, чтобы все-все можно было делать через деплой. Чтобы всегда были версии, чтобы всегда четко можно было по истории репозитория отследить что происходило, и кто вносил изменения.



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


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


И нам пришлось все роли локализовать. Т. е. те, которые раньше мы доставали из интернета, мы их локализовали, потому что Роскомнадзор довольно активизировался. Он постоянно банит хосты GitHub, поэтому мы решили не тащить роли снаружи. И все роли у нас лежат локально в наших репозиториях.


Также мы использовали встроенную возможность Ansible. Это использование для деплоя разные окружения. Т. е. по дефолту в нашем деплое есть testing, production и staging. Под staging мы понимаем такой почти production, но без трафика пользователей. В принципе, используя встроенную возможность Ansible можно добавить какие угодно окружения. Если вам нужно два-три testing, чтобы протестировать какую-то фичу, то вы добавляете в дополнительный environments, добавляете переменные, нажимаете deploy. И после этого у вас есть рабочий кластер.


Ключи, пароли мы храним в секретах. Шифруем все Ansible Vault. Это встроенная в Ansible возможность.


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


Мы постарались автоматизировать все рутинные операции. Т. е. любое изменение конфигурации: добавление баз, добавление пользователей, добавление real only пользователей, добавление каких-то дополнительных штук в базу, изменение режима в балансировке, потому что у нас одна часть сервисов использует транзакционную балансировку, другой части нужны prepared statements, а они используют сессионную балансировку.


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


Деплой у нас лежит в виде Git-репозитории, как я уже говорил, в нашем внутреннем Gitlab.


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


Также мы написали кастомную обвязку для развертывания кластера в OpenStack. Это очень удобно. Особенно, если вам нужна куча тестингов. Мы можем использовать нативное Openstack API через модуль Ansible, либо через одну штуку в OpenStack, которая называется heat-api, которая позволяет шаблонами запускать машины по несколько штук. Это очень удобно. Если вам нужно в ветке что-то потестировать, вы подключаете эту обвязку, которая позволяет через heat-api разворачивать машинки. Разворачиваете себе кластер. С ним работаете. После говорите: Мне это не надо. Удалить. Это все удаляется, т. е. виртуальные машинки в OpenStack удаляются. Все очень просто и удобно.


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



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



И последний пункт. Мы используем встроенные возможности Gitlab.



Gitlab умеет запускать специальные jobs. Jobs это отдельные шаги, которые выполняются.



Т. е. у нас отдельными шагами являются syntax check, деплой, тесты. Здесь у нас маленькая схема. После мержа в мастер автоматически запускается pipeline, который производит syntax check, деплоится на тестинг. На тестинге запускаются тесты. После этого, если все Ok, все зеленое, разблокируется ручной запуск деплоя staging и деплоя production.


Ручной запуск у нас сделан, чтобы люди, которые это делают, понимали, что они делают и отдавали отчет, что сейчас будет деплой на testing или на staging или на production.



Подведем итоги. Что же нам удалось? Мы хотели сделать такой инструмент, который будет нам все разворачивать, чтобы получить очень быстро рабочий кластер со всеми интеграциями. В принципе, нам это удалось. Такой деплой мы создали. Нам он очень помогает. Даже при не очень хороших обстоятельствах в течение 15 минут после начала нажатия кнопки deploy, вы получаете рабочий кластер. Вы можете заходить на endpoint и использовать в работе. Соответственно, команды могут его встраивать прямо в pipeline, т. е. полностью с ним работать.



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


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


Мы получили огромный опыт. Разобрались как работают rep managers, балансировка, репликация, Postgres. Это неоценимый опыт, всем советую.


Failover у нас работает. Failover, я бы не сказал, что происходит часто. За три года порядка десяти раз у нас был failover. Failover практически всегда по делу был.


Мы делаем вручную switchover, т. е. это failover вручную. Switchover мы делаем для всяких интересных штук. Например, когда нам нужно было перевести один из кластеров из одного ДЦ в другой, мы просто забутстрапили с помощью деплоя ноду в другом ДЦ. Сделали на нее switchover, переключили балансировщики. И тогда у нас появился рабочий мастер в новом ДЦ практически без downtime, только на время переключения. А для repmgr (Replication Manager) это, по-моему, две минуты дефолтные.



Без falls у нас тоже не обошлось:


  • Мы хотели сделать решение простым, чтобы команды могли его сами использовать. Но тут ничего не вышло. Все равно надо знать нюансы, как все работает внутри, все равно нужно понимать, как работает репликация, как работает rep managers. Именно поэтому количество форков нашего репозитория равно нулю. Команды не занимаются этим. Может быть, это и неплохо, потому что все проблемы мы бы решали.
  • Все равно для каждого кластера приходится что-то допиливать, дописывать. Не удается использовать один и тот же деплой.
  • И от ручных операций тоже не удалось избавиться. Все равно апгрейды, перезапуски Postgres, когда нужно внести какие-то изменения в postgresql.conf, приходится делать вручную. Потому что автоматике это можно доверить, но нужно понимать, что происходит. Без оператора не обойтись. Человек должен понимать, что он делает. Без ручных операций все равно не получается.
  • Обновление это отдельная боль. Это нужно все апгрейдить руками. Балансировщики, например, можно проапгрейдить автоматом, но будет downtime. А без автоматики вручную это можно сделать без downtime.
  • И мы не очень любим собирать пакеты, потому что на это тратится дополнительное время. Нужно делать инфраструктуру для сборки, инфраструктуру для pushes и репозиторий.


У нас в компании довольно активно развивается Kubernetes, поэтому есть ощущение попробовать что-нибудь новое. Например, попробовать запустить отказоустойчивый Postgres в Kubernetes. Для этого мы хотим посмотреть на Stolon, Patroni. Возможно, это будет первым, чем мы займемся.


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


И наше решение мы будем делать апгрейд на PostgreSQL 10-11. Я предвижу, что это будет очень веселое развлечение. Вызов принят, у нас вариантов нет, мы используем наше решение и будем апгрейдиться.




Вопросы


Спасибо за доклад! На разработку всех плейбуков в Ansible, сколько потратилось времени?


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


Какие-то были особенности именно внедрения Ansible в связке с Postgres, с вашим решением? Например, что-то пришлось кардинально перерабатывать?


Модули писать для Ansible?


Да.


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


Спасибо за доклад! Почему на Barman остановились? И насчет апгрейда у меня созрел вопрос еще в самом начале, когда про 9.6 рассказывали. Я увидел, что у вас есть планы на 10 и 11 версию, да?


Не знаю, но почему-то решили выбрать Barman. Он нам понравился тем, что конфигурируется нормально. Т. е. у нас была для него уже написанная роль в Ansible. Мы хотим посмотреть на что-нибудь другое, например, на WAL-G. Но проблема в том, насколько я помню, WAL-G не умеет в диск (Уточнение: уже умеет писать на диск). А у нас требование, чтобы все бэкапы и все-все лежали внутри инфраструктуры. А городить для этого отдельный S3, конечно, можно, но зачем?


Апгрейд мы делали вручную. Мы также подеплоили рядом кластер 9.6. В него смигрировали данные и все. И после этого выкинули 9.4 и у нас все стало хорошо.


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


Да.


По какому принципу новые кластера добавляются помимо staging?


Я понял вопрос. Мы все базы консолидировали в трех больших своих кластерах. У нас там есть testing, staging. И когда приложение работает уже на staging, мы можем понять, что что-то. Допустим, процессинговые базы, про которые я говорил. И такое пускать в кластер не понятно зачем, потому что будет постоянная нагрузка на WALs, будет постоянно большой бэкап. Потому что если бэкап пришел, пока у тебя процессинговая база лежит, ты получаешь . И, в принципе, по профилю нагрузки мы понимаем, что происходит внутри приложения. И после этого решаем дать отдельный кластер этим ребятам. И деплоим кластер, а что делать? Приложения в production все.


Здравствуйте! Спасибо за доклад! У меня немного двойной вопрос. Вы для половины части используете ванильные сборки Postgres?


Да.


Я сейчас тоже использую ванильные, но присматриваюсь к бесплатной части команды Postgres Professional, т. е. Postgres Pro Standard. И коснулась тема, что выбирать для резервного копирования. И них есть утилита pg_probackup, которая похожа на Barman, но у нее есть встроенная проверка бэкапов уже внутри. Почему вы не обратили внимание на эту утилиту?


Я даже не знаю, как вам правильно ответить. В принципе, мы как-то вообще не рассматривали Postgres Proшные штуки. Как-то так получилось. Мы привыкли, что мы сами с усами, строим свои велосипеды. Вроде бы у нас все работает.


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


Да.


Спасибо!


Спасибо большое!

Подробнее..

Как разогнать Parallels Desktop до космических скоростей

07.07.2020 12:09:02 | Автор: admin


С Parallels Desktop пользователи знакомы более 10 лет. До сих пор потребность в работе с Windows (у кого-то Linux) на Mac не теряет свою актуальность. Дизайнеры, бухгалтеры, геймеры, разработчики, музыканты, полицейские, список пользователей можно продолжать бесконечно.

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

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

Улучшение производительности виртуальной машины


Очень часто, в погоне за улучшением производительности виртуальной машины (ВМ) пользователи Parallels Desktop выделяют ей слишком много ресурсов. Разработчики не рекомендуют выделять более 50 % всех ресурсов Mac: ЦПУ и оперативной памяти. В ситуациях, когда виртуальная машина имеет больше ресурсов, чем сам Mac, начинаются проблемы с производительностью самого Mac, что в свою очередь негативно влияет на производительность виртуальной машины.

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

Parallels рекомендует использование SSD, т.к. от скорости диска напрямую зависит производительность Mac и виртуальной машины в результате. Альтернативой, при отсутствии внутреннего SSD диска, может быть использование внешнего высокоскоростного SSD накопителя при условии наличия у Mac высокоскоростного порта передачи данных (USB 3.0, Thunderbolt).

Управление обновлениями Windows


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

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

Режим поездки


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

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

Автоматическая видео память


Начиная с Parallels Desktop 14 для виртуальных машин Windows 8 и выше, в данном ПО появилась возможность использования автоматического режима для определения размера видеопамяти. С этим изменением размер видеопамяти определяется самой Windows исходя из собственных нужд и берется из оперативной памяти, выделенной на виртуальную машину. Это позволяет увеличить максимальный размер видео памяти более 2 Гб. В стандартных ситуациях размер видеопамяти равен примерно половине оперативной памяти виртуальной машины.

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

Интеграция Mac и Windows


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

На самом деле папки Рабочий Стол, Документы, Загрузки и прочее, доступные в Windows, являются ссылками на соответствующие папки Mac. Таким образом, не нужно копировать файлы в виртуальную машину, вы работаете с ними напрямую. То же самое касается и удаления файлов. Если Общий Профиль включен (настройка по умолчанию) то удаляя файл в папках Общего профиля в виртуальной машине вы удалите файл на Mac.

Так же, Parallels Desktop позволяет использовать программы установленные и на Mac и в Windows для открытия файлов на обеих сторонах. Т.е. вы можете использовать iTunes на Mac для воспроизведения музыки в Windows, щелкнув по файлу в Windows, и наоборот, начать смотреть видео используя Windows Media Player, щелкнув по файлу в Finder.

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

Категории

Последние комментарии

© 2006-2020, personeltest.ru