Version v14.1 (2013-01-21 04:31) [AUTO]

s4a.tex

@@ -1117,6 +1117,7 @@ Apache, crond, atd, которые по роду служебной деятел
 +ln+.
 
 \section{Смена корня}
+\label{sec:chroots}
 
 Практически все администраторы и разработчики рано или поздно встречаются с
 \href{http://linux.die.net/man/1/chroot}{chroot-окружениями}. Системный вызов
@@ -2612,6 +2613,7 @@ systemd. Но, конечно, будет лучше, если этим займ
 приложения, или сопровождающие вашего дистрибутива.
 
 \section{К вопросу о безопасности}
+\label{sec:security}
 
 Одно из важнейших достоинств Unix-систем~--- концепция разделения привилегий
 между различными компонентами ОС. В частности, службы обычно работают от имени
@@ -4139,6 +4141,198 @@ ControlGroupAttribute=memory.swappiness 70
 и они не~так сильно ухудшают производительность. Возможно, мы рассмотрим их в
 последующих статьях.
 
+\section{Проверка на виртуальность}
+
+Еще в начале разработки systemd, мы внимательно изучали существовавшие на тот
+момент init-скрипты, выделяя наиболее типичные для них операции. Среди прочих, в
+составленный нами список попала и такая функция, как определение виртуализации:
+некоторые скрипты проверяли, запускаются они в виртуальном окружении (например,
+KVM, VMWare, LXC и т.д.) или на полноценной, физической системе. Часть этих
+скриптов отказывалась работать на виртуальных системах (например, службы
+управления устройствами совершенно излишни в виртуальных контейнерах, не~имеющих
+доступа к устройствам), другие же, наоборот, запускались только в определенных 
+виртуальных окружениях (например, всевозможные <<guest additions>>,
+рекомендуемые к запуску на гостевых системах VMWare и VirtualBox). По-хорошему,
+в некоторых ситуациях было бы более правильно проверять некоторые другие
+условия, а не~пытаться явно определить наличие виртуализации. Тем не~менее,
+всесторонне изучив вопрос, мы пришли к выводу, что во многих случаях
+возможность явной проверки такого условия при запуске служб была бы очень
+кстати. В результате, мы добавили поддержку соответствующей опции настройки
+юнитов~---
+\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{ConditionVirtualization};
+кроме того, мы создали небольшую утилиту, которую можно вызывать из
+скриптов~---
+\hreftt{http://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html}{systemd-detect-virt(1)};
+и наконец, мы предоставили простой интерфейс для шины D-Bus, позволяющий
+получить информацию о виртуализации даже непривилегированным программам. 
+
+Определить, запущен код на виртуальной системе, или на физической, на самом деле
+\href{http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/virt.c#n30}{не~так
+уж и сложно}. В зависимости от того, какие именно механизмы виртуализации вы
+хотите определить, основная работа сводится к выполнению инструкции CPUID и,
+возможно, проверке некоторых файлов в +/sys+ и +/proc+. Основная трудность
+здесь~--- точно знать строки, которые нужно искать. Список таких строк
+необходимо поддерживать в актуальном состоянии. В настоящий момент, systemd
+определяет следующие механизмы виртуализации:
+\begin{itemize}
+	\item Полная виртуализация (т.е. виртуальные машины):
+		\begin{itemize}
+			\item qemu
+			\item kvm
+			\item vmware
+			\item microsoft
+			\item oracle
+			\item xen
+			\item bochs
+		\end{itemize}
+	\item Виртуализация на уровне ОС (т.е. контейнеры):
+		\begin{itemize}
+			\item chroot
+			\item openvz
+			\item lxc
+			\item lxc-libvirt
+			\item \hyperref[sec:chroots]{systemd-nspawn}
+		\end{itemize}
+\end{itemize}
+
+Рассмотрим, как можно использовать эту функциональность.
+
+\subsection{Условия на запуск юнитов}
+
+При помощи опции
+\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{ConditionVirtualization},
+добавленной в секцию +[Unit]+ файла конфигурации юнита, вы можете обеспечить
+запуск (или наоборот, отмену запуска) данного юнита в зависимости от того,
+работает ли он на виртуальной системе, или нет. В случае утвердительного ответа,
+также можно уточнить, какая система виртуализации при этом используется.
+Например:
+\begin{Verbatim}
+[Unit]
+Name=My Foobar Service (runs only only on guests)
+ConditionVirtualization=yes
+
+[Service]
+ExecStart=/usr/bin/foobard
+\end{Verbatim}
+
+Помимо <<+yes+>> или <<+no+>>, вы также можете указать идентификатор конкретной
+системы виртуализации (согласно списку выше, например, <<+kvm+>>, <<+vmware+>> и
+т.д.), либо <<+container+>> или <<+vm+>> (что позволит отличить виртуализацию на
+уровне ОС от полной виртуализации). Кроме того, вы можете добавить перед
+значением восклицательный знак, и результат проверки будет инвертирован (юнит
+запустится только в том случае, если указанная технология
+\emph{не}~используется). Подробности вы можете узнать на
+\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{странице
+руководства}.
+
+\subsection{В скриптах}
+
+В скриптах оболочки вы можете выполнить аналогичные проверки при помощи утилиты
+\hreftt{http://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html}{systemd-detect-virt(1)}.
+Например:
+\begin{Verbatim}
+if systemd-detect-virt -q ; then
+        echo "Virtualization is used:" `systemd-detect-virt`
+else
+        echo "No virtualization is used."
+fi
+\end{Verbatim}
+
+Эта утилита возвращает код 0 (успех), обнаружив виртуализацию, или ненулевое
+значение, если виртуализация не~выявлена. Кроме того, она выводит идентификатор
+обнаруженной системы виртуализации (согласно списку выше), если это не~было
+запрещено опцией +-q+. Кроме того, опции +-c+ и +-v+ позволяют ограничить
+проверки только механизмами виртуализации на уровне ОС, либо полной
+виртуализации, соответственно. Подробности см. на
+\href{http://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html}{странице
+руководства}.
+
+\subsection{В программах}
+
+Информация о виртуализации также представлена на системной шине:
+\begin{Verbatim}
+$ gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1 \
+> --method org.freedesktop.DBus.Properties.Get org.freedesktop.systemd1.Manager Virtualization
+(<'systemd-nspawn'>,)
+\end{Verbatim}
+
+Если виртуализация не~выявлена, это свойство содержит пустую строку. Обратите
+внимание, что некоторые контейнерные системы не~могут быть обнаружены напрямую
+из непривилегированного кода. Именно поэтому мы не~стали создавать библиотеку, а
+воспользовались шиной D-Bus, которая позволяет корректно решить проблему
+привилегий.
+
+Стоит отметить, что все эти инструменты определяют только <<самый внутренний>>
+из задействованных механизмов виртуализации. Если вы используете несколько
+систем, вложенных друг в друга, вышеописанные инструменты обнаружат только ту, в
+которой они непосредственно запущены. В частности, если они работают в
+контейнере, находящемся внутри виртуальной машины, они увидят только контейнер.
+
+\section{Сокет-активация служб и контейнеров}
+
+\href{http://0pointer.de/blog/projects/socket-activation.html}{Сокет}-%
+\href{http://0pointer.de/blog/projects/socket-activation2.html}{активация}~---
+это одна из наиболее интересных возможностей systemd. Еще в
+\href{http://0pointer.de/blog/projects/systemd.html}{первом анонсе} нашего
+проекта мы рассказывали о том, как этот механизм улучшает
+параллелизацию и отказоустойчивость использующих сокеты служб, а также упрощает
+формирование зависимостей между службами при загрузке. В данной статье я
+продолжу рассказ о его возможностях~--- на этот раз речь пойдет об увеличении
+числа служб и контейнеров, работающих на одной и той же системе, без повышения
+потребления ресурсов. Другими словами: как можно увеличить количество клиентских
+сайтов на хостинговых серверах без затрат на новое оборудование.
+
+\subsection{Сокет-активация сетевых служб}
+
+Начнем с небольшого отступления. Итак, что же такое сокет-активация, и как она
+работает? На самом деле все довольно просто. systemd создает <<слушающие>>
+сокеты (не~обязательно IP) от имени вашей службы (которая пока не~запущена) и
+ожидает входящие соединения. Как только в сокет поступает первый запрос, systemd
+запускает службу и передает ей полученные данные. После обработки запроса, в
+зависимости от реализации службы, она может продолжать работу, ожидая новых
+соединений, или завершиться, переложив эту задачу обратно на systemd (который
+вновь запустит ее при поступлении очередного запроса). При этом, со стороны
+клиента невозможно отличить, когда служба запущена, а когда~--- нет. Сокет
+постоянно остается открытым для входящих соединений, и все они обрабатываются
+быстро и корректно.
+
+Такая конфигурация позволяет снизить потребление ресурсов: службы работают и
+потребляют ресурсы только тогда, когда это действительно необходимо. Многие
+интернет-сайты и службы могут использовать это с выгодой для себя. Например,
+хостеры веб-сайтов знают, что из огромного количества существующих в Интернете
+сайтов лишь малая часть получает непрерывный поток запросов. Большинство же
+сайтов, хотя и должны постоянно оставаться доступными, получают запросы очень
+редко. Используя сокет-активацию, вы можете воспользоваться этим: разместив
+множество таких сайтов на одной системе и активируя их службы только при
+необходимости, вы получаете возможность <<оверкоммита>>: ваша система
+будет обслуживать сайтов больше, чем формально позволяют ее ресурсы. Разумеется,
+увлекаться оверкоммитом не~стоит, иначе в моменты пиковой нагрузки ресурсов
+может действительно не~хватить.
+
+С помощью systemd вы без труда можете организовать такую схему. Множество
+современных сетевых служб уже поддерживают сокет-активацию <<из коробки>> (а в
+те, которые пока не~поддерживают, ее
+\href{http://0pointer.de/blog/projects/socket-activation.html}{не~так уж} и
+\href{http://0pointer.de/blog/projects/socket-activation2.html}{сложно}
+добавить). Используя встроенный в systemd механизм управления
+\hyperref[sec:instances]{экземплярами служб}, вы сможете подготовить
+универсальные шаблоны конфигурации служб, и в соответствии с ними для каждого
+сайта будет запускаться свой экземпляр службы. Кроме того, не~стоит забывать,
+что systemd предоставляет вам \hyperref[sec:security]{богатый арсенал}
+механизмов обеспечения безопасности и разграничения доступа, который позволит
+изолировать клиентские сайты друг от друга (например, службы каждого клиента
+будут видеть только его собственный домашний каталог, в то время как каталоги
+всех остальных пользователей будут им недоступны). Итак, в конечном итоге вы
+получаете надежную и масштабируемую серверную систему, на сравнительно небольших
+ресурсах которой функционирует множество безопасно изолированных друг от друга
+служб~--- и все это реализовано штатными возможностями вашей ОС.
+
+Подобные конфигурации уже используются на рабочих серверах ряда компаний. В
+частности, специалисты из \href{https://www.getpantheon.com/}{Pantheon}
+используют такую схему для обслуживания масштабируемой инфраструктуры множества
+сайтов на базе Drupal. (Стоит упомянуть, что заслуга ее внедрения в Pantheon
+принадлежит Дэвиду Штрауссу. Дэвид, ты крут!)
+
 \end{document}
 
 vim:ft=tex:tw=80:spell:spelllang=ru