From 237904f0dfee59ffafeeb5d919562c6554d8c0cd Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Fri, 25 Jan 2013 00:28:00 +0400 Subject: [PATCH] Version v14.3 (2013-01-25 00:28) [AUTO] --- s4a.tex | 116 +++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 78 insertions(+), 38 deletions(-) diff --git a/s4a.tex b/s4a.tex index 509b242..6587b3f 100644 --- a/s4a.tex +++ b/s4a.tex @@ -14,7 +14,7 @@ \hypersetup{pdftitle={systemd для администраторов},% pdfauthor={Lennart Poettering, Sergey Ptashnick}} % Не засоряем оглавление подразделами -\setcounter{tocdepth}{1} +%\setcounter{tocdepth}{1} % А почему бы и нет? % Несколько сокращений \newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}} \newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}} @@ -3959,13 +3959,15 @@ CPUShares=1500 дистрибутиве (если это включение не~указать явно, данный файл будет проигнорирован). Далее, мы указываем тот параметр, который хотим изменить. Сохраняем файл, приказываем systemd перечитать конфигурацию, и перезапускаем Apache, чтобы -настройки вступили в силу\footnote{Прим. перев.: К сожалению, в настоящее время -systemd не~поддерживает изменение параметров контрольных групп без перезапуска -службы. Но вы можете узнать контрольную группу службы командой наподобие -+systemctl show -p ControlGroup avahi-daemon.service+, и выполнить настройки -любым удобным для вас способом, например, через запись значений в псевдофайлы -cgroupfs. Разумеется, при следующем запуске службы к ней будут применены -параметры, указанные в конфигурационном файле.}: +настройки вступили в силу\footnote{Прим. перев.: systemd версий до 197 +включительно, не~поддерживает изменение параметров контрольных групп без +перезапуска службы. Но вы можете узнать контрольную группу службы командой +наподобие +systemctl show -p ControlGroup avahi-daemon.service+, и выполнить +настройки любым удобным для вас способом, например, через запись значений в +псевдофайлы cgroupfs (разумеется, при следующем запуске службы к ней будут +применены параметры, указанные в конфигурационном файле). Начиная с systemd 198, +в программу +systemctl+ добавлена поддержка команд +set-cgroup-attr+, ++unset-cgroup-attr+ и +get-cgroup-attr+.}: \begin{Verbatim} systemctl daemon-reload systemctl restart httpd.service @@ -4297,16 +4299,21 @@ $ gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedes постоянно остается открытым для входящих соединений, и все они обрабатываются быстро и корректно. -Такая конфигурация позволяет снизить потребление ресурсов: службы работают и -потребляют ресурсы только тогда, когда это действительно необходимо. Многие -интернет-сайты и службы могут использовать это с выгодой для себя. Например, -хостеры веб-сайтов знают, что из огромного количества существующих в Интернете -сайтов лишь малая часть получает непрерывный поток запросов. Большинство же -сайтов, хотя и должны постоянно оставаться доступными, получают запросы очень -редко. Используя сокет-активацию, вы можете воспользоваться этим: разместив -множество таких сайтов на одной системе и активируя их службы только при -необходимости, вы получаете возможность <<оверкоммита>>: ваша система -будет обслуживать сайтов больше, чем формально позволяют ее ресурсы. Разумеется, +Такая конфигурация позволяет снизить потребление системных ресурсов: службы +работают и потребляют ресурсы только тогда, когда это действительно необходимо. +Многие интернет-сайты и службы могут использовать это с выгодой для себя. +Например, хостеры веб-сайтов знают, что из огромного количества существующих в +Интернете сайтов лишь малая часть получает непрерывный поток запросов. +Большинство же сайтов, хотя и должны постоянно оставаться доступными, получают +запросы очень редко. Используя сокет-активацию, вы можете воспользоваться этим: +разместив множество таких сайтов на одной системе и активируя их службы только +при необходимости, вы получаете возможность <<оверкоммита>>: ваша система будет +обслуживать сайтов больше, чем формально позволяют ее ресурсы\footnote{Прим. +перев.: Стоит отметить, что подобная схема работает только при условии, что для +каждого клиентского сайта запускаются отдельные процессы служб, хотя это и +происходит в рамках одного хоста. Не~очень распространенный в отчественном +хостинге вариант: обычно следующей опцией после shared-хостинга (одна служба на +всех клиентов) идет VPS (каждому клиенту по виртуальному хосту).}. Разумеется, увлекаться оверкоммитом не~стоит, иначе в моменты пиковой нагрузки ресурсов может действительно не~хватить. @@ -4319,14 +4326,19 @@ $ gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedes \hyperref[sec:instances]{экземплярами служб} позволяет подготовить универсальные шаблоны конфигурации служб, и в соответствии с ними для каждого сайта будет запускаться свой экземпляр службы. Кроме того, не~стоит забывать, -что systemd предоставляет \hyperref[sec:security]{богатый арсенал} +что systemd предоставляет \hyperref[sec:security]{внушительный арсенал} механизмов обеспечения безопасности и разграничения доступа, который позволит изолировать клиентские сайты друг от друга (например, службы каждого клиента будут видеть только его собственный домашний каталог, в то время как каталоги всех остальных пользователей будут им недоступны). Итак, в конечном итоге вы получаете надежную и масштабируемую серверную систему, на сравнительно небольших ресурсах которой функционирует множество безопасно изолированных друг от друга -служб~--- и все это реализовано штатными возможностями вашей ОС. +служб~--- и все это реализовано штатными возможностями вашей ОС\footnote{Прим. +перев.: В качестве практического примера использования сокет-активации служб +systemd в промышленных серверных платформах, можно предложить +\href{http://savanne.be/articles/deploying-node-js-with-systemd/}{вот эту +статью}, наглядно описывающую применение этой и других технологий (мониторинг, +использование Journal, ограничение ресурсов и доступа) на примере Node.js.}. Подобные конфигурации уже используются на рабочих серверах ряда компаний. В частности, специалисты из \href{https://www.getpantheon.com/}{Pantheon} @@ -4368,12 +4380,12 @@ systemd 197 (и, соответственно, с Fedora~19), мы добави в systemd простейшим контейнерным менеджером~--- \hyperref[sec:chroots]{systemd-nspawn}. Мы надеемся, что соответствующая возможность вскоре появится и в -\href{http://libvirt.org/drvlxc.html}{libvirt-lxc}. А пока рассмотрим -использование этого механизма на примере systemd-nspawn. +\href{http://libvirt.org/drvlxc.html}{libvirt-lxc}. А пока, за отсутствие +альтернатив, рассмотрим использование этого механизма на примере systemd-nspawn. Начнем с установки файлов ОС контейнера в выбранный каталог. Детальное рассмотрение этого вопроса выходит далеко за рамки нашего обсуждения, и -при этом детально рассмотрено во многих статьях и руководствах. Поэтому +при том детально рассмотрено во многих статьях и руководствах. Поэтому ограничусь лишь несколькими наиболее важными замечаниями. В частности, команда для установки Fedora будет выглядеть следующим образом: \begin{Verbatim} @@ -4399,7 +4411,7 @@ $ debootstrap --arch=amd64 unstable /srv/mycontainer/ Итак, ваш контейнер нормально загружается и работает. Подготовим для него service-файл, при помощи которого systemd сможет запускать и останавливать -виртуальное окружение. Для этого, создадим на хост системе файл +виртуальное окружение. Для этого, создадим на хост-системе файл +/etc/systemd/system/mycontainer.service+ со следующим содержанием: \begin{Verbatim} [Unit] @@ -4417,10 +4429,10 @@ KillMode=process корневой каталог у них один и тот же, пространства имен (например, списки процессов) у каждого будут свои. Впрочем, данная задача может быть решена утилитой +nsenter+, которая должна войти в следующий релиз util-linux -(предположительно, 2.23).}. Настроим на контейнере SSH-сервер, причем таким -образом, что подключение к его порту активировало весь контейнер, а затем -активировало сервер, работающий внутри. Начнем с того, что прикажем хосту -слушать порт SSH для контейнера. Для этого создадим на хосте файл +(предположительно, 2.23).}. Чтобы исправить это упущение, настроим на контейнере +SSH-сервер, причем таким образом, что подключение к его порту активировало весь +контейнер, а затем активировало сервер, работающий внутри. Начнем с того, что +прикажем хосту слушать порт SSH для контейнера. Для этого создадим на хосте файл +/etc/systemd/system/mycontainer.socket+: \begin{Verbatim} [Unit] @@ -4441,13 +4453,14 @@ ListenStream=23 nspawn. Впрочем, опытные администраторы легко могут найти обходные пути, например: присваивание хосту дополнительного IP-адреса (безо всякой виртуализации, командой +ip addr add+) и привязка слушающих сокетов к конкретным -адресам (в параметре +ListenStream=+ сокет-файлов или в директиве -+ListenAddress+ файла +sshd_config+).}. +адресам (в параметре +ListenStream=+ сокет-файлов и/или в директиве ++ListenAddress+ файла +sshd_config+ хоста).}. Пока что systemd, работающий внутри контейнера, не~знает, что делать с тем сокетами, которые ему передает systemd хоста. Если вы попробуете подключиться к порту 23, контейнер запустится, но сетевое соединение немедленно будет закрыто, -так как этому сокету не~соответствует пока никакой сервер. Давайте это исправим! +так как данному сокету не~соответствует пока никакой сервер. Давайте это +исправим! Настройка сокет-активации службы SSH была детально рассмотрена \hyperref[sec:inetd]{в одной из предыдущих статей}, поэтому ограничусь @@ -4503,15 +4516,24 @@ systemd начнет прослушивать TCP-порт 23. При подкл соединения экземпляр +sshd@.service+, что позволит нам залогиниться в контейнер по SSH. -Если нам нужно запуститьунтри контейнера другие службы с сокет-активацией, мы +Если нам нужно запуститьунтри контейнера другие службы с сокет-активацией, мы можем добавить в +mycontainer.socket+ дополнительные сокеты. Все они будут прослушиваться, обращение к любому из них приведет к активации контейнера, и все -они будут переданы контейнеру при его активации. Внутри контейнера они будут -обработаны соответствии с настройками имеющихся там сокет-юнитов. Те сокеты, для -которых соответствующих юнитов не~найдется, будут закрыты, а те сокеты, которые -будут настроены для прослушивания внутри контейнера, но не~получены от хоста, -будут активированы и доступны изнутри контейнера (а если это сетевые или -файловые unix-сокеты, то и извне). +эти сокеты будут переданы контейнеру при его активации. Внутри контейнера они +будут обработаны соответствии с настройками имеющихся там сокет-юнитов. Те +сокеты, для которых соответствующих юнитов не~найдется, будут +закрыты\footnote{Прим. перев.: Стоит особо отметить, что описанная технология +работает только для служб, поддерживающих сокет-активацию в режимах inetd (все +классические inetd-службы, кроме встроенных) или systemd (зависят от библиотеки ++libsystemd-daemon.so+, либо содержат в исходниках заголовочный файл ++sd-daemon.h+). Службы, которые сами открывают себе слушающий сокет и +не~содержат кода для приема уже открытого сокета, так активировать нельзя. +Точнее, в случае с сетевыми и файловыми сокетами, все-таки можно, но первое +соединение/сообщение при этом будет <<потрачено>> на запуск контейнера, и до +службы в итоге дойдут только последующие, начина со второго, что сводит выгоды +практически к нулю.}, а те сокеты, которые будут настроены для прослушивания +внутри контейнера, но не~получены от хоста, будут активированы и доступны +изнутри контейнера (а если это сетевые или файловые unix-сокеты, то и извне). Итак, давайте отступим чуть назад и полюбуемся на результаты наших трудов. Что мы получили в итоге? Возможность настраивать на одном хосте множество @@ -4539,6 +4561,24 @@ libvirt-lxc или nspawn, но не~c qemu/kvm или xen. \href{http://www.freedesktop.org/software/systemd/man/journalctl.html}{journalctl(1)}.}. Ловко, не~правда ли? +Необходимый минимум технологий для сокет-активации контейнеров, присутствует в +systemd, начиная с версии 197. Тем не~менее, наша работа в этой области еще +не~закончена, и в ближайшее время мы планируем доработать некоторые моменты. +Например, сейчас, даже если все серверные службы внутри контейнера +закончили обработку запросов и завершились, контейнер все равно продолжает +функционировать и потреблять ресурсы хоста. Мы просто обязаны реализовать +возможность автоматического завершения работы гостевой системы в такой ситуации. +Причем у нас уже есть готовые наработки в этой области~--- мы можем +задействовать уже существующую инфраструктуру, обеспечивающую автоматическое +засыпание/выключение ноутбука при отсутствии активных задач и пользователей. + +Впрочем, пора закругляться, а то статья получается чересчур длинной. Надеюсь, +что вы смогли продраться через все эти длинные и скучные рассуждения о +виртуализации, сокетах, службах, различных ОС и прочем колдунстве. Также +надеюсь, что эта статья станет хорошей отправной точкой при конфигурировании +мощных и хорошо масштабируемых серверных систем. За дополнительной информацией +обращайтесь к документации или приходите на наш IRC-канал. Спасибо за внимание! + \end{document} vim:ft=tex:tw=80:spell:spelllang=ru