0 - en to ru-RU translation catalogue (368 entries)

en: Preseeding
ru-RU: Пресидинг

en: Monitoring
ru-RU: Мониторинг

en: Virtualization
ru-RU: Виртуализация

en: Advanced Administration
ru-RU: Углублённое администрирование

en: This chapter revisits some aspects we already described, with a different perspective: instead of installing one single computer, we will study mass-deployment systems; instead of creating RAID or LVM volumes at install time, we'll learn to do it by hand so we can later revise our initial choices. Finally, we will discuss monitoring tools and virtualization techniques. As a consequence, this chapter is more particularly targeting professional administrators, and focuses somewhat less on individuals responsible for their home network.
ru-RU: Эта глава возвращается к некоторым аспектам, уже описанным ранее, но в другом ракурсе: вместо установки на одном компьютере мы изучим массовое разворачивание систем; вместо создания томов RAID или LVM во время установки мы научимся делать это вручную, чтобы иметь возможность пересмотреть наш изначальный выбор. Наконец, мы обсудим инструменты мониторинга и технологии виртуализации. Таким образом, эта глава предназначена главным образом для профессиональных администраторов и в несколько меньшей мере — для отдельных лиц, ответственных за свою домашнюю сеть.

en: RAID and LVM
ru-RU: RAID и LVM

en: RAID and LVM are both techniques to abstract the mounted volumes from their physical counterparts (actual hard-disk drives or partitions thereof); the former ensures the security and availability of the data in case of hardware failure by introducing redundancy, the latter makes volume management more flexible and independent of the actual size of the underlying disks. In both cases, the system ends up with new block devices, which can be used to create filesystems or swap space, without necessarily having them mapped to one physical disk. RAID and LVM come from quite different backgrounds, but their functionality can overlap somewhat, which is why they are often mentioned together.
ru-RU: И RAID, и LVM являются технологиями абстрагирования монтируемых томов от их физических эквивалентов (жёстких дисков или разделов на них); первая обеспечивает безопасность и доступность данных в случае аппаратных сбоев, добавляя избыточность, а вторая делает управление данными более гибким и независимым от реального размера физических дисков. В обоих случаях система получает новые блочные устройства, которые могут использоваться для создания файловых систем или пространства подкачки без обязательного размещения их на одном физическом диске. RAID и LVM возникли из разных нужд, но их функциональность может в чём-то перекрываться, поэтому их часто и упоминают вместе.

en: <emphasis>PERSPECTIVE</emphasis> Btrfs combines LVM and RAID
ru-RU: <emphasis>ПЕРСПЕКТИВА</emphasis> Btrfs сочетает LVM и RAID

en: Among the noteworthy features are the ability to take a snapshot of a filesystem tree at any point in time. This snapshot copy doesn't initially use any disk space, the data only being duplicated when one of the copies is modified. The filesystem also handles transparent compression of files, and checksums ensure the integrity of all stored data.
ru-RU: Среди примечательных особенностей — возможность создания снимков дерева файловой системы в любой момент времени. Этот снимок изначально не занимает места на диске, данные копируются только при изменении одной из копий. Файловая система также обеспечивает прозрачное сжатие файлов, а контрольные суммы гарантируют сохранность всех записанных данных.

en: In both the RAID and LVM cases, the kernel provides a block device file, similar to the ones corresponding to a hard disk drive or a partition. When an application, or another part of the kernel, requires access to a block of such a device, the appropriate subsystem routes the block to the relevant physical layer. Depending on the configuration, this block can be stored on one or several physical disks, and its physical location may not be directly correlated to the location of the block in the logical device.
ru-RU: В случае и RAID, и LVM ядро предоставляет файл блочного устройства, сходный с соответствующими жёсткому диску или разделу. Когда приложению или другой части ядра требуется доступ к блоку такого устройства, надлежащая подсистема передаёт блок соответствующему физическому слою. В зависимости от конфигурации этот блок может быть сохранён на одном или нескольких физических дисках, и его физическое расположение может не прямо соотноситься с расположением блока в логическом устройстве.

en: Software RAID
ru-RU: Программный RAID

en: RAID means <emphasis>Redundant Array of Independent Disks</emphasis>. The goal of this system is to prevent data loss and ensure availability in case of hard disk failure. The general principle is quite simple: data are stored on several physical disks instead of only one, with a configurable level of redundancy. Depending on this amount of redundancy, and even in the event of an unexpected disk failure, data can be losslessly reconstructed from the remaining disks.
ru-RU: RAID расшифровывается как <foreignphrase>Redundant Array of Independent Disks</foreignphrase> — избыточный массив независимых дисков. Цель этой системы — предотвратить потерю данных и гарантировать их доступность в случае сбоя жёсткого диска. Основной принцип прост: данные хранятся на нескольких физических дисках вместо одного, с настраиваемым уровнем избыточности, и даже в случае неожиданного выхода диска из строя данные могут быть без потерь восстановлены с остальных дисков.

en: <emphasis>CULTURE</emphasis> <foreignphrase>Independent</foreignphrase> or <foreignphrase>inexpensive</foreignphrase>?
ru-RU: <emphasis>КУЛЬТУРА</emphasis> <foreignphrase>Independent</foreignphrase> или <foreignphrase>inexpensive</foreignphrase>?

en: The I in RAID initially stood for <emphasis>inexpensive</emphasis>, because RAID allowed a drastic increase in data safety without requiring investing in expensive high-end disks. Probably due to image concerns, however, it is now more customarily considered to stand for <emphasis>independent</emphasis>, which doesn't have the unsavory flavor of cheapness.
ru-RU: I в аббревиатуре RAID изначально обозначала <emphasis>inexpensive</emphasis> — «недорогой», поскольку RAID позволял резко увеличить сохранность данных без необходимости инвестиций в дорогостоящие диски класса high-end. Возможно из соображений поддержания имиджа, однако, она сейчас чаще расшифровывается как <emphasis>independent</emphasis> — «независимый», что не имеет неприятного привкуса дешевизны.

en: RAID can be implemented either by dedicated hardware (RAID modules integrated into SCSI or SATA controller cards) or by software abstraction (the kernel). Whether hardware or software, a RAID system with enough redundancy can transparently stay operational when a disk fails; the upper layers of the stack (applications) can even keep accessing the data in spite of the failure. Of course, this “degraded mode” can have an impact on performance, and redundancy is reduced, so a further disk failure can lead to data loss. In practice, therefore, one will strive to only stay in this degraded mode for as long as it takes to replace the failed disk. Once the new disk is in place, the RAID system can reconstruct the required data so as to return to a safe mode. The applications won't notice anything, apart from potentially reduced access speed, while the array is in degraded mode or during the reconstruction phase.
ru-RU: RAID может быть реализован как в виде специального оборудования (модули RAID, встроенные в карты контроллеров SCSI или SATA), так и в виде программной абстракции (ядро). Как аппаратный, так и программный RAID с достаточной избыточностью может прозрачно продолжать работу, когда диск выходит из строя; верхние уровни стека (приложения) могут даже продолжать доступ к данным несмотря на сбой. Разумеется, такой «деградированный режим» может повлиять на производительность, а избыточность уменьшается, так что отказ следующего диска может привести к потере данных. На деле, однако, работать в этом деградированном режиме придётся лишь столько времени, сколько потребуется для замены отказавшего диска. Как только новый диск будет на месте, система RAID сможет восстановить необходимые данные для возврата в безопасный режим. Приложения не заметят ничего, кроме возможно снизившейся скорости доступа в то время, когда массив пребывает в деградированном состоянии, или на этапе восстановления.

en: When RAID is implemented by hardware, its configuration generally happens within the BIOS setup tool, and the kernel will consider a RAID array as a single disk, which will work as a standard physical disk, although the device name may be different (depending on the driver).
ru-RU: Когда RAID реализован аппаратно, его настройка в общем случае производится с помощью инструмента настройки BIOS, и ядро принимает RAID-массив за отдельный диск, который будет работать как обычный физический диск, хотя его имя может быть другим (в зависимости от драйвера).

en: We only focus on software RAID in this book.
ru-RU: В этой книге мы сосредоточимся исключительно на программном RAID.

en: Different RAID Levels
ru-RU: Разные уровни RAID

en: RAID is actually not a single system, but a range of systems identified by their levels; the levels differ by their layout and the amount of redundancy they provide. The more redundant, the more failure-proof, since the system will be able to keep working with more failed disks. The counterpart is that the usable space shrinks for a given set of disks; seen the other way, more disks will be needed to store a given amount of data.
ru-RU: RAID представляет собой не единую систему, а набор систем, различаемых по их уровням; уровни отличаются по схеме размещения данных и по степени избыточности. Более избыточный является более отказоустойчивым, поскольку система сможет продолжить работу с бо́льшим числом вышедших из строя дисков. С другой стороны, доступное пространство для того же набора дисков уменьшается; другими словами, для хранения того же объёма данных потребуется больше дисков.

en: Even though the kernel's RAID subsystem allows creating “linear RAID”, this is not proper RAID, since this setup doesn't involve any redundancy. The kernel merely aggregates several disks end-to-end and provides the resulting aggregated volume as one virtual disk (one block device). That is about its only function. This setup is rarely used by itself (see later for the exceptions), especially since the lack of redundancy means that one disk failing makes the whole aggregate, and therefore all the data, unavailable.
ru-RU: Хотя RAID-подсистема ядра позволяет создавать так называемый «linear RAID», собственно RAID он не является, поскольку не подразумевает какой-либо избыточности. Ядро просто объединяет несколько дисков «встык» и представляет получившийся том как один виртуальный диск (одно блочное устройство). Это единственное его назначение. Такая настройка редко используется сама по себе (об исключениях см. ниже), главным образом потому что отсутствие избыточности означает, что сбой одного диска делает всё объединение и, соответственно, все данные, недоступными.

en: This level doesn't provide any redundancy either, but disks aren't simply stuck on end one after another: they are divided in <emphasis>stripes</emphasis>, and the blocks on the virtual device are stored on stripes on alternating physical disks. In a two-disk RAID-0 setup, for instance, even-numbered blocks of the virtual device will be stored on the first physical disk, while odd-numbered blocks will end up on the second physical disk.
ru-RU: Этот уровень также не обеспечивает избыточности, но диски не просто соединяются один за другим : они разделяются на <emphasis>полосы</emphasis>, и блоки виртуального устройства сохраняются на полосах физических дисков поочерёдно. В двухдисковом RAID-0, например, чётные блоки виртуального устройства будут сохраняться на первом физическом диске, а нечётные разместятся на втором физическом диске.

en: This system doesn't aim at increasing reliability, since (as in the linear case) the availability of all the data is jeopardized as soon as one disk fails, but at increasing performance: during sequential access to large amounts of contiguous data, the kernel will be able to read from both disks (or write to them) in parallel, which increases the data transfer rate. The disks are utilized entirely by the RAID device, so they should have the same size not to lose performance.
ru-RU: Целью такой системы является не повышение надёжности, поскольку (как и в случае с linear) доступность всех данных оказывается под угрозой, как только один из дисков отказывает, а увеличение производительности: при последовательном доступе к большому объёму непрерывных данных ядро сможет читать с обоих дисков (или производить запись на них) параллельно, что увеличит скорость передачи данных. Диски используются RAID-устройством полностью, поэтому они должны быть одинакового размера, чтобы не терять производительности.

en: RAID-0 use is shrinking, its niche being filled by LVM (see later).
ru-RU: RAID-0 используется всё реже, его ниша сейчас занимается LVM (см. ниже).

en: This level, also known as “RAID mirroring”, is both the simplest and the most widely used setup. In its standard form, it uses two physical disks of the same size, and provides a logical volume of the same size again. Data are stored identically on both disks, hence the “mirror” nickname. When one disk fails, the data is still available on the other. For really critical data, RAID-1 can of course be set up on more than two disks, with a direct impact on the ratio of hardware cost versus available payload space.
ru-RU: Этот уровень, также известный как «зеркальный RAID», является одновременно и самым простым, и самым широко используемым. В своём стандартном виде он использует два физических диска одного размера и предоставляет логический том опять-таки того же размера. Данные хранятся одинаково на обоих дисках, отсюда и название «зеркало». Когда один диск выходит из строя, данные по-прежнему доступны с другого. Для действительно ценных данных RAID-1, конечно, может быть настроен на более чем двух дисках, с пропорциональным увеличением отношения цены оборудования к доступному пространству.

en: <emphasis>NOTE</emphasis> Disks and cluster sizes
ru-RU: <emphasis>ПРИМЕЧАНИЕ</emphasis> Размеры дисков и кластера

en: If two disks of different sizes are set up in a mirror, the bigger one will not be fully used, since it will contain the same data as the smallest one and nothing more. The useful available space provided by a RAID-1 volume therefore matches the size of the smallest disk in the array. This still holds for RAID volumes with a higher RAID level, even though redundancy is stored differently.
ru-RU: Если два диска разного размера настроены зеркалом, больший из них будет использоваться не полностью, поскольку он будет содержать те же данные, что и меньший, и ничего сверх этого. Таким образом доступное полезное пространство, предоставляемое томом RAID-1, соответствует размеру меньшего диска в массиве. Это справедливо и для томов RAID более высокого уровня, хотя избыточность в них реализована другим образом.

en: It is therefore important, when setting up RAID arrays (except for RAID-0 and “linear RAID”), to only assemble disks of identical, or very close, sizes, to avoid wasting resources.
ru-RU: По этой причине при настройке RAID-массивов (за исключением RAID-0 и «linear RAID») важно использовать диски идентичных или очень близких размеров, чтобы избежать пустой траты ресурсов.

en: <emphasis>NOTE</emphasis> Spare disks
ru-RU: <emphasis>ПРИМЕЧАНИЕ</emphasis> Резервные диски

en: RAID levels that include redundancy allow assigning more disks than required to an array. The extra disks are used as spares when one of the main disks fails. For instance, in a mirror of two disks plus one spare, if one of the first two disks fails, the kernel will automatically (and immediately) reconstruct the mirror using the spare disk, so that redundancy stays assured after the reconstruction time. This can be used as another kind of safeguard for critical data.
ru-RU: Уровни RAID, включающие избыточность, позволяют добавлять больше дисков, чем требуется для массива. Дополнительные диски используются в качестве резервных, когда один из основных дисков выходит из строя. К примеру, в зеркале из двух дисков с одним резервным при отказе одного из первых двух дисков ядро автоматически (и немедленно) восстанавливает зеркало с использованием резервного диска, так что избыточность остаётся на гарантированном уровне по истечении времени на восстановление. Это может быть использовано как ещё одна мера предосторожности для ценных данных.

en: One would be forgiven for wondering how this is better than simply mirroring on three disks to start with. The advantage of the “spare disk” configuration is that the spare disk can be shared across several RAID volumes. For instance, one can have three mirrored volumes, with redundancy assured even in the event of one disk failure, with only seven disks (three pairs, plus one shared spare), instead of the nine disks that would be required by three triplets.
ru-RU: Естественно может возникнуть вопрос, чем это лучше простого зеркалирования сразу на три диска. Преимущество конфигурации с резервным диском заключается в том, что резервный диск может быть общим для нескольких RAID-томов. Например, можно иметь три зеркальных тома с гарантированной избыточностью даже в случае сбоя одного диска, при наличии всего семи дисков (три пары плюс один общий резерв) вместо девяти, которые потребовались бы для трёх триплетов.

en: This RAID level, although expensive (since only half of the physical storage space, at best, is useful), is widely used in practice. It is simple to understand, and it allows very simple backups: since both disks have identical contents, one of them can be temporarily extracted with no impact on the working system. Read performance is often increased since the kernel can read half of the data on each disk in parallel, while write performance isn't too severely degraded. In case of a RAID-1 array of N disks, the data stays available even with N-1 disk failures.
ru-RU: Данный уровень RAID хотя и дорог (поскольку в лучшем случае используется только половина физического хранилища), но широко применяется на практике. Он прост для понимания и позволяет легко делать резервные копии: поскольку оба диска хранят одинаковое содержимое, один из них может быть временно извлечён без влияния на работающую систему. Скорость чтения часто возрастает, поскольку ядро может считывать половину данных с каждого диска одновременно, в то время как скорость записи существенно не уменьшается. В случае массива RAID-1 из N дисков данные остаются доступными даже при отказе N-1 диска.

en: This RAID level, not widely used, uses N disks to store useful data, and an extra disk to store redundancy information. If that disk fails, the system can reconstruct its contents from the other N. If one of the N data disks fails, the remaining N-1 combined with the “parity” disk contain enough information to reconstruct the required data.
ru-RU: Этот довольно редко применяемый уровень RAID, использует N дисков для хранения полезных данных и дополнительный диск для хранения избыточной информации. Если этот диск выходит из строя, система восстанавливает его содержимое с оставшихся N дисков. Если один из N дисков с данными отказывает, оставшиеся N-1 в сочетании с диском контроля чётности содержат достаточно информации для восстановления необходимых данных.

en: RAID-4 isn't too expensive since it only involves a one-in-N increase in costs and has no noticeable impact on read performance, but writes are slowed down. Furthermore, since a write to any of the N disks also involves a write to the parity disk, the latter sees many more writes than the former, and its lifespan can shorten dramatically as a consequence. Data on a RAID-4 array is safe only up to one failed disk (of the N+1).
ru-RU: RAID-4 не так дорог, поскольку приводит к увеличению цены только на один из N и не оказывает существенного влияния на скорость чтения, но запись замедляется. Кроме того, поскольку запись на любой из N дисков влечёт за собой запись на диск контроля чётности, на последний запись производится значительно чаще, и как следствие его время жизни существенно сокращается. Данные на массиве RAID-4 сохранны при отказе только одного диска (из N+1).

en: RAID-5 addresses the asymmetry issue of RAID-4: parity blocks are spread over all of the N+1 disks, with no single disk having a particular role.
ru-RU: RAID-5 нацелен на исправление асимметрии RAID-4: блоки контроля чётности распределяются по всем N+1 дискам, без выделения специального диска.

en: Read and write performance are identical to RAID-4. Here again, the system stays functional with up to one failed disk (of the N+1), but no more.
ru-RU: Скорость чтения и записи идентичны RAID-4. Опять-таки, система остаётся работоспособной только с одним отказавшим диском (из N+1), не более.

en: RAID-6 can be considered an extension of RAID-5, where each series of N blocks involves two redundancy blocks, and each such series of N+2 blocks is spread over N+2 disks.
ru-RU: RAID-6 можно считать расширением RAID-5, где каждая последовательность из N блоков предполагает два избыточных блока, и каждая последовательность из N+2 блоков распределяется по N+2 дискам.

en: This RAID level is slightly more expensive than the previous two, but it brings some extra safety since up to two drives (of the N+2) can fail without compromising data availability. The counterpart is that write operations now involve writing one data block and two redundancy blocks, which makes them even slower.
ru-RU: Этот уровень RAID несколько более дорогостоящ, чем предыдущие два, но он добавляет надёжности, поскольку до двух дисков (из N+2) могут выйти из строя без ущерба для доступа к данным. С другой стороны, операции записи теперь предполагают запись одного блока данных и двух избыточных блоков, что делает их ещё более медленными.

en: This isn't strictly speaking, a RAID level, but a stacking of two RAID groupings. Starting from 2×N disks, one first sets them up by pairs into N RAID-1 volumes; these N volumes are then aggregated into one, either by “linear RAID” or (increasingly) by LVM. This last case goes farther than pure RAID, but there is no problem with that.
ru-RU: Строго говоря, это не уровень RAID, а наложение двух группировок RAID. Начиная с 2×N дисков, первая собирает их попарно в тома RAID-1; эти N томов затем собираются в один при посредстве «linear RAID» или (всё чаще) LVM. Этот последний случай не является RAID в чистом виде, но это не создаёт проблем.

en: RAID-1+0 can survive multiple disk failures: up to N in the 2×N array described above, provided that at least one disk keeps working in each of the RAID-1 pairs.
ru-RU: RAID-1+0 может пережить выход из строя нескольких дисков: до N в массиве из 2×N, описанном выше, в случае если хотя бы один диск остаётся работоспособным в каждой паре RAID-1.

en: <emphasis>GOING FURTHER</emphasis> RAID-10
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> RAID-10

en: RAID-10 is generally considered a synonym of RAID-1+0, but a Linux specificity makes it actually a generalization. This setup allows a system where each block is stored on two different disks, even with an odd number of disks, the copies being spread out along a configurable model.
ru-RU: RAID-10 в общем случае считается синонимом RAID-1+0, но из-за специфики LINUX это на самом деле является обобщением. Эта установка позволяет создать систему, где каждый блок хранится на двух разных дисках, даже при нечётном числе дисков, и копии распределяются на основании изменяемой модели.

en: Performances will vary depending on the chosen repartition model and redundancy level, and of the workload of the logical volume.
ru-RU: Производительность будет изменяться в зависимости от выбранной модели распределения и степени избыточности, а также нагрузки на логический том.

en: Obviously, the RAID level will be chosen according to the constraints and requirements of each application. Note that a single computer can have several distinct RAID arrays with different configurations.
ru-RU: Безусловно, уровень RAID следует выбирать в соответствии с ограничениями и потребностями конкретного приложения. Учтите, что в одном компьютере может быть несколько отдельных RAID-массивов разных конфигураций.

en: Setting up RAID
ru-RU: Настройка RAID

en: Setting up RAID volumes requires the <emphasis role="pkg">mdadm</emphasis> package; it provides the <command>mdadm</command> command, which allows creating and manipulating RAID arrays, as well as scripts and tools integrating it to the rest of the system, including the monitoring system.
ru-RU: Настройка томов RAID требует пакета <emphasis role="pkg">mdadm</emphasis>; он предоставляет команду <command>mdadm</command>, с помощью которой можно создавать RAID-массивы и манипулировать ими, а также сценарии и инструменты для интеграции с остальными компонентами системы, в том числе с системами мониторинга.

en: Our example will be a server with a number of disks, some of which are already used, the rest being available to setup RAID. We initially have the following disks and partitions:
ru-RU: Для примера рассмотрим сервер с несколькими дисками, некоторые из которых уже используются, а другие доступны для создания RAID. Изначально у нас есть такие диски и разделы:

en: the <filename>sdb</filename> disk, 4 GB, is entirely available;
ru-RU: диск <filename>sdb</filename>, 4 ГБ, полностью доступен;

en: the <filename>sdc</filename> disk, 4 GB, is also entirely available;
ru-RU: диск <filename>sdc</filename>, 4 ГБ, также полностью доступен;

en: on the <filename>sdd</filename> disk, only partition <filename>sdd2</filename> (about 4 GB) is available;
ru-RU: на диске <filename>sdd</filename> доступен только раздел <filename>sdd2</filename> (около 4 ГБ);

en: finally, a <filename>sde</filename> disk, still 4 GB, entirely available.
ru-RU: наконец, диск <filename>sde</filename>, также 4 ГБ, полностью доступен.

en: <emphasis>NOTE</emphasis> Identifying existing RAID volumes
ru-RU: <emphasis>ЗАМЕТКА</emphasis> Идентификация существующих томов RAID

en: The <filename>/proc/mdstat</filename> file lists existing volumes and their states. When creating a new RAID volume, care should be taken not to name it the same as an existing volume.
ru-RU: В файл <filename>/proc/mdstat</filename> перечислены существующие тома и их состояние. При создании нового тома RAID следует быть осторожным, чтобы не дать ему имя, совпадающее с именем уже существующего тома.

en: We're going to use these physical elements to build two volumes, one RAID-0 and one mirror (RAID-1). Let's start with the RAID-0 volume:
ru-RU: Мы собираемся использовать эти физические носители для сборки двух томов, одного RAID-0 и одного зеркала (RAID-1). Начнём с тома RAID-0:

en: The <command>mdadm --create</command> command requires several parameters: the name of the volume to create (<filename>/dev/md*</filename>, with MD standing for <foreignphrase>Multiple Device</foreignphrase>), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on <filename>md0</filename> is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It is also possible to create named RAID arrays, by giving <command>mdadm</command> parameters such as <filename>/dev/md/linear</filename> instead of <filename>/dev/md0</filename>.
ru-RU: Команда <command>mdadm --create</command> требует нескольких параметров: имени создаваемого тома (<filename>/dev/md*</filename>, где MD расшифровывается как <foreignphrase>Multiple Device</foreignphrase>), уровня RAID, количества дисков (это обязательный параметр, хотя он и имеет значение только для RAID-1 и выше), и физические устройства для использования. Когда устройство создано, мы можем использовать его, как если бы это был обычный раздел: создавать файловую систему на нём, монтировать эту файловую систему и т. п. Обратите внимание, что создание тома RAID-0 под именем <filename>md0</filename> — не более чем совпадение, и нумерация массивов не обязана соответствовать выбранному уровню избыточности. Также можно создать именованные RAID-массивы, передавая <command>mdadm</command> такие параметры как <filename>/dev/md/linear</filename> вместо <filename>/dev/md0</filename>.

en: Creation of a RAID-1 follows a similar fashion, the differences only being noticeable after the creation:
ru-RU: RAID-1 создаётся сходным образом, различия заметны только после создания:

en: <emphasis>TIP</emphasis> RAID, disks and partitions
ru-RU: <emphasis>ПОДСКАЗКА</emphasis> RAID, диски и разделы

en: A few remarks are in order. First, <command>mdadm</command> notices that the physical elements have different sizes; since this implies that some space will be lost on the bigger element, a confirmation is required.
ru-RU: Здесь уместны несколько замечаний. Во-первых, <command>mdadm</command> предупреждает, что физические элементы имеют разные размеры; поскольку это подразумевает, что часть пространства на большем элементе будет потеряна, здесь требуется подтверждение.

en: More importantly, note the state of the mirror. The normal state of a RAID mirror is that both disks have exactly the same contents. However, nothing guarantees this is the case when the volume is first created. The RAID subsystem will therefore provide that guarantee itself, and there will be a synchronization phase as soon as the RAID device is created. After some time (the exact amount will depend on the actual size of the disks…), the RAID array switches to the “active” or “clean” state. Note that during this reconstruction phase, the mirror is in a degraded mode, and redundancy isn't assured. A disk failing during that risk window could lead to losing all the data. Large amounts of critical data, however, are rarely stored on a freshly created RAID array before its initial synchronization. Note that even in degraded mode, the <filename>/dev/md1</filename> is usable, and a filesystem can be created on it, as well as some data copied on it.
ru-RU: Что более важно, обратите внимание на состояние зеркала. Нормальное состояние зеркала RAID — когда содержимое двух дисков полностью идентично. Однако ничто не гарантирует этого, когда том только что создан. Поэтому подсистема RAID берёт эту гарантию на себя, и как только устройство RAID будет создано, начнётся этап синхронизации. Некоторое время спустя (точное его количество будет зависеть от размера дисков…) массив RAID переходит в состояние «active». Заметьте что на этом этапе восстановления зеркало находится в деградированном состоянии, и избыточность не гарантируется. Сбой диска в этот рискованный промежуток времени может привести к потере всех данных. Большие объёмы важных данных, однако, редко сохраняются на только что созданном RAID до конца начальной синхронизации. Отметьте, что даже в деградированном состоянии <filename>/dev/md1</filename> может использоваться, на нём можно создать файловую систему и скопировать в неё какие-то данные.

en: <emphasis>TIP</emphasis> Starting a mirror in degraded mode
ru-RU: <emphasis>СОВЕТ</emphasis> Запуск зеркала в деградированном состоянии

en: Sometimes two disks are not immediately available when one wants to start a RAID-1 mirror, for instance because one of the disks one plans to include is already used to store the data one wants to move to the array. In such circumstances, it is possible to deliberately create a degraded RAID-1 array by passing <filename>missing</filename> instead of a device file as one of the arguments to <command>mdadm</command>. Once the data have been copied to the “mirror”, the old disk can be added to the array. A synchronization will then take place, giving us the redundancy that was wanted in the first place.
ru-RU: Иногда два диска недоступны сразу, когда появляется желание создать зеркало RAID-1, например потому что один из дисков, которые планируется включить в зеркало, уже используется для хранения данных, которые необходимо перенести на массив. В таких случаях можно специально создать деградированный массив RAID-1, передав <filename>missing</filename> вместо файла устройства как один из аргументов <command>mdadm</command>. После того, как данные будут скопированы на «зеркало», старый диск можно добавить в массив. После этого начнётся синхронизация, которая и обеспечит нам избыточность, которой мы хотели добиться.

en: <emphasis>TIP</emphasis> Setting up a mirror without synchronization
ru-RU: <emphasis>СОВЕТ</emphasis> Настройка зеркала без синхронизации

en: RAID-1 volumes are often created to be used as a new disk, often considered blank. The actual initial contents of the disk is therefore not very relevant, since one only needs to know that the data written after the creation of the volume, in particular the filesystem, can be accessed later.
ru-RU: Тома RAID-1 часто создаются для использования в качестве нового диска, зачастую считающегося пустым. Начальное содержимое диска поэтому не особо важно, ведь необходимо обеспечить доступность только данных, записанных после создания тома, а именно файловой системы.

en: One might therefore wonder about the point of synchronizing both disks at creation time. Why care whether the contents are identical on zones of the volume that we know will only be read after we have written to them?
ru-RU: По этой причине можно усомниться в смысле синхронизации обоих дисков во время создания. Зачем беспокоиться об этом, если идентично содержимое тех областей тома, которые будут читаться только после того, как мы записали на них что-то?

en: Fortunately, this synchronization phase can be avoided by passing the <literal>--assume-clean</literal> option to <command>mdadm</command>. However, this option can lead to surprises in cases where the initial data will be read (for instance if a filesystem is already present on the physical disks), which is why it isn't enabled by default.
ru-RU: К счастью, этот этап синхронизации можно пропустить, передав опцию <literal>--assume-clean</literal> команде <command>mdadm</command>. Однако эта опция может повлечь неприятные сюрпризы в случаях, когда начальные данные будут читаться (например если на физических дисках уже присутствовала файловая система), поэтому она не включена по умолчанию.

en: Now let's see what happens when one of the elements of the RAID-1 array fails. <command>mdadm</command>, in particular its <literal>--fail</literal> option, allows simulating such a disk failure:
ru-RU: Теперь посмотрим, что происходит, когда один из элементов массива RAID-1 выходит из строя. <command>mdadm</command>, а точнее её опция <literal>--fail</literal>, позволяет симулировать такой отказ диска:

en: The contents of the volume are still accessible (and, if it is mounted, the applications don't notice a thing), but the data safety isn't assured anymore: should the <filename>sdd</filename> disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, <filename>sdf</filename>:
ru-RU: Содержимое тома по-прежнему доступно (и, если он смонтирован, приложения ничего не заметят), но сохранность данных больше не застрахована: если диск <filename>sdd</filename> в свою очередь выйдет из строя, данные будут потеряны. Мы хотим избежать такого риска, поэтому мы заменим отказавший диск новым, <filename>sdf</filename>:

en: Here again, the kernel automatically triggers a reconstruction phase during which the volume, although still accessible, is in a degraded mode. Once the reconstruction is over, the RAID array is back to a normal state. One can then tell the system that the <filename>sde</filename> disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:
ru-RU: Опять-таки, ядро автоматически запускает этап восстановления, на протяжении которого том, хотя и по-прежнему доступный, находится в деградированном состоянии. Когда восстановление завершается, массив RAID возвращается в нормальное состояние. Можно сказать системе, что диск <filename>sde</filename> следует удалить из массива, в результате чего получится классическое зеркало RAID на двух дисках:

en: From then on, the drive can be physically removed when the server is next switched off, or even hot-removed when the hardware configuration allows hot-swap. Such configurations include some SCSI controllers, most SATA disks, and external drives operating on USB or Firewire.
ru-RU: После этого диск может быть физически извлечён из сервера при следующем отключении, или даже из работающего сервера, если аппаратная конфигурация позволяет горячую замену. Такие конфигурации включают некоторые контроллеры SCSI, большинство SATA-дисков и внешние накопители, работающие через USB или Firewire.

en: Backing up the Configuration
ru-RU: Создание резервной копии настроек

en: Backing up the configuration is therefore important, if only for reference. The standard way to do it is by editing the <filename>/etc/mdadm/mdadm.conf</filename> file, an example of which is listed here:
ru-RU: Поэтому резервное копирование важно хотя бы для справки. Стандартный путь для этого — редактирование файла <filename>/etc/mdadm/mdadm.conf</filename>, пример которого приводится здесь:

en: <command>mdadm</command> configuration file
ru-RU: Конфигурационный файл <command>mdadm</command>

en: One of the most useful details is the <literal>DEVICE</literal> option, which lists the devices where the system will automatically look for components of RAID volumes at start-up time. In our example, we replaced the default value, <literal>partitions containers</literal>, with an explicit list of device files, since we chose to use entire disks and not only partitions, for some volumes.
ru-RU: Один из наиболее важных элементов здесь — опция <literal>DEVICE</literal>, в которой перечисляются устройства, на которых система будет автоматически искать компоненты томов RAID во время запуска. В нашем примере мы заменили значение по умолчанию, <literal>partitions containers</literal>, на явный список файлов устройств, поскольку мы выбрали использование целых дисков, а не только разделов, для некоторых томов.

en: The last two lines in our example are those allowing the kernel to safely pick which volume number to assign to which array. The metadata stored on the disks themselves are enough to re-assemble the volumes, but not to determine the volume number (and the matching <filename>/dev/md*</filename> device name).
ru-RU: Последние две строки в нашем примере позволяют ядру безопасно выбирать, какой номер тома какому массиву следует назначить. Метаданных, хранящихся на самих дисках, достаточно для пересборки томов, но не для определения номера тома (и соответствующего имени устройства <filename>/dev/md*</filename>).

en: Fortunately, these lines can be generated automatically:
ru-RU: К счастью, эти строки могут быть сгенерированы автоматически:

en: The contents of these last two lines doesn't depend on the list of disks included in the volume. It is therefore not necessary to regenerate these lines when replacing a failed disk with a new one. On the other hand, care must be taken to update the file when creating or deleting a RAID array.
ru-RU: Содержимое этих последних двух строк не зависит от списка дисков, входящих в том. Поэтому нет необходимости перегенерировать эти строки при замене вышедшего из строя диска новым. С другой стороны, следует аккуратно обновлять этот файл при создании или удалении массива RAID.

en: LVM, the <emphasis>Logical Volume Manager</emphasis>, is another approach to abstracting logical volumes from their physical supports, which focuses on increasing flexibility rather than increasing reliability. LVM allows changing a logical volume transparently as far as the applications are concerned; for instance, it is possible to add new disks, migrate the data to them, and remove the old disks, without unmounting the volume.
ru-RU: LVM, или <emphasis>менеджер логических томов</emphasis> ("Logical Volume Manager"), — другой подход к абстрагированию логических томов от их физических носителей, который фокусируется на увеличении гибкости, а не надёжности. LVM позволяет изменять логический том прозрачно для приложений; к примеру, можно добавить новые диски, перенести на них данные и удалить старые диски без отмонтирования тома.

en: LVM Concepts
ru-RU: Принципы работы LVM

en: This flexibility is attained by a level of abstraction involving three concepts.
ru-RU: Такая гибкость достигается за счёт уровня абстракции, включающего три понятия.

en: First, the PV (<emphasis>Physical Volume</emphasis>) is the entity closest to the hardware: it can be partitions on a disk, or a full disk, or even any other block device (including, for instance, a RAID array). Note that when a physical element is set up to be a PV for LVM, it should only be accessed via LVM, otherwise the system will get confused.
ru-RU: Первое, PV (<emphasis>физический том</emphasis> — "Physical Volume"), ближе всего к аппаратной стороне: это могут быть разделы на диске, целый диск или иное блочное устройство (в том числе и RAID-массив). Обратите внимание, что когда физический элемент настроен на использование в роли PV для LVM, доступ к нему должен осуществляться только через LVM, иначе система будет сбита с толку.

en: A number of PVs can be clustered in a VG (<emphasis>Volume Group</emphasis>), which can be compared to disks both virtual and extensible. VGs are abstract, and don't appear in a device file in the <filename>/dev</filename> hierarchy, so there is no risk of using them directly.
ru-RU: Несколько PV могут быть объединены в VG (<emphasis>группу томов</emphasis> — "Volume Group"), которую можно сравнить с виртуальными расширяемыми дисками. VG абстрактны и не имеют представления в виде файла в структуре иерархии <filename>/dev</filename>, так что риска использовать их напрямую нет.

en: The third kind of object is the LV (<emphasis>Logical Volume</emphasis>), which is a chunk of a VG; if we keep the VG-as-disk analogy, the LV compares to a partition. The LV appears as a block device with an entry in <filename>/dev</filename>, and it can be used as any other physical partition can be (most commonly, to host a filesystem or swap space).
ru-RU: Третий тип объектов — LV (<emphasis>логический том</emphasis> — "Logical Volume"), который является частью VG; если продолжить аналогию VG с диском, то LV соответствует разделу. LV представляется как блочное устройство в <filename>/dev</filename> и может использоваться точно так же, как и любой физический раздел (как правило — для размещения файловой системы или пространства подкачки).

en: The important thing is that the splitting of a VG into LVs is entirely independent of its physical components (the PVs). A VG with only a single physical component (a disk for instance) can be split into a dozen logical volumes; similarly, a VG can use several physical disks and appear as a single large logical volume. The only constraint, obviously, is that the total size allocated to LVs can't be bigger than the total capacity of the PVs in the volume group.
ru-RU: Важно, что разбиение VG на LV совершенно независимо от его физических компонент (PV). VG с единственным физическим компонентом (например диском) может быть разбита на десяток логических томов; точно так же VG может использовать несколько физических дисков и представляться в виде единственного большого логического тома. Единственным ограничением является то, что, само собой, общий размер, выделенный LV, не может быть больше, чем общая ёмкость всех PV в группе томов.

en: It often makes sense, however, to have some kind of homogeneity among the physical components of a VG, and to split the VG into logical volumes that will have similar usage patterns. For instance, if the available hardware includes fast disks and slower disks, the fast ones could be clustered into one VG and the slower ones into another; chunks of the first one can then be assigned to applications requiring fast data access, while the second one will be kept for less demanding tasks.
ru-RU: Часто, однако, имеет смысл использовать однородные физические компоненты в составе VG. К примеру, если доступны быстрые диски и более медленные, быстрые можно объединить в одну VG, а более медленные — в другую; порции первой можно выдавать приложениям, требующим быстрого доступа к данным, а вторую оставить для менее требовательных задач.

en: In any case, keep in mind that an LV isn't particularly attached to any one PV. It is possible to influence where the data from an LV are physically stored, but this possibility isn't required for day-to-day use. On the contrary: when the set of physical components of a VG evolves, the physical storage locations corresponding to a particular LV can be migrated across disks (while staying within the PVs assigned to the VG, of course).
ru-RU: В любом случае помните, что LV не закреплены за конкретным PV. Можно повлиять на то, где физически хранятся данные с LV, но эта возможность не требуется для повседневного использования. С другой стороны, когда набор физических компонентов VG меняется, физические места хранения, соответствующие конкретному LV, можно переносить между дисками (в пределах PV, закреплённых за VG, разумеется).

en: Setting up LVM
ru-RU: Настройка LVM

en: Let us now follow, step by step, the process of setting up LVM for a typical use case: we want to simplify a complex storage situation. Such a situation usually happens after some long and convoluted history of accumulated temporary measures. For the purposes of illustration, we'll consider a server where the storage needs have changed over time, ending up in a maze of available partitions split over several partially used disks. In more concrete terms, the following partitions are available:
ru-RU: Давайте пройдём шаг за шагом процесс настройки LVM для типичного случая: мы хотим упростить чрезмерно усложнённую ситуацию с хранилищами. Такое обычно получается в результате долгой и витиеватой истории накопления временных мер. Для иллюстрации возьмём сервер, на котором со временем возникала потребность в изменении хранилища, что в конечном итоге привело к путанице из доступных разделов, распределённых по нескольким частично используемым дискам. Если более конкретно, доступны следующие разделы:

en: on the <filename>sdb</filename> disk, a <filename>sdb2</filename> partition, 4 GB;
ru-RU: на диске <filename>sdb</filename> — раздел <filename>sdb2</filename>, 4 ГБ;

en: on the <filename>sdc</filename> disk, a <filename>sdc3</filename> partition, 3 GB;
ru-RU: на диске <filename>sdс</filename> — раздел <filename>sdс3</filename>, 3 ГБ;

en: the <filename>sdd</filename> disk, 4 GB, is fully available;
ru-RU: диск <filename>sdd</filename>, 4 ГБ, доступен полностью;

en: on the <filename>sdf</filename> disk, a <filename>sdf1</filename> partition, 4 GB; and a <filename>sdf2</filename> partition, 5 GB.
ru-RU: на диске <filename>sdf</filename> — раздел <filename>sdf1</filename>, 4 ГБ, и раздел <filename>sdf2</filename>, 5 ГБ.

en: In addition, let's assume that disks <filename>sdb</filename> and <filename>sdf</filename> are faster than the other two.
ru-RU: Кроме того, давайте считать, что диски <filename>sdb</filename> и <filename>sdf</filename> быстрее двух других.

en: Our goal is to set up three logical volumes for three different applications: a file server requiring 5 GB of storage space, a database (1 GB) and some space for back-ups (12 GB). The first two need good performance, but back-ups are less critical in terms of access speed. All these constraints prevent the use of partitions on their own; using LVM can abstract the physical size of the devices, so the only limit is the total available space.
ru-RU: Наша цель — настроить три логических тома для трёх разных приложений: файлового сервера, требующего 5 ГБ дискового пространства, базы данных (1 ГБ), и некоторое пространство для резервных копий (12 ГБ). Первым двум требуется хорошая производительность, а резервные копии менее критичны к скорости доступа. Все эти ограничения не позволяют разделы сами по себе; используя LVM, можно абстрагироваться от физического размера устройств, так что единственным ограничением является общее доступное пространство.

en: The required tools are in the <emphasis role="pkg">lvm2</emphasis> package and its dependencies. When they're installed, setting up LVM takes three steps, matching the three levels of concepts.
ru-RU: Необходимые инструменты находятся в пакете <emphasis role="pkg">lvm2</emphasis> и его зависимостях. После их установки настройка LVM проходит в три шага, соответствующих трём уровням организации.

en: First, we prepare the physical volumes using <command>pvcreate</command>:
ru-RU: Первым делом мы подготавливаем физические тома с помощью <command>pvcreate</command>:

en: So far, so good; note that a PV can be set up on a full disk as well as on individual partitions of it. As shown above, the <command>pvdisplay</command> command lists the existing PVs, with two possible output formats.
ru-RU: Пока всё идёт неплохо; отметим, что PV может быть размещён как на целом диске, так и на отдельном его разделе. Как показано выше, команда <command>pvdisplay</command> выводит список существующих PV, с двумя возможными форматами вывода.

en: Now let's assemble these physical elements into VGs using <command>vgcreate</command>. We'll gather only PVs from the fast disks into a <filename>vg_critical</filename> VG; the other VG, <filename>vg_normal</filename>, will also include slower elements.
ru-RU: Теперь давайте соберём эти физические элементы в VG с помощью <command>vgcreate</command>. Мы соберём PV с быстрых дисков в VG под названием <filename>vg_critical</filename>; другая VG, <filename>vg_normal</filename>, будет также включать более медленные элементы.

en: Here again, commands are rather straightforward (and <command>vgdisplay</command> proposes two output formats). Note that it is quite possible to use two partitions of the same physical disk into two different VGs. Note also that we used a <filename>vg_</filename> prefix to name our VGs, but it is nothing more than a convention.
ru-RU: И снова команды довольно просты (и <command>vgdisplay</command> предоставляет два формата вывода). Заметьте, что можно использовать два раздела одного физического диска в двух разных VG. Мы использовали приставку <filename>vg_</filename> в именах наших VG, но это не более чем соглашение.

en: We now have two “virtual disks”, sized about 8 GB and 12 GB respectively. Let's now carve them up into “virtual partitions” (LVs). This involves the <command>lvcreate</command> command, and a slightly more complex syntax:
ru-RU: Теперь у нас есть два «виртуальных диска» размером около 8 ГБ и 12 ГБ соответственно. Давайте разделим их на «виртуальные разделы» (LV). Для этого потребуется команда <command>lvcreate</command> и несколько более сложный синтаксис:

en: Two parameters are required when creating logical volumes; they must be passed to the <command>lvcreate</command> as options. The name of the LV to be created is specified with the <literal>-n</literal> option, and its size is generally given using the <literal>-L</literal> option. We also need to tell the command what VG to operate on, of course, hence the last parameter on the command line.
ru-RU: При создании логических томов обязательны два параметра; они должны быть переданы <command>lvcreate</command> как опции. Имя создаваемого LV указывается с опцией <literal>-n</literal>, а его размер обычно указывается с опцией <literal>-L</literal>. Конечно, нужно ещё указать имя VG, который следует использовать, отсюда последний параметр командной строки.

en: <emphasis>GOING FURTHER</emphasis> <command>lvcreate</command> options
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> Опции <command>lvcreate</command>

en: The <command>lvcreate</command> command has several options to allow tweaking how the LV is created.
ru-RU: У команды <command>lvcreate</command> есть ряд опций для тонкой настройки создания LV.

en: Let's first describe the <literal>-l</literal> option, with which the LV's size can be given as a number of blocks (as opposed to the “human” units we used above). These blocks (called PEs, <emphasis>physical extents</emphasis>, in LVM terms) are contiguous units of storage space in PVs, and they can't be split across LVs. When one wants to define storage space for an LV with some precision, for instance to use the full available space, the <literal>-l</literal> option will probably be preferred over <literal>-L</literal>.
ru-RU: Сначала опишем опцию <literal>-l</literal>, с которой размер LV может быть указан в виде числа блоков (в противоположность «человеческим» единицам, которые мы использовали выше). Эти блоки (называемые PE — <emphasis>физическими экстентами</emphasis>, "Physical Extents" — в терминологии LVM) являются непрерывными единицами хранения на PV, и они не могут быть распределены между LV. При необходимости указать пространство для LV с некоторой точностью, например для использования всего доступного пространства, опция <literal>-l</literal> может оказаться полезнее, чем <literal>-L</literal>.

en: It is also possible to hint at the physical location of an LV, so that its extents are stored on a particular PV (while staying within the ones assigned to the VG, of course). Since we know that <filename>sdb</filename> is faster than <filename>sdf</filename>, we may want to store the <filename>lv_base</filename> there if we want to give an advantage to the database server compared to the file server. The command line becomes: <command>lvcreate -n lv_base -L 1G vg_critical /dev/sdb2</command>. Note that this command can fail if the PV doesn't have enough free extents. In our example, we would probably have to create <filename>lv_base</filename> before <filename>lv_files</filename> to avoid this situation – or free up some space on <filename>sdb2</filename> with the <command>pvmove</command> command.
ru-RU: Также можно указать физическое размещение LV, чтобы его экстенты физически размещались на конкретном PV (разумеется, из числа выделенных для VG). Поскольку мы знаем, что <filename>sdb</filename> быстрее <filename>sdf</filename>, мы можем предпочесть записать <filename>lv_base</filename> туда, если хотим дать преимущество серверу баз данных по сравнению с файловым сервером. Командная строка будет выглядеть так: <command>lvcreate -n lv_base -L 1G vg_critical /dev/sdb2</command>. Обратите внимание, что эта команда может завершиться с ошибкой, если на PV недостаточно свободных экстентов. В нашем примере имеет смысл создать <filename>lv_base</filename> раньше <filename>lv_files</filename> чтобы избежать такой ситуации — или освободить немного места на <filename>sdb2</filename> с помощью команды <command>pvmove</command>.

en: Logical volumes, once created, end up as block device files in <filename>/dev/mapper/</filename>:
ru-RU: Созданные логические тома появляются как блочные устройства в <filename>/dev/mapper/</filename>:

en: <emphasis>NOTE</emphasis> Auto-detecting LVM volumes
ru-RU: <emphasis>ЗАМЕТКА</emphasis> Автоматическое определение томов LVM

en: When the computer boots, the <filename>lvm2-activation</filename> systemd service unit executes <command>vgchange -aay</command> to “activate” the volume groups: it scans the available devices; those that have been initialized as physical volumes for LVM are registered into the LVM subsystem, those that belong to volume groups are assembled, and the relevant logical volumes are started and made available. There is therefore no need to edit configuration files when creating or modifying LVM volumes.
ru-RU: Когда компьютер загружается, сервис systemd <filename>lvm2-activation</filename> запускает команду <command>vgchange -aay</command> чтобы «активировать» группы томов: она сканирует доступные устройства; те, которые были инициализированы как физические тома LVM, регистрируются в подсистеме LVM, принадлежащие к группам томов собираются, и соответствующие логические тома запускаются и делаются доступными. Поэтому нет необходимости редактировать конфигурационные файлы при создании или изменении томов LVM.

en: Note, however, that the layout of the LVM elements (physical and logical volumes, and volume groups) is backed up in <filename>/etc/lvm/backup</filename>, which can be useful in case of a problem (or just to sneak a peek under the hood).
ru-RU: Обратите внимание, однако, что резервная копия конфигурации элементов LVM (физических и логических томов и групп томов) сохраняется в <filename>/etc/lvm/backup</filename>, что может пригодиться при возникновении проблем (или просто чтобы мельком взглянуть под капот).

en: To make things easier, convenience symbolic links are also created in directories matching the VGs:
ru-RU: Для облегчения жизни также создаются символические ссылки в каталогах, соответствующих VG:

en: The LVs can then be used exactly like standard partitions:
ru-RU: LV можно использовать в точности как обычные разделы:

en: From the applications' point of view, the myriad small partitions have now been abstracted into one large 12 GB volume, with a friendlier name.
ru-RU: С точки зрения приложений, множество маленьких разделов теперь представлены в виде одного 12-гигабайтного тома с удобным именем.

en: LVM Over Time
ru-RU: Эволюция LVM

en: Even though the ability to aggregate partitions or physical disks is convenient, this is not the main advantage brought by LVM. The flexibility it brings is especially noticed as time passes, when needs evolve. In our example, let's assume that new large files must be stored, and that the LV dedicated to the file server is too small to contain them. Since we haven't used the whole space available in <filename>vg_critical</filename>, we can grow <filename>lv_files</filename>. For that purpose, we'll use the <command>lvresize</command> command, then <command>resize2fs</command> to adapt the filesystem accordingly:
ru-RU: Хотя возможность объединять разделы или физические диски и удобна, не она является главным преимуществом LVM. Её гибкость особенно заметна с течением времени, когда возникают потребности в изменениях. Допустим, что в нашем примере возникла потребность в сохранении новых больших файлов, и что LV, выделенный файловому серверу, слишком мал для них. Поскольку мы использовали не всё пространство, доступное на <filename>vg_critical</filename>, мы можем увеличить <filename>lv_files</filename>. Для этого мы используем команду <command>lvresize</command>, затем <command>resize2fs</command> чтобы соответствующим образом подогнать файловую систему:

en: <emphasis>CAUTION</emphasis> Resizing filesystems
ru-RU: <emphasis>ОСТОРОЖНО</emphasis> Изменение размера файловых систем

en: Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It is rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).
ru-RU: Размеры не всех файловых систем можно изменять во время работы; поэтому изменение размера тома может потребовать отмонтирования файловой системы в начале и обратного монтирования её в конце. Разумеется, при желании уменьшить пространство, выделенное под LV, файловая система должна быть уменьшена первой; при изменении размера в другом направлении порядок обратный: логический том должен быть увеличен прежде, чем файловая система на нём. Это вполне очевидно, ведь файловая система никогда не должна быть больше блочного устройства, на котором она размещается (будь это устройство физическим разделом или логическим томом).

en: The ext3, ext4 and xfs filesystems can be grown online, without unmounting; shrinking requires an unmount. The reiserfs filesystem allows online resizing in both directions. The venerable ext2 allows neither, and always requires unmounting.
ru-RU: Файловые системы ext3, ext4 и xfs могут быть увеличены онлайн, без размонтирования; уменьшение требует размонтирования. Файловая система reiserfs позволяет изменение размера онлайн в обоих направлениях. Преклонная ext2 не позволяет ни того, ни другого, и всегда должна быть отмонтирована.

en: We could proceed in a similar fashion to extend the volume hosting the database, only we've reached the VG's available space limit:
ru-RU: Мы могли бы, действуя тем же образом, расширить том, на котором размещается база данных, только мы достигли предела доступного места на VG:

en: <emphasis>GOING FURTHER</emphasis> Advanced LVM
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> Более подробно о LVM

en: LVM also caters for more advanced uses, where many details can be specified by hand. For instance, an administrator can tweak the size of the blocks that make up physical and logical volumes, as well as their physical layout. It is also possible to move blocks across PVs, for instance, to fine-tune performance or, in a more mundane way, to free a PV when one needs to extract the corresponding physical disk from the VG (whether to affect it to another VG or to remove it from LVM altogether). The manual pages describing the commands are generally clear and detailed. A good entry point is the <citerefentry><refentrytitle>lvm</refentrytitle> <manvolnum>8</manvolnum></citerefentry> manual page.
ru-RU: LVM угодит и более опытным пользователям, позволяя задавать вручную множество параметров. Например, администратор может настроить размер блоков, составляющих физические и логические тома, как и их физическое размещение. Также можно перемещать блоки между PV, к примеру для тонкой настройки производительности или, в более прозаичном случае, чтобы освободить PV, когда необходимо извлечь соответствующий физический диск из VG (чтобы присоединить его к другой VG или вовсе удалить из LVM). Страницы руководства, описывающие команды, в целом ясны и подробны. Для начала хорошо подойдёт страница <citerefentry><refentrytitle>lvm</refentrytitle> <manvolnum>8</manvolnum></citerefentry>.

en: RAID or LVM?
ru-RU: RAID или LVM?

en: RAID and LVM both bring indisputable advantages as soon as one leaves the simple case of a desktop computer with a single hard disk where the usage pattern doesn't change over time. However, RAID and LVM go in two different directions, with diverging goals, and it is legitimate to wonder which one should be adopted. The most appropriate answer will of course depend on current and foreseeable requirements.
ru-RU: Как RAID, так и LVM предоставляют бесспорные преимущества как только мы выходим за рамки простейшего случая настольного компьютера с одним жёстким диском, где схема использования не меняется с течением времени.

en: There are a few simple cases where the question doesn't really arise. If the requirement is to safeguard data against hardware failures, then obviously RAID will be set up on a redundant array of disks, since LVM doesn't really address this problem. If, on the other hand, the need is for a flexible storage scheme where the volumes are made independent of the physical layout of the disks, RAID doesn't help much and LVM will be the natural choice.
ru-RU: Есть несколько простых примеров, где вопрос выбора не встаёт. Если требуется защитить данные от аппаратных сбоев, безусловно следует создать RAID на избыточном дисковом массиве, ведь LVM просто не предназначен для решения этой проблемы. Если, с другой стороны, требуется гибкая система хранения, где тома не зависят от реальных физических дисков, RAID мало чем поможет, и естественно выбрать LVM.

en: <emphasis>NOTE</emphasis> If performance matters…
ru-RU: <emphasis>ЗАМЕТКА</emphasis> Если производительность имеет значение…

en: The third notable use case is when one just wants to aggregate two disks into one volume, either for performance reasons or to have a single filesystem that is larger than any of the available disks. This case can be addressed both by a RAID-0 (or even linear-RAID) and by an LVM volume. When in this situation, and barring extra constraints (for instance, keeping in line with the rest of the computers if they only use RAID), the configuration of choice will often be LVM. The initial set up is barely more complex, and that slight increase in complexity more than makes up for the extra flexibility that LVM brings if the requirements change or if new disks need to be added.
ru-RU: Третий характерный случай — когда хочется просто объединить два диска в один том из соображений производительности или чтобы иметь единую файловую систему, которая больше любого из доступных дисков. В этом случае подходят как RAID-0 (или даже linear-RAID), так и том LVM. В такой ситуации, если нет дополнительных ограничений (вроде унификации с другими компьютерами, на которых используется только RAID), более предпочтительным часто является выбор LVM. Начальная настройка несколько более сложна, но это небольшое увеличение сложности более чем покрывается дополнительной гибкостью, которую привнесёт LVM, если потребности изменятся, или если понадобится добавить новые диски.

en: Then of course, there is the really interesting use case, where the storage system needs to be made both resistant to hardware failure and flexible when it comes to volume allocation. Neither RAID nor LVM can address both requirements on their own; no matter, this is where we use both at the same time — or rather, one on top of the other. The scheme that has all but become a standard since RAID and LVM have reached maturity is to ensure data redundancy first by grouping disks in a small number of large RAID arrays, and to use these RAID arrays as LVM physical volumes; logical partitions will then be carved from these LVs for filesystems. The selling point of this setup is that when a disk fails, only a small number of RAID arrays will need to be reconstructed, thereby limiting the time spent by the administrator for recovery.
ru-RU: Ну и конечно, есть ещё по-настоящему интересный случай, когда систему хранения нужно сделать одновременно устойчивой к аппаратным сбоям и гибкой, когда дело доходит до выделения томов. Ни RAID, ни LVM не могут удовлетворить обоим требованиям сами по себе; не страшно, в этом случае мы используем их одновременно — точнее, одно поверх другого. Схема, включающая всё и ставшая стандартом с тех пор, как RAID и LVM достигли стабильности, заключается в обеспечении сначала избыточности группировкой дисков в небольшое число RAID-массивов и использовании этих массивов в качестве физических томов LVM; логические разделы будут потом выделяться из этих LV для файловых систем. Преимущество такой настройки заключается в том, что при отказе диска потребуется пересобрать только небольшое число RAID-массивов, тем самым экономя время, которое потребуется администратору на восстановление.

en: RAID-1 and LVM are combined to satisfy these constraints. The disks are attached to two different SATA controllers to optimize parallel access and reduce the risk of a simultaneous failure, and they therefore appear as <filename>sda</filename> and <filename>sdc</filename>. They are partitioned identically along the following scheme:
ru-RU: Чтобы удовлетворить этим требованиям, совмещены RAID-1 и LVM. Диски подключены к двум разным SATA-контроллерам для оптимизации параллельного доступа и снижения риска одновременного отказа, поэтому они представлены как <filename>sda</filename> и <filename>sdc</filename>. Они размечены одинаково по следующей схеме:

en: Once the VGs are created, they can be partitioned in a very flexible way. One must keep in mind that LVs created in <filename>vg_raid</filename> will be preserved even if one of the disks fails, which will not be the case for LVs created in <filename>vg_bulk</filename>; on the other hand, the latter will be allocated in parallel on both disks, which allows higher read or write speeds for large files.
ru-RU: После создания VG можно разбить их весьма гибким образом. Следует помнить, что LV, созданные на <filename>vg_raid</filename> будут сохранны даже если один из дисков выйдет из строя, чего нельзя сказать о LV, созданных на <filename>vg_bulk</filename>; с другой стороны, последние будут размещаться параллельно на обоих дисках, что обеспечит более высокие скорости чтения и записи больших файлов.

en: We will therefore create the <filename>lv_var</filename> and <filename>lv_home</filename> LVs on <filename>vg_raid</filename>, to host the matching filesystems; another large LV, <filename>lv_movies</filename>, will be used to host the definitive versions of movies after editing. The other VG will be split into a large <filename>lv_rushes</filename>, for data straight out of the digital video cameras, and a <filename>lv_tmp</filename> for temporary files. The location of the work area is a less straightforward choice to make: while good performance is needed for that volume, is it worth risking losing work if a disk fails during an editing session? Depending on the answer to that question, the relevant LV will be created on one VG or the other.
ru-RU: По этой причине мы создадим LV <filename>lv_var</filename> и <filename>lv_home</filename> на <filename>vg_raid</filename> для размещения соответствующих файловых систем; другой большой LV, <filename>lv_movies</filename>, будет использоваться для размещения окончательных версий роликов после редактирования. Другая VG будет разбита на большой <filename>lv_rushes</filename> для данных, захваченных с видеокамер, и <filename>lv_tmp</filename> для временных файлов. Размещение рабочей области — не такой простой выбор: в то время как для этого тома нужна хорошая производительность, стоит ли она риска потери работы, если диск выйдет из строя во время сессии? В зависимости от ответа на этот вопрос соответствующий LV следует создать на одной VG или на другой.

en: We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.
ru-RU: Теперь у нас есть некоторая избыточность для важных данных и большая гибкость в распределении доступного пространства между приложениями.

en: <emphasis>NOTE</emphasis> Why three RAID-1 volumes?
ru-RU: <emphasis>ПРИМЕЧАНИЕ</emphasis> Почему три тома RAID-1?

en: We could have set up one RAID-1 volume only, to serve as a physical volume for <filename>vg_raid</filename>. Why create three of them, then?
ru-RU: Мы могли ограничиться одним томом RAID-1 для размещения физического тома под <filename>vg_raid</filename>. Зачем же создавать три?

en: The rationale for the first split (<filename>md0</filename> vs. the others) is about data safety: data written to both elements of a RAID-1 mirror are exactly the same, and it is therefore possible to bypass the RAID layer and mount one of the disks directly. In case of a kernel bug, for instance, or if the LVM metadata become corrupted, it is still possible to boot a minimal system to access critical data such as the layout of disks in the RAID and LVM volumes; the metadata can then be reconstructed and the files can be accessed again, so that the system can be brought back to its nominal state.
ru-RU: Смысл первого разделения (<filename>md0</filename> от остальных) в обеспечении сохранности данных: данные, записанные на оба элемента зеркала RAID-1 в точности совпадают, поэтому можно обойти RAID и смонтировать один из дисков напрямую. В случае ошибки в ядре, например, или если метаданные LVM окажутся повреждены, всё равно можно загрузить минимальную систему для доступа к важным данным, таким как выделение дисков под RAID и LVM тома; метаданные можно восстановить и получить доступ к файлам снова, так что система может быть возвращена в рабочее состояние.

en: <primary>virtualization</primary>
ru-RU: <primary>виртуализация</primary>

en: Virtualization is one of the most major advances in the recent years of computing. The term covers various abstractions and techniques simulating virtual computers with a variable degree of independence on the actual hardware. One physical server can then host several systems working at the same time and in isolation. Applications are many, and often derive from this isolation: test environments with varying configurations for instance, or separation of hosted services across different virtual machines for security.
ru-RU: Виртуализация — это одно из крупнейших достижений вычислительной техники последних лет. Этот термин включает в себя различные абстракции и технологии имитации виртуальных компьютеров с разной степенью независимости от реального оборудования. На одном физическом сервере могут размещаться несколько систем, работающих одновременно и изолированных друг от друга. Приложений много, и зачастую они были бы невозможны без такой изоляции: к примеру, тестовые окружения с различными конфигурациями или разделение сервисов по разным виртуальным машинам для безопасности.

en: There are multiple virtualization solutions, each with its own pros and cons. This book will focus on Xen, LXC, and KVM, but other noteworthy implementations include the following:
ru-RU: Существует множество решений для виртуализации, каждое со своими достоинствами и недостатками. Эта книга сфокусируется на Xen, LXC и KVM, но есть и другие реализации, достойные упоминания:

en: Bochs is another free virtual machine, but it only emulates the x86 architectures (i386 and amd64).
ru-RU: Bochs — другая свободная виртуальная машина, но она эмулирует только архитектуры x86 (i386 и amd64).

en: <emphasis>HARDWARE</emphasis> Virtualization support
ru-RU: <emphasis>АППАРАТНОЕ ОБЕСПЕЧЕНИЕ</emphasis> Массовая виртуализация

en: Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.
ru-RU: Некоторые компьютеры могут не поддерживать аппаратную виртуализацию; в случае, когда она поддерживается, её следует включить в BIOS.

en: To know if you have virtualization support enabled, you can check if the relevant flag is enabled with <command>grep</command>. If the following command for your processor returns some text, you already have virtualization support enabled:
ru-RU: Чтобы узнать, включена ли поддержка виртуализации, можно проверить, включены ли соответствующие флаги, с помощью <command>grep</command>. Если следующая команда выводит некоторый текст, значит, поддержка виртуализации уже включена:

en: Xen <indexterm><primary>Xen</primary></indexterm> is a “paravirtualization” solution. It introduces a thin abstraction layer, called a “hypervisor”, between the hardware and the upper systems; this acts as a referee that controls access to hardware from the virtual machines. However, it only handles a few of the instructions, the rest is directly executed by the hardware on behalf of the systems. The main advantage is that performances are not degraded, and systems run close to native speed; the drawback is that the kernels of the operating systems one wishes to use on a Xen hypervisor need to be adapted to run on Xen.
ru-RU: Xen <indexterm><primary>Xen</primary></indexterm> — это решение для «паравиртуализации». Оно вводит тонкий слой абстракции, называемый «гипервизором», между оборудованием и вышележащими системами; он играет роль арбитра, контролирующего доступ к оборудованию из виртуальных машин. Однако он обрабатывает лишь немногие инструкции, остальные напрямую выполняются оборудованием от имени систем. Главное преимущество заключается в том, что производительность не страдает, и системы работают со скоростью, близкой к нативной; минусом является то, что ядра операционных систем, которые нужно запускать на гипервизоре Xen, должны быть адаптированы для этого.

en: Let's spend some time on terms. The hypervisor is the lowest layer, which runs directly on the hardware, even below the kernel. This hypervisor can split the rest of the software across several <emphasis>domains</emphasis>, which can be seen as so many virtual machines. One of these domains (the first one that gets started) is known as <emphasis>dom0</emphasis>, and has a special role, since only this domain can control the hypervisor and the execution of other domains. These other domains are known as <emphasis>domU</emphasis>. In other words, and from a user point of view, the <emphasis>dom0</emphasis> matches the “host” of other virtualization systems, while a <emphasis>domU</emphasis> can be seen as a “guest”.
ru-RU: Уделим немного времени терминологии. Гипервизор является нижним слоем, выполняющимся непосредственно на оборудовании, даже ниже ядра. Гипервизор может разделять остальное программное обеспечение по нескольким <emphasis>доменам</emphasis>, которые могут выглядеть как множество виртуальных машин. Один из этих доменов (первый, который запускается) известен как <emphasis>dom0</emphasis> и имеет особую роль, поскольку только этот домен может управлять гипервизором и исполнением других доменов. Эти другие домены известны как <emphasis>domU</emphasis>. Другими словами, с точки зрения пользователя <emphasis>dom0</emphasis> соответствует «хосту» в других системах виртуализации, а <emphasis>domU</emphasis> — «гостю».

en: <emphasis>CULTURE</emphasis> Xen and the various versions of Linux
ru-RU: <emphasis>КУЛЬТУРА</emphasis> Xen и разные версии Linux

en: Xen was initially developed as a set of patches that lived out of the official tree, and not integrated to the Linux kernel. At the same time, several upcoming virtualization systems (including KVM) required some generic virtualization-related functions to facilitate their integration, and the Linux kernel gained this set of functions (known as the <emphasis>paravirt_ops</emphasis> or <emphasis>pv_ops</emphasis> interface). Since the Xen patches were duplicating some of the functionality of this interface, they couldn't be accepted officially.
ru-RU: Xen изначально разрабатывался как набор заплат, живший вне официального дерева и не интегрированный в ядро Linux. В то же время некоторые развивающиеся системы виртуализации (включая KVM) требовали некоторых общих функций, связанных с виртуализацией, для облегчения их интеграции, и ядро Linux получило такой набор функций (известный как интерфейс <emphasis>paravirt_ops</emphasis> или <emphasis>pv_ops</emphasis>). Поскольку заплаты Xen дублировали часть функционала этого интерфейса, они не могли быть приняты официально.

en: Xensource, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0. <ulink type="block" url="https://wiki.xenproject.org/wiki/XenParavirtOps" />
ru-RU: Xensource, компания, стоящая за Xen, по этой причине должна была перенести Xen на этот новый каркас, чтобы заплаты Xen могли быть влиты в официальное ядро Linux. Это означало переписывание большого объёма кода, и хотя Xensource вскоре получила работающую версию, основанную на интерфейсе paravirt_ops, заплаты были лишь постепенно влиты в официальное ядро. Процесс закончился в Linux 3.0. <ulink type="block" url="https://wiki.xenproject.org/wiki/XenParavirtOps" />

en: Since <emphasis role="distribution">Jessie</emphasis> is based on version 3.16 of the Linux kernel, the standard <emphasis role="pkg">linux-image-686-pae</emphasis> and <emphasis role="pkg">linux-image-amd64</emphasis> packages include the necessary code, and the distribution-specific patching that was required for <emphasis role="distribution">Squeeze</emphasis> and earlier versions of Debian is no more. <ulink type="block" url="https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix" />
ru-RU: Поскольку <emphasis role="distribution">Jessie</emphasis> основан на версии 3.16 ядра Linux, стандартные пакеты <emphasis role="pkg">linux-image-686-pae</emphasis> и <emphasis role="pkg">linux-image-amd64</emphasis> включают необходимый код, и в наложении заплат, которые требовались для <emphasis role="distribution">Squeeze</emphasis> и более ранних версий Debian, более нет нужды. <ulink type="block" url="https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix" />

en: <emphasis>CULTURE</emphasis> Xen and non-Linux kernels
ru-RU: <emphasis>КУЛЬТУРА</emphasis> Xen и ядра, отличные от Linux

en: Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki: <ulink type="block" url="https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen" /> <ulink type="block" url="https://wiki.xenproject.org/wiki/DomU_Support_for_Xen" />
ru-RU: Xen требует изменений во всех операционных системах, которые хочется на нём запустить; не все ядра достигли полной функциональности в этом отношении. Многие полнофункциональны как dom0 и domU: Linux 3.0 и выше, NetBSD 4.0 и выше и OpenSolaris. Другие работают только как domU. Статус каждой операционной системы можно проверить в вики Xen: <ulink type="block" url="https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen" /> <ulink type="block" url="https://wiki.xenproject.org/wiki/DomU_Support_for_Xen" />

en: However, if Xen can rely on the hardware functions dedicated to virtualization (which are only present in more recent processors), even non-modified operating systems can run as domU (including Windows).
ru-RU: Однако если Xen может положиться на аппаратные функции виртуализации (которые наличествуют только в недавно выпущенных процессорах), даже немодифицированные операционные системы могут запускаться как domU (включая Windows).

en: <emphasis>NOTE</emphasis> Architectures compatible with Xen
ru-RU: <emphasis>ЗАМЕТКА</emphasis> Архитектуры, совместимые с Xen

en: Xen is currently only available for the i386, amd64, arm64 and armhf architectures.
ru-RU: Xen в настоящее время доступен только для архитектур i386, amd64, arm64 и armhf.

en: Using Xen under Debian requires three components:
ru-RU: Чтобы использовать Xen в Debian, нужны три компонента:

en: The i386 architecture also requires a standard library with the appropriate patches taking advantage of Xen; this is in the <emphasis role="pkg">libc6-xen</emphasis> package.
ru-RU: Для архитектуры i386 также требуется стандартная библиотека с заплатами, использующими Xen; она находится в пакете <emphasis role="pkg">libc6-xen</emphasis>.

en: Once these prerequisites are installed, the next step is to test the behavior of the dom0 by itself; this involves a reboot to the hypervisor and the Xen kernel. The system should boot in its standard fashion, with a few extra messages on the console during the early initialization steps.
ru-RU: Когда всё необходимое установлено, следующим шагом будет тестирование поведения самого dom0; оно включает перезагрузку в гипервизор и ядро Xen. Система должна загрузиться обычным образом, с несколькими дополнительными сообщениями в консоли на ранних стадиях инициализации.

en: Now is the time to actually install useful systems on the domU systems, using the tools from <emphasis role="pkg">xen-tools</emphasis>. This package provides the <command>xen-create-image</command> command, which largely automates the task. The only mandatory parameter is <literal>--hostname</literal>, giving a name to the domU; other options are important, but they can be stored in the <filename>/etc/xen-tools/xen-tools.conf</filename> configuration file, and their absence from the command line doesn't trigger an error. It is therefore important to either check the contents of this file before creating images, or to use extra parameters in the <command>xen-create-image</command> invocation. Important parameters of note include the following:
ru-RU: Теперь время собственно установить подходящие системы в domU с помощью инструментов из <emphasis role="pkg">xen-tools</emphasis>. Этот пакет предоставляет команду <command>xen-create-image</command>, которая в значительной мере автоматизирует задачу. Единственный обязательный параметр — <literal>--hostname</literal>, передающий имя domU; другие опции важны, но они могут быть сохранены в конфигурационном файле <filename>/etc/xen-tools/xen-tools.conf</filename>, и их отсутствие в командной строке не вызовет ошибки. Поэтому следует проверить содержимое этого файла перед созданием образов, или же использовать дополнительные параметры в вызове <command>xen-create-image</command>. Отметим следующие важные параметры:

en: <literal>--memory</literal>, to specify the amount of RAM dedicated to the newly created system;
ru-RU: <literal>--memory</literal> для указания количества ОЗУ, выделенного вновь создаваемой системе;

en: <literal>--size</literal> and <literal>--swap</literal>, to define the size of the “virtual disks” available to the domU;
ru-RU: <literal>--size</literal> и <literal>--swap</literal>, чтобы задать размер «виртуальных дисков», доступных для domU;

en: <emphasis>GOING FURTHER</emphasis> Installing a non-Debian system in a domU
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> Установка систем, отличных от Debian, в domU

en: In case of a non-Linux system, care should be taken to define the kernel the domU must use, using the <literal>--kernel</literal> option.
ru-RU: В случае системы, основанной не на Linux, следует быть аккуратным при указании ядра, которое должно использоваться domU, с помощью опции <literal>--kernel</literal>.

en: <literal>--dhcp</literal> states that the domU's network configuration should be obtained by DHCP while <literal>--ip</literal> allows defining a static IP address.
ru-RU: <literal>--dhcp</literal> объявляет, что конфигурация сети domU должна быть получена по DHCP, в то время как <literal>--ip</literal> позволяет задать статический IP-адрес.

en: Lastly, a storage method must be chosen for the images to be created (those that will be seen as hard disk drives from the domU). The simplest method, corresponding to the <literal>--dir</literal> option, is to create one file on the dom0 for each device the domU should be provided. For systems using LVM, the alternative is to use the <literal>--lvm</literal> option, followed by the name of a volume group; <command>xen-create-image</command> will then create a new logical volume inside that group, and this logical volume will be made available to the domU as a hard disk drive.
ru-RU: Наконец, следует выбрать метод хранения для создаваемых образов (тех, которые будут видны как жёсткие диски из domU). Самый простой метод, соответствующий опции <literal>--dir</literal>, заключается в создании одного файла на dom0 для каждого устройства, которое будет передано domU. Для систем, использующих LVM, альтернативой является использование опции <literal>--lvm</literal>, за которой указывается имя группы томов; в таком случае <command>xen-create-image</command> создаст новый логический том в этой группе, и этот логический том станет доступным для domU как жёсткий диск.

en: <emphasis>NOTE</emphasis> Storage in the domU
ru-RU: <emphasis>ЗАМЕТКА</emphasis> Хранилище в domU

en: Entire hard disks can also be exported to the domU, as well as partitions, RAID arrays or pre-existing LVM logical volumes. These operations are not automated by <command>xen-create-image</command>, however, so editing the Xen image's configuration file is in order after its initial creation with <command>xen-create-image</command>.
ru-RU: Целые жёсткие диски также могут быть экспортированы в domU, равно как разделы, RAID-массивы или ранее созданные логические тома LVM. Эти операции не автоматизированы <command>xen-create-image</command>, однако, поэтому требуется редактирование конфигурационного файла образа Xen после его создания с помощью <command>xen-create-image</command>.

en: Once these choices are made, we can create the image for our future Xen domU:
ru-RU: Когда выборы сделаны, мы можем создать образ для нашего будущего Xen domU:

en: We now have a virtual machine, but it is currently not running (and therefore only using space on the dom0's hard disk). Of course, we can create more images, possibly with different parameters.
ru-RU: Теперь у нас есть виртуальная машина, но она ещё не запущена (и поэтому только занимает место на жёстком диске dom0). Разумеется, мы можем создать больше образов, возможно с разными параметрами.

en: Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:
ru-RU: До включения этих виртуальных машин нам нужно определить, как будет получаться доступ к ним. Разумеется, они могут быть назначены изолированными машинами, доступными только через системную консоль, но это редко соответствует сценарию работы. Большую часть времени domU будет считаться удалённым сервером, и доступ к нему будет осуществляться только через сеть. Однако было бы весьма неудобным добавлять сетевую карту для каждого domU; по этой причине Xen позволяет создавать виртуальные интерфейсы, которые каждый домен может видеть и использовать обычным образом. Заметьте, что эти карты, хоть они и виртуальные, будут полезными только когда они подключены к сети, хотя бы виртуальной. У Xen есть несколько сетевых моделей для этого:

en: The simplest model is the <emphasis>bridge</emphasis> model; all the eth0 network cards (both in the dom0 and the domU systems) behave as if they were directly plugged into an Ethernet switch.
ru-RU: Простейшей является модель <emphasis>моста</emphasis>; все сетевые карты eth0 (как в dom0, так и в domU-системах) ведут себя, как если бы они были напрямую подключены к Ethernet-коммутатору.

en: Then comes the <emphasis>routing</emphasis> model, where the dom0 behaves as a router that stands between the domU systems and the (physical) external network.
ru-RU: Следующая модель — <emphasis>маршрутизируемая</emphasis>, когда dom0 ведёт себя как маршрутизатор, находящийся между domU-системами и (физической) внешней сетью.

en: Finally, in the <emphasis>NAT</emphasis> model, the dom0 is again between the domU systems and the rest of the network, but the domU systems are not directly accessible from outside, and traffic goes through some network address translation on the dom0.
ru-RU: Наконец, в модели <emphasis>NAT</emphasis> dom0 опять находится между domU-системами и остальной сетью, но domU-системы не доступны извне напрямую, и трафик проходит через преобразование адресов на dom0.

en: These three networking nodes involve a number of interfaces with unusual names, such as <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> and <filename>xenbr0</filename>. The Xen hypervisor arranges them in whichever layout has been defined, under the control of the user-space tools. Since the NAT and routing models are only adapted to particular cases, we will only address the bridging model.
ru-RU: Эти три сетевых режима включают различные интерфейсы с необычными именами, такими как <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> и <filename>xenbr0</filename>. Гипервизор Xen комбинирует их в соответствии с заданной схемой под контролем инструментов пространства пользователя. Поскольку NAT и маршрутизируемая модель приспособлены лишь для отдельных случаев, мы рассмотрим только модель моста.

en: After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the <command>xl</command> command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, <filename>/etc/xen/testxen.cfg</filename>). Here we have set it to 1024 (megabytes).
ru-RU: Перезагрузившись для проверки, что мост создаётся автоматически, мы можем запустить domU с помощью инструментов управления Xen, а именно команды <command>xl</command>. Эта команда позволяет производить различные манипуляции с доменами, в частности выводить их список, запускать их и останавливать. Может понадобиться увеличить объём памяти по умолчанию, отредактировав значение переменной memory в конфигурационном файле (в данном случае — <filename>/etc/xen/testxen.cfg</filename>). Здесь мы установили его в 1024 (мегабайт).

en: <emphasis>TOOL</emphasis> Choice of toolstacks to manage Xen VM
ru-RU: <emphasis>ИНСТРУМЕНТ</emphasis> Выбор набора инструментов для управления Xen

en: <emphasis>CAUTION</emphasis> Only one domU per image!
ru-RU: <emphasis>ОСТОРОЖНО</emphasis> Только один domU на образ!

en: While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the <filename>/home</filename> filesystem.
ru-RU: Хотя, безусловно, возможно запускать несколько domU-систем параллельно, каждая из них должна иметь свой собственный образ, ведь каждый domU создан, как если бы он работал на своём собственном оборудовании (за исключением маленькой части ядра, общающейся с гипервизором). В частности, две запущенных одновременно domU-системы не могут использовать общее хранилище. Если системы не запускаются одновременно, всё же возможно использовать для них один раздел подкачки или раздел, на котором размещается файловая система <filename>home</filename>.

en: Note that the <filename>testxen</filename> domU uses real memory taken from the RAM that would otherwise be available to the dom0, not simulated memory. Care should therefore be taken, when building a server meant to host Xen instances, to provision the physical RAM accordingly.
ru-RU: Заметьте, что domU <filename>testxen</filename> использует реальную память, взятую из ОЗУ, которая иначе была бы доступна dom0, а не виртуальную. Поэтому при сборке сервера для размещения машин Xen следует побеспокоиться об обеспечении достаточного объёма физического ОЗУ.

en: Voilà! Our virtual machine is starting up. We can access it in one of two modes. The usual way is to connect to it “remotely” through the network, as we would connect to a real machine; this will usually require setting up either a DHCP server or some DNS configuration. The other way, which may be the only way if the network configuration was incorrect, is to use the <filename>hvc0</filename> console, with the <command>xl console</command> command:
ru-RU: Voilà! Наша виртуальная машина запускается. Мы можем получить доступ к ней в одном из двух режимов. Обычный путь — подключаться к ней «удалённо» через сеть, как мы подключались бы к реальной машине; для этого обычно требуется настройка либо DHCP-сервера, либо DNS. Другой путь, который может стать единственно возможным в случае неправильной настройки сети, — использование консоли <filename>hvc0</filename> с помощью команды <command>xl console</command>:

en: One can then open a session, just like one would do if sitting at the virtual machine's keyboard. Detaching from this console is achieved through the <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo> key combination.
ru-RU: После этого можно начать сессию, как если бы вы сидели за клавиатурой виртуальной машины. Для отключения от этой консоли служит сочетание клавиш <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo>.

en: <emphasis>TIP</emphasis> Getting the console straight away
ru-RU: <emphasis>СОВЕТ</emphasis> Получение консоли сразу

en: Sometimes one wishes to start a domU system and get to its console straight away; this is why the <command>xl create</command> command takes a <literal>-c</literal> switch. Starting a domU with this switch will display all the messages as the system boots.
ru-RU: Иногда хочется запустить domU-систему и сразу же подключиться к её консоли; для этого команда <command>xl create</command> может принимать флаг <literal>-c</literal>. Запуск domU с этим флагом приведёт к отображению всех сообщений во время загрузки системы.

en: Once the domU is up, it can be used just like any other server (since it is a GNU/Linux system after all). However, its virtual machine status allows some extra features. For instance, a domU can be temporarily paused then resumed, with the <command>xl pause</command> and <command>xl unpause</command> commands. Note that even though a paused domU does not use any processor power, its allocated memory is still in use. It may be interesting to consider the <command>xl save</command> and <command>xl restore</command> commands: saving a domU frees the resources that were previously used by this domU, including RAM. When restored (or unpaused, for that matter), a domU doesn't even notice anything beyond the passage of time. If a domU was running when the dom0 is shut down, the packaged scripts automatically save the domU, and restore it on the next boot. This will of course involve the standard inconvenience incurred when hibernating a laptop computer, for instance; in particular, if the domU is suspended for too long, network connections may expire. Note also that Xen is so far incompatible with a large part of ACPI power management, which precludes suspending the host (dom0) system.
ru-RU: Когда domU запущен, он может использоваться как любой другой сервер (ведь это, помимо прочего, система GNU/Linux). Однако благодаря тому, что это виртуальная машина, доступны и некоторые дополнительные возможности. К примеру, domU может быть временно приостановлен, а затем вновь запущен с помощью команд <command>xl pause</command> и <command>xl unpause</command>. Заметьте, что хотя приостановленный domU не использует ресурсы процессора, выделенная ему память по-прежнему занята. Может иметь смысл использовать команды <command>xl save</command> и <command>xl restore</command>: сохранение domU освобождает ресурсы, которые ранее использовались этим domU, в том числе и ОЗУ. После восстановления (или снятия с паузы) domU не замечает ничего кроме того, что прошло некоторое время. Если domU был запущен, когда dom0 выключается, сценарии из пакетов автоматически сохраняют domU и восстанавливают его при следующей загрузке. Отсюда, конечно, проистекает обычное неудобство, проявляющееся, например, при переводе ноутбука в спящий режим; в частности, если domU приостановлен слишком надолго, сетевые подключения могут завершиться. Заметьте также, что Xen на данный момент несовместим с большей частью системы управления питанием ACPI, что мешает приостановке dom0-системы.

en: Halting or rebooting a domU can be done either from within the domU (with the <command>shutdown</command> command) or from the dom0, with <command>xl shutdown</command> or <command>xl reboot</command>.
ru-RU: Выключение или перезагрузка domU могут быть выполнены как изнутри domU (с помощью команды <command>shutdown</command>), так и из dom0, с помощью <command>xl shutdown</command> или <command>xl reboot</command>.

en: Most of the <command>xl</command> subcommands expect one or more arguments, often a domU name. These arguments are well described in the <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
ru-RU: Большая часть подкоманд <command>xl</command> требуют одного или более аргументов, часто — имени domU. Эти аргументы подробно описаны в странице руководства <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry>.

en: <emphasis>GOING FURTHER</emphasis> Advanced Xen
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> Xen углублённо

en: Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation. <ulink type="block" url="https://xenproject.org/help/documentation/" />
ru-RU: У Xen есть гораздо больше возможностей, чем мы могли описать в этих нескольких абзацах. В частности, система очень динамична, и многие параметры домена (такие как объём выделенной памяти, видимые жёсткие диски, поведение планировщика задач и так далее) могут быть изменены даже когда домен запущен. domU может быть даже перенесён с одного сервера на другой без отключения, и даже без потери сетевых подключений! Главным источником информации обо всех этих углублённых аспектах является официальная документация Xen. <ulink type="block" url="https://xenproject.org/help/documentation/" />

en: Even though it is used to build “virtual machines”, LXC is not, strictly speaking, a virtualization system, but a system to isolate groups of processes from each other even though they all run on the same host. It takes advantage of a set of recent evolutions in the Linux kernel, collectively known as <emphasis>control groups</emphasis>, by which different sets of processes called “groups” have different views of certain aspects of the overall system. Most notable among these aspects are the process identifiers, the network configuration, and the mount points. Such a group of isolated processes will not have any access to the other processes in the system, and its accesses to the filesystem can be restricted to a specific subset. It can also have its own network interface and routing table, and it may be configured to only see a subset of the available devices present on the system.
ru-RU: Хотя она и используется для создания «виртуальных машин», LXC является, строго говоря, не системой виртуализации, а системой для изоляции групп процессов друг от друга, даже если они все выполняются на одном узле. Она использует набор недавних изменений в ядре Linux, известных под общим названием <emphasis>control groups</emphasis>, благодаря которому разные наборы процессов, называемые «группами», имеют разные представления о некоторых аспектах системы. Наиболее примечательные из этих аспектов — идентификаторы процессов, конфигурация сети и точки монтирования. Такая группа изолированных процессов не будет иметь доступа к другим процессам в системе, и её доступ к файловой системе может быть ограничен определённым подмножеством. У неё также могут быть свои собственные сетевой интерфейс и таблица маршрутизации, и она может быть настроена так, чтобы видеть только подмножество устройств, присутствующих в системе.

en: These features can be combined to isolate a whole process family starting from the <command>init</command> process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: <emphasis>LinuX Containers</emphasis>), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).
ru-RU: С помощью комбинации этих возможностей можно изолировать целое семейство процессов начиная с процесса <command>init</command>, и получившийся набор будет выглядеть чрезвычайно похоже на виртуальную машину. Официальное название для такой схемы «контейнер» (отсюда и неофициальное название LXC: <emphasis>LinuX Containers</emphasis>), но весьма значительным отличием от «настоящих» виртуальных машин, таких как предоставляемые Xen или KVM, заключается в отсутствии второго ядра; контейнер использует то же самое ядро, что и хост-система. У этого есть как преимущества, так и недостатки: к преимуществам относится великолепная производительность благодаря полному отсутствию накладных расходов, а также тот факт, что ядро видит все процессы в системе, поэтому планировщик может работать более эффективно, чем если бы два независимых ядра занимались планированием выполнения разных наборов задач. Основное из неудобств — невозможность запустить другое ядро в контейнере (как другую версию Linux, так и другую операционную систему).

en: <emphasis>NOTE</emphasis> LXC isolation limits
ru-RU: <emphasis>ЗАМЕТКА</emphasis> Ограничения изоляции LXC

en: LXC containers do not provide the level of isolation achieved by heavier emulators or virtualizers. In particular:
ru-RU: Контейнеры LXC не предоставляют такого уровня изоляции, который достижим с помощью более серьёзных эмуляторов или виртуальных машин. В частности:

en: since the kernel is shared among the host system and the containers, processes constrained to containers can still access the kernel messages, which can lead to information leaks if messages are emitted by a container;
ru-RU: поскольку ядро разделяется между хост-системой и контейнерами, процессы, заключённые в контейнеры, всё же могут получать доступ к сообщениям ядра, что может привести к утечкам информации, если сообщения исходят из контейнера;

en: for similar reasons, if a container is compromised and a kernel vulnerability is exploited, the other containers may be affected too;
ru-RU: по той же причине, если контейнер скомпрометирован и была эксплуатирована уязвимость ядра, другие контейнеры также могут быть затронуты;

en: on the filesystem, the kernel checks permissions according to the numerical identifiers for users and groups; these identifiers may designate different users and groups depending on the container, which should be kept in mind if writable parts of the filesystem are shared among containers.
ru-RU: ядро проверяет права доступа файловых систем в соответствии с числовыми идентификаторами пользователей и групп; эти идентификаторы могут обозначать разных пользователей и группы в зависимости от контейнера, что следует помнить, если доступные для записи части файловой системы разделяются между контейнерами.

en: Since we are dealing with isolation and not plain virtualization, setting up LXC containers is more complex than just running debian-installer on a virtual machine. We will describe a few prerequisites, then go on to the network configuration; we will then be able to actually create the system to be run in the container.
ru-RU: Поскольку мы имеем дело с изоляцией, а не обычной виртуализацией, настройка контейнеров LXC более сложна, чем простой запуск debian-installer на виртуальной машине. Мы опишем некоторые предварительные требования, затем перейдём к конфигурации сети; после этого мы сможем собственно создать систему для запуска в контейнере.

en: Preliminary Steps
ru-RU: Предварительные шаги

en: The <emphasis role="pkg">lxc</emphasis> package contains the tools required to run LXC, and must therefore be installed.
ru-RU: Пакет <emphasis role="pkg">lxc</emphasis> содержит инструменты, необходимые для запуска LXC, поэтому его необходимо установить.

en: LXC also requires the <emphasis>control groups</emphasis> configuration system, which is a virtual filesystem to be mounted on <filename>/sys/fs/cgroup</filename>. Since Debian 8 switched to systemd, which also relies on control groups, this is now done automatically at boot time without further configuration.
ru-RU: LXC также требует систему конфигурации <emphasis>control groups</emphasis>, представляющую собой виртуальную файловую систему, которая должна быть смонтирована в <filename>/sys/fs/cgroup</filename>. Так как Debian 8 перешел на systemd, который также зависит от control groups, это делается автоматически во время загрузки без дополнительной настройки.

en: Network Configuration
ru-RU: Сетевые настройки

en: The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the <emphasis role="pkg">bridge-utils</emphasis> package will be required.
ru-RU: Цель установки LXC — в запуске виртуальных машин; хотя мы, разумеется, можем держать их изолированными от сети и взаимодействовать с ними только через файловую систему, для большинства задач требуется хотя бы минимальный сетевой доступ к контейнерам. В типичном случае каждый контейнер получит виртуальный сетевой интерфейс присоединённый к реальной сети через мост. Этот виртуальный интерфейс может быть подключён либо напрямую к физическому сетевому интерфейсу хост-системы (в таком случае контейнер непосредственно в сети), либо к другому виртуальному интерфейсу, определённому в хост-системе (тогда хост сможет фильтровать или маршрутизировать трафик). В обоих случаях потребуется пакет <emphasis role="pkg">bridge-utils</emphasis>.

en: They should be disabled and replaced with the following:
ru-RU: Их следует отключить и заменить на следующие:

en: The effect of this configuration will be similar to what would be obtained if the containers were machines plugged into the same physical network as the host. The “bridge” configuration manages the transit of Ethernet frames between all the bridged interfaces, which includes the physical <literal>eth0</literal> as well as the interfaces defined for the containers.
ru-RU: Результат такой настройки будет похож на тот, какой мы получили бы, если бы контейнеры были машинами, подключёнными к той же физической сети, что и хост-машина. Конфигурация «мост» управляет прохождением кадров Ethernet между всеми связанными интерфейсами, включая и физический <literal>eth0</literal>, и интерфейсы, заданные для контейнеров.

en: In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual <emphasis>tap</emphasis> interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.
ru-RU: В случаях, когда такую конфигурацию использовать невозможно (например, если контейнерам нельзя выделить публичные IP-адреса), будет создан и подключён к мосту виртуальный <emphasis>tap</emphasis>-интерфейс. Это будет эквивалентно сетевой топологии, при которой вторая сетевая карта подключена к отдельному коммутатору, и к нему же подключены контейнеры. Хост тогда должен выступать как шлюз для контейнеров, если им требуется соединяться с остальным миром.

en: In addition to <emphasis role="pkg">bridge-utils</emphasis>, this “rich” configuration requires the <emphasis role="pkg">vde2</emphasis> package; the <filename>/etc/network/interfaces</filename> file then becomes:
ru-RU: В дополнение к <emphasis role="pkg">bridge-utils</emphasis> для «продвинутой» конфигурации потребуется пакет <emphasis role="pkg">vde2</emphasis>; файл <filename>/etc/network/interfaces</filename> тогда примет следующий вид:

en: The network can then be set up either statically in the containers, or dynamically with DHCP server running on the host. Such a DHCP server will need to be configured to answer queries on the <literal>br0</literal> interface.
ru-RU: Сеть может быть настроена как статически в контейнерах, так и динамически и помощью DHCP-сервера, запущенного на хост-системе. Такой DHCP-сервер должен быть сконфигурирован для ответа на запросы на интерфейсе <literal>br0</literal>.

en: Setting Up the System
ru-RU: Установка системы

en: Note that the filesystem is initially created in <filename>/var/cache/lxc</filename>, then moved to its destination directory. This allows creating identical containers much more quickly, since only copying is then required.
ru-RU: Заметьте, что файловая система изначально создана в <filename>/var/cache/lxc</filename>, а затем перемещена в каталог назначения. Это позволяет создавать идентичные контейнеры намного быстрее, поскольку требуется лишь скопировать их.

en: Note that the Debian template creation script accepts an <option>--arch</option> option to specify the architecture of the system to be installed and a <option>--release</option> option if you want to install something else than the current stable release of Debian. You can also set the <literal>MIRROR</literal> environment variable to point to a local Debian mirror.
ru-RU: Заметьте, что сценарий создания шаблона debian принимает опцию <option>--arch</option> с указанием архитектуры системы для установки и опцию <option>--release</option>, если вы хотите установить что-то отличное от текущего стабильного релиза Debian. Вы можете также установить переменную окружения <literal>MIRROR</literal>, чтобы указать на локальное зеркало Debian.

en: Another useful entry in that file is the setting of the hostname:
ru-RU: Другая полезная запись в этом файле — имя узла:

en: Starting the Container
ru-RU: Запуск контейнера

en: We are now in the container; our access to the processes is restricted to only those started from the container itself, and our access to the filesystem is similarly restricted to the dedicated subset of the full filesystem (<filename>/var/lib/lxc/testlxc/rootfs</filename>). We can exit the console with <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.
ru-RU: Теперь мы в контейнере; наш доступ к процессам ограничен только теми, которые запущены изнутри самого контейнера, и наш доступ к файловой системе также ограничен до выделенного подмножества полной файловой системы (<filename>/var/lib/lxc/testlxc/rootfs</filename>). Мы можем выйти из консоли с помощью <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.

en: The <emphasis role="pkg">lxc</emphasis> package contains an initialization script that can automatically start one or several containers when the host boots (it relies on <command>lxc-autostart</command> which starts containers whose <literal>lxc.start.auto</literal> option is set to 1). Finer-grained control of the startup order is possible with <literal>lxc.start.order</literal> and <literal>lxc.group</literal>: by default, the initialization script first starts containers which are part of the <literal>onboot</literal> group and then the containers which are not part of any group. In both cases, the order within a group is defined by the <literal>lxc.start.order</literal> option.
ru-RU: Пакет <emphasis role="pkg">lxc</emphasis>содержит сценарий инициализации, который может автоматически запускать один или несколько контейнеров при загрузке хост-системы (он использует <command>lxc-autostart</command>, запускающую контейнеры, параметр <literal>lxc.start.auto</literal> которых установлен в значение 1). Более тонкий контроль порядка запуска возможен с помощью <literal>lxc.start.order</literal> и <literal>lxc.group</literal>: по умолчанию сценарий инициализации сначала запускает контейнеры, входящие в группу <literal>onboot</literal>, а затем — контейнеры, не входящие ни в какие группы. В обоих случаях порядок внутри группы определяется параметром <literal>lxc.start.order</literal>.

en: <emphasis>GOING FURTHER</emphasis> Mass virtualization
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> Массовая виртуализация

en: Since LXC is a very lightweight isolation system, it can be particularly adapted to massive hosting of virtual servers. The network configuration will probably be a bit more advanced than what we described above, but the “rich” configuration using <literal>tap</literal> and <literal>veth</literal> interfaces should be enough in many cases.
ru-RU: Поскольку LXC — очень легковесная система изоляции, её в частности можно приспособить для массового размещения виртуальных серверов. Сетевая конфигурация будет, возможно, несколько более сложной, чем мы описали выше, но «продвинутой» конфигурации с использованием интерфейсов <literal>tap</literal> и <literal>veth</literal> должно быть достаточно во многих случаях.

en: It may also make sense to share part of the filesystem, such as the <filename>/usr</filename> and <filename>/lib</filename> subtrees, so as to avoid duplicating the software that may need to be common to several containers. This will usually be achieved with <literal>lxc.mount.entry</literal> entries in the containers configuration file. An interesting side-effect is that the processes will then use less physical memory, since the kernel is able to detect that the programs are shared. The marginal cost of one extra container can then be reduced to the disk space dedicated to its specific data, and a few extra processes that the kernel must schedule and manage.
ru-RU: Может также иметь смысл сделать общей часть файловой системы, такую как ветки <filename>/usr</filename> и <filename>/lib</filename>, чтобы избежать дупликации программного обеспечения, которое может быть общим для нескольких контейнеров. Это обычно достигается с помощью записей <literal>lxc.mount.entry</literal> в конфигурационных файлах контейнеров. Интересным побочным эффектом является то, что процессы станут потреблять меньше физической памяти, поскольку ядро способно определить, что программы используются совместно. Минимальные затраты на один дополнительный контейнер могут быть снижены до дискового пространства, выделенного под его специфические данные, и нескольких дополнительных процессов, которыми должно управлять ядро.

en: We haven't described all the available options, of course; more comprehensive information can be obtained from the <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> and <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual pages and the ones they reference.
ru-RU: Разумеется, мы не описали всех доступных опций; более исчерпывающая информация может быть получена из страниц руководства <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> и <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> и тех, на которые они ссылаются.

en: Virtualization with KVM
ru-RU: Виртуализация с помощью KVM

en: KVM, which stands for <emphasis>Kernel-based Virtual Machine</emphasis>, is first and foremost a kernel module providing most of the infrastructure that can be used by a virtualizer, but it is not a virtualizer by itself. Actual control for the virtualization is handled by a QEMU-based application. Don't worry if this section mentions <command>qemu-*</command> commands: it is still about KVM.
ru-RU: KVM, что расшифровывается как <emphasis>Kernel-based Virtual Machine</emphasis>, является первым и главным модулем ядра, предоставляющим большую часть инфраструктуры, которая может использоваться виртуализатором, но не является самим виртуализатором. Собственно контроль за виртуализацией осуществляется приложением, основанным на QEMU. Не переживайте, если в этом разделе будут упоминаться команды <command>qemu-*</command>: речь всё равно о KVM.

en: Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors. For x86-based computers, you can verify that you have such a processor by looking for “vmx” or “svm” in the CPU flags listed in <filename>/proc/cpuinfo</filename>.
ru-RU: В отличие от других систем виртуализации, KVM был влит в ядро Linux с самого начала. Его разработчики выбрали использование наборов инструкций процессора, выделенных для виртуализации (Intel-VT и AMD-V), благодаря чему KVM получился легковесным, элегантным и не прожорливым до ресурсов. Обратной стороной медали является, естественно, то, что KVM работает не на любом компьютере, а только на таком, в котором установлен подобающий процессор. Для x86-машин можно убедиться, такой ли у вас процессор, проверив наличие флага «vmx» или «svm» в файле <filename>/proc/cpuinfo</filename>.

en: With Red Hat actively supporting its development, KVM has more or less become the reference for Linux virtualization.
ru-RU: Поскольку его разработка активно поддерживается Red Hat, KVM стал в той или иной степени эталоном виртуализации в Linux.

en: We first install the required packages, with <command>apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer</command>. <emphasis role="pkg">libvirt-daemon-system</emphasis> provides the <command>libvirtd</command> daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. <emphasis role="pkg">libvirt-clients</emphasis> provides the <command>virsh</command> command-line tool, which allows controlling the <command>libvirtd</command>-managed machines.
ru-RU: Первым делом мы установим необходимые пакеты с помощью команды <command>apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer</command>. <emphasis role="pkg">libvirt-bin</emphasis> предоставляет демон <command>libvirtd</command>, позволяющий (возможно удалённо) управлять виртуальными машинами, запущенными на хосте, и запускает необходимые виртуальные машины при загрузке хоста. <emphasis role="pkg">libvirt-clients</emphasis> предоставляет утилиту <command>virsh</command> с интерфейсом командной строки, которая позволяет контролировать виртуальные машины, управляемые <command>libvirt</command>.

en: The <emphasis role="pkg">virtinst</emphasis> package provides <command>virt-install</command>, which allows creating virtual machines from the command line. Finally, <emphasis role="pkg">virt-viewer</emphasis> allows accessing a VM's graphical console.
ru-RU: Пакет <emphasis role="pkg">virtinst</emphasis> предоставляет <command>virt-install</command>, которая позволяет создавать виртуальные машины из командной строки. Наконец, <emphasis role="pkg">virt-viewer</emphasis> позволяет получать доступ к графической консоли виртуальной машины.

en: Just as in Xen and LXC, the most frequent network configuration involves a bridge grouping the network interfaces of the virtual machines (see <xref linkend="sect.lxc.network" />).
ru-RU: Как и в случаях Xen и LXC, наиболее распространённая сетевая конфигурация включает мост, группирующий сетевые интерфейсы виртуальных машин (см. <xref linkend="sect.lxc.network" />).

en: Alternatively, and in the default configuration provided by KVM, the virtual machine is assigned a private address (in the 192.168.122.0/24 range), and NAT is set up so that the VM can access the outside network.
ru-RU: В качестве альтернативы, в конфигурации KVM по умолчанию, виртуальной машине выдаётся адрес из частного диапазона (192.168.122.0/24), и NAT настраивается таким образом, чтобы виртуальная машина могла получить доступ во внешнюю сеть.

en: The rest of this section assumes that the host has an <literal>eth0</literal> physical interface and a <literal>br0</literal> bridge, and that the former is connected to the latter.
ru-RU: Ниже в этом разделе считается, что на хост-системе имеются физический интерфейс <literal>eth0</literal> и мост <literal>br0</literal>, и что первый присоединён к последнему.

en: Installation with <command>virt-install</command>
ru-RU: Установка с помощью <command>virt-install</command>

en: Creating a virtual machine is very similar to installing a normal system, except that the virtual machine's characteristics are described in a seemingly endless command line.
ru-RU: Создание виртуальной машины очень похоже на установку обычной системы с той разницей, что характеристики виртуальной машины описываются в командной строке, кажущейся бесконечной.

en: Practically speaking, this means we will use the Debian installer, by booting the virtual machine on a virtual DVD-ROM drive that maps to a Debian DVD image stored on the host system. The VM will export its graphical console over the VNC protocol (see <xref linkend="sect.remote-desktops" /> for details), which will allow us to control the installation process.
ru-RU: С практической точки зрения это значит, что мы будем использовать установщик Debian, загружая виртуальную машину с виртуального привода DVD-ROM, соответствующего образу DVD Debian, хранящемуся на хост-системе. Виртуальная машина экспортирует свой графический интерфейс по протоколу VNC (см. подробности в <xref linkend="sect.remote-desktops" />), что позволит нам контролировать процесс установки.

en: <emphasis>TIP</emphasis> Add your user to the libvirt group
ru-RU: <emphasis>СОВЕТ</emphasis> Добавьте пользователя в группу libvirt

en: All samples in this section assume that you are running commands as root. Effectively, if you want to control a local libvirt daemon, you need either to be root or to be a member of the <literal>libvirt</literal> group (which is not the case by default). Thus if you want to avoid using root rights too often, you can add yourself to the <literal>libvirt</literal> group and run the various commands under your user identity.
ru-RU: Все примеры в этом разделе подразумевают выполнение команд от имени root. Фактически для управления локальным демоном libvirt надо или быть root, или входить в группу <literal>libvirt</literal> (по умолчанию пользователи в неё не добавляются). Так что при желании избежать слишком частого использования привилегий root можно добавить себя в группу <literal>libvirt</literal> и запускать команды от собственного имени.

en: Let us now start the installation process for the virtual machine, and have a closer look at <command>virt-install</command>'s most important options. This command registers the virtual machine and its parameters in libvirtd, then starts it so that its installation can proceed.
ru-RU: Давайте запустим процесс установки на виртуальной машине и поближе взглянем на наиболее важные опции <command>virt-install</command>. Эта команда регистрирует виртуальную машину и её параметры в libvirtd, а затем запускает её, чтобы приступить к установке.

en: The <literal>--connect</literal> option specifies the “hypervisor” to use. Its form is that of an URL containing a virtualization system (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, and so on) and the machine that should host the VM (this can be left empty in the case of the local host). In addition to that, and in the QEMU/KVM case, each user can manage virtual machines working with restricted permissions, and the URL path allows differentiating “system” machines (<literal>/system</literal>) from others (<literal>/session</literal>).
ru-RU: Опция <literal>--connect</literal> указывает, какой «гипервизор» использовать. Он указывается в виде URL, содержащего систему виртуализации(<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal> и т. п.) и машину, на которой должны размещаться виртуальные машины (это поле можно оставить пустым в случае локального узла). В дополнение к этому, в случае QEMU/KVM каждый пользователь может управлять виртуальными машинами, работающими с ограниченными правами, и путь URL позволяет дифференцировать «системные» машины (<literal>/system</literal>) от остальных (<literal>/session</literal>).

en: Since KVM is managed the same way as QEMU, the <literal>--virt-type kvm</literal> allows specifying the use of KVM even though the URL looks like QEMU.
ru-RU: Так как KVM управляется тем же образом, что и QEMU, в <literal>--virt-type kvm</literal> можно указать использование KVM, хотя URL и выглядит так же, как для QEMU.

en: The <literal>--name</literal> option defines a (unique) name for the virtual machine.
ru-RU: Опция <literal>--name</literal> задаёт (уникальное) имя виртуальной машины.

en: The <literal>--memory</literal> option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.
ru-RU: Опция <literal>--memory</literal> позволяет указать объём ОЗУ (в МБ), который будет выделен виртуальной машине.

en: The <literal>--disk</literal> specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the <literal>size</literal> parameter. The <literal>format</literal> parameter allows choosing among several ways of storing the image file. The default format (<literal>qcow2</literal>) allows starting with a small file that only grows when the virtual machine starts actually using space.
ru-RU: <literal>--disk</literal> служит для указания местоположения файла образа, который будет представляться жёстким диском виртуальной машины; этот файл создаётся, если только ещё не существует, а его размер (в ГБ) указывается параметром <literal>size</literal>. Параметр <literal>format</literal> позволяет выбрать из нескольких способов хранения образа файла. Формат по умолчанию (<literal>qcow2</literal>) позволяет начать с небольшого файла, увеличивающегося только по мере того, как виртуальная машина использует пространство.

en: The <literal>--cdrom</literal> option is used to indicate where to find the optical disk to use for installation. The path can be either a local path for an ISO file, an URL where the file can be obtained, or the device file of a physical CD-ROM drive (i.e. <literal>/dev/cdrom</literal>).
ru-RU: Опция <literal>--cdrom</literal> используется, чтобы указать, где искать оптический диск для установки. Путь может быть либо локальным путём к ISO-файлу, либо URL, по которому можно получить файл, либо файлом устройства физического привода CD-ROM (то есть <literal>/dev/cdrom</literal>).

en: The <literal>--network</literal> specifies how the virtual network card integrates in the host's network configuration. The default behavior (which we explicitly forced in our example) is to integrate it into any pre-existing network bridge. If no such bridge exists, the virtual machine will only reach the physical network through NAT, so it gets an address in a private subnet range (192.168.122.0/24).
ru-RU: С помощью опции <literal>--network</literal> указывается, каким образом виртуальная сетевая карта интегрируется в сетевую конфигурацию хоста. Поведением по умолчанию (которое мы задали явно в этом примере) является интеграция в любой существующий сетевой мост. Если ни одного моста нет, виртуальная машина сможет получить доступ к физической сети только через NAT, поэтому она получает адрес в подсети из частного диапазона (192.168.122.0/24).

en: <literal>--graphics vnc</literal> states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see <xref linkend="sect.ssh-port-forwarding" />). Alternatively, <literal>--graphics vnc,listen=0.0.0.0</literal> can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.
ru-RU: <literal>--graphics vnc</literal> означает, что подключение к графической консоли нужно сделать доступным через VNC. По умолчанию соответствующий VNC-сервер слушает только на локальном интерфейсе; если VNC-клиент должен запускаться на другой системе, для подключения потребуется использовать SSH-туннель (см. <xref linkend="sect.ssh-port-forwarding" />). Как вариант, можно использовать опцию <literal>--graphics vnc,listen=0.0.0.0</literal>, чтобы VNC-сервер стал доступен на всех интерфейсах; заметьте, что если вы сделаете так, вам серьёзно стоит заняться настройкой межсетевого экрана.

en: The <literal>--os-type</literal> and <literal>--os-variant</literal> options allow optimizing a few parameters of the virtual machine, based on some of the known features of the operating system mentioned there.
ru-RU: Опции <literal>--os-type</literal> и <literal>--os-variant</literal> позволяют оптимизировать некоторые параметры виртуальной машины, исходя из известных особенностей указанной операционной системы.

en: At this point, the virtual machine is running, and we need to connect to the graphical console to proceed with the installation process. If the previous operation was run from a graphical desktop environment, this connection should be automatically started. If not, or if we operate remotely, <command>virt-viewer</command> can be run from any graphical environment to open the graphical console (note that the root password of the remote host is asked twice because the operation requires 2 SSH connections):
ru-RU: Сейчас виртуальная машина запущена, и нам надо подключиться к графической консоли, чтобы произвести установку. Если предыдущий шаг выполнялся в графическом окружении, это подключение установится автоматически. В противном случае, или же при удалённой работе, чтобы открыть графическую консоль, можно запустить <command>virt-viewer</command> в любом графическом окружении (пароль root на удалённой машине запрашивается дважды, поскольку для работы требуется два SSH-соединения):

en: When the installation process ends, the virtual machine is restarted, now ready for use.
ru-RU: Когда процесс установки завершится, виртуальная машина перезагрузится и будет готова к работе.

en: Managing Machines with <command>virsh</command>
ru-RU: Управление машинами с помощью <command>virsh</command>

en: Now that the installation is done, let us see how to handle the available virtual machines. The first thing to try is to ask <command>libvirtd</command> for the list of the virtual machines it manages:
ru-RU: Теперь, когда установка выполнена, давайте посмотрим, как обращаться с имеющимися виртуальными машинами. Первым делом попробуем попросить у <command>libvirtd</command> список управляемых им виртуальных машин:

en: Let's start our test virtual machine:
ru-RU: Давайте запустим нашу тестовую виртуальную машину:

en: <computeroutput># </computeroutput><userinput>virsh -c qemu:///system start testkvm
    </userinput><computeroutput>Domain testkvm started</computeroutput>
ru-RU: <computeroutput># </computeroutput><userinput>virsh -c qemu:///system start testkvm
    </userinput><computeroutput>Domain testkvm стартует </computeroutput>

en: We can now get the connection instructions for the graphical console (the returned VNC display can be given as parameter to <command>vncviewer</command>):
ru-RU: Теперь можно получить инструкции для подключения к графической консоли (возвращённый VNC-дисплей можно передать в качестве параметра команде <command>vncviewer</command>):

en: Other available <command>virsh</command> subcommands include:
ru-RU: В число прочих подкоманд <command>virsh</command> входят:

en: <literal>reboot</literal> to restart a virtual machine;
ru-RU: <literal>reboot</literal> для перезапуска виртуальной машины;

en: <literal>shutdown</literal> to trigger a clean shutdown;
ru-RU: <literal>shutdown</literal> для корректного завершения работы;

en: <literal>destroy</literal>, to stop it brutally;
ru-RU: <literal>destroy</literal> для грубого прерывания работы;

en: <literal>suspend</literal> to pause it;
ru-RU: <literal>suspend</literal> для временной приостановки;

en: <literal>resume</literal> to unpause it;
ru-RU: <literal>resume</literal> для продолжения работы после приостановки;

en: <literal>autostart</literal> to enable (or disable, with the <literal>--disable</literal> option) starting the virtual machine automatically when the host starts;
ru-RU: <literal>autostart</literal> для включения (или для выключения, с опцией <literal>--disable</literal>) автоматического запуска виртуальной машины при запуске хост-системы;

en: <literal>undefine</literal> to remove all traces of the virtual machine from <command>libvirtd</command>.
ru-RU: <literal>undefine</literal> для удаления всех следов виртуальной машины из <command>libvirtd</command>.

en: All these subcommands take a virtual machine identifier as a parameter.
ru-RU: Все эти подкоманды принимают идентификатор виртуальной машины в качестве параметра.

en: Automated Installation
ru-RU: Автоматизированная установка

en: <primary>deployment</primary>
ru-RU: <primary>развёртывание</primary>

en: <primary>installation</primary><secondary>automated installation</secondary>
ru-RU: <primary>установка</primary><secondary>автоматизированная установка</secondary>

en: The Falcot Corp administrators, like many administrators of large IT services, need tools to install (or reinstall) quickly, and automatically if possible, their new machines.
ru-RU: Администраторам Falcot Corp, как и многим администраторам больших IT-инфраструктур, необходимы инструменты для быстрой установки (или переустановки), причём по возможности автоматической, на новых машинах.

en: These requirements can be met by a wide range of solutions. On the one hand, generic tools such as SystemImager handle this by creating an image based on a template machine, then deploy that image to the target systems; at the other end of the spectrum, the standard Debian installer can be preseeded with a configuration file giving the answers to the questions asked during the installation process. As a sort of middle ground, a hybrid tool such as FAI (<emphasis>Fully Automatic Installer</emphasis>) installs machines using the packaging system, but it also uses its own infrastructure for tasks that are more specific to massive deployments (such as starting, partitioning, configuration and so on).
ru-RU: Эти потребности можно удовлетворить с помощью широкого диапазона решений. С одной стороны, универсальные инструменты вроде SystemImager делают это, создавая образ, основанный на шаблонной машине, после чего развёртывают этот образ на целевых системах; с другой стороны, стандартный установщик Debian может быть преднастроен с помощью конфигурационного файла, содержащего ответы на задаваемые в процессе установки вопросы. Промежуточным вариантом являются такие гибридные инструменты как FAI (<emphasis>Fully Automatic Installer</emphasis>), которые производят установку с помощью пакетной системы, но также используют свою собственную инфраструктуру для задач, специфичных для массового развёртывания (таких как запуск, разметка, конфигурирование и т. п.).

en: <foreignphrase>Fully Automatic Installer</foreignphrase> is probably the oldest automated deployment system for Debian, which explains its status as a reference; but its very flexible nature only just compensates for the complexity it involves.
ru-RU: <foreignphrase>Fully Automatic Installer</foreignphrase> — это, возможно, самая старая система автоматизированного развёртывания Debian, чем объясняется её статус эталонной; но её очень гибкая натура едва компенсирует привносимую ей сложность.

en: FAI requires a server system to store deployment information and allow target machines to boot from the network. This server requires the <emphasis role="pkg">fai-server</emphasis> package (or <emphasis role="pkg">fai-quickstart</emphasis>, which also brings the required elements for a standard configuration).
ru-RU: FAI требуется серверная система для хранения информации для развёртывания и обеспечения загрузки целевых машин по сети. Для этого сервера нужен пакет <emphasis role="pkg">fai-server</emphasis> (или <emphasis role="pkg">fai-quickstart</emphasis>, в который также входят необходимые элементы для стандартной конфигурации).

en: Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:
ru-RU: Для создания всех этих конфигурационных файлов нужно иметь представление о том, как работает FAI. Типичный процесс установки включает следующие шаги:

en: fetching a kernel from the network, and booting it;
ru-RU: получение ядра по сети и загрузка его;

en: mounting the root filesystem from NFS;
ru-RU: монтирование корневой файловой системы по NFS;

en: executing <command>/usr/sbin/fai</command>, which controls the rest of the process (the next steps are therefore initiated by this script);
ru-RU: запуск <command>/usr/sbin/fai</command>, который контролирует оставшуюся часть процесса (последующие шаги, таким образом, запускаются этим сценарием);

en: copying the configuration space from the server into <filename>/fai/</filename>;
ru-RU: копирование конфигурации с сервера в <filename>/fai/</filename>;

en: running <command>fai-class</command>. The <filename>/fai/class/[0-9][0-9]*</filename> scripts are executed in turn, and return names of “classes” that apply to the machine being installed; this information will serve as a base for the following steps. This allows for some flexibility in defining the services to be installed and configured.
ru-RU: запуск <command>fai-class</command>. Сценарии <filename>/fai/class/[0-9][0-9]*</filename> последовательно выполняются и возвращают имена «классов», которые применяются к устанавливаемой машине; эта информация послужит основой для дальнейших шагов. Это придаёт некоторую гибкость в определении сервисов, которые следует установить и настроить.

en: fetching a number of configuration variables, depending on the relevant classes;
ru-RU: получение набора переменных конфигурации, в зависимости от соответствующих классов;

en: partitioning the disks and formatting the partitions, based on information provided in <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;
ru-RU: разметка дисков и форматирование разделов на основании информации, предоставленной классом <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;

en: mounting said partitions;
ru-RU: монтирование указанных раделов;

en: installing the base system;
ru-RU: установка базовой системы;

en: preseeding the Debconf database with <command>fai-debconf</command>;
ru-RU: предварительная подготовка базы данных Debconf с помощью <command>fai-debconf</command>;

en: fetching the list of available packages for APT;
ru-RU: получение списка доступных пакетов для APT;

en: installing the packages listed in <filename>/fai/package_config/<replaceable>class</replaceable></filename>;
ru-RU: установка пакетов, перечисленных в <filename>/fai/package_config/<replaceable>class</replaceable></filename>;

en: executing the post-configuration scripts, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;
ru-RU: выполнение постконфигурационных сценариев, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;

en: recording the installation logs, unmounting the partitions, and rebooting.
ru-RU: запись журналов установки, отмонтирование разделов и перезагрузка.

en: Preseeding Debian-Installer
ru-RU: Пресидинг Debian-Installer

en: <primary>preconfiguration</primary>
ru-RU: <primary>преднастройка</primary>

en: <emphasis>GOING FURTHER</emphasis> Debconf with a centralized database
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> Debconf с централизованной базой данных

en: Preseeding allows to provide a set of answers to Debconf questions at installation time, but these answers are static and do not evolve as time passes. Since already-installed machines may need upgrading, and new answers may become required, the <filename>/etc/debconf.conf</filename> configuration file can be set up so that Debconf uses external data sources (such as an LDAP directory server, or a remote file accessed via NFS or Samba). Several external data sources can be defined at the same time, and they complement one another. The local database is still used (for read-write access), but the remote databases are usually restricted to reading. The <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the possibilities in detail (you need the <emphasis role="pkg">debconf-doc</emphasis> package).
ru-RU: Пресидинг позволяет предоставить набор ответов на вопросы, задаваемые Debconf во время установки, но эти ответы являются статичными и не меняются с течением времени. Поскольку уже установленные машины могут нуждаться в обновлении, и могут потребоваться новые ответы, конфигурационный файл <filename>/etc/debconf.conf</filename> можно настроить таким образом, чтобы Debconf использовал внешние источники данных (таки как сервер каталогов LDAP или удалённый файл, доступный через NFS или Samba). Можно задать несколько разных источников данных, которые будут дополнять друг друга. Локальная база данных по-прежнему будет использоваться (для доступа на чтение и запись), в то время как удалённые базы обычно ограничиваются только чтением. На странице руководства <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> подробно описаны возможные варианты (понадобится пакет <emphasis role="pkg">debconf-doc</emphasis>).

en: Using a Preseed File
ru-RU: Использование preseed-файла

en: There are several places where the installer can get a preseeding file:
ru-RU: Есть несколько мест, откуда установщик может получить файл пресидинга:

en: in the initrd used to start the machine; in this case, preseeding happens at the very beginning of the installation, and all questions can be avoided. The file just needs to be called <filename>preseed.cfg</filename> and stored in the initrd root.
ru-RU: в initrd, используемом для запуска машины; в этом случае пресидинг происходит на самом раннем этапе установки, и можно избежать каких бы то ни было вопросов. Нужно лишь назвать файл <filename>preseed.cfg</filename> и сохранить его в корне initrd.

en: on the boot media (CD or USB key); preseeding then happens as soon as the media is mounted, which means right after the questions about language and keyboard layout. The <literal>preseed/file</literal> boot parameter can be used to indicate the location of the preseeding file (for instance, <filename>/cdrom/preseed.cfg</filename> when the installation is done off a CD-ROM, or <filename>/hd-media/preseed.cfg</filename> in the USB-key case).
ru-RU: на загрузочном носителе (CD или USB-брелоке); пресидинг в таком случае происходит, как только носитель смонтирован, то есть сразу после вопросов о языке и раскладке клавиатуры. Для указания расположения файла пресидинга можно использовать параметр загрузки <literal>preseed/file</literal> (например, <filename>/cdrom/preseed.cfg</filename> при установке с CD-ROM, или <filename>/hd-media/preseed.cfg</filename> в случае USB-брелока).

en: At a glance, including the preseeding file in the initrd looks like the most interesting solution; however, it is rarely used in practice, because generating an installer initrd is rather complex. The other two solutions are much more common, especially since boot parameters provide another way to preseed the answers to the first questions of the installation process. The usual way to save the bother of typing these boot parameters by hand at each installation is to save them into the configuration for <command>isolinux</command> (in the CD-ROM case) or <command>syslinux</command> (USB key).
ru-RU: На первый взгляд, включение файла пресидинга в initrd выглядит наиболее интересным решением; однако оно редко используется на практике, потому что генерация initrd установщика довольно сложна. Другие два решения гораздо более общеприняты, тем более сто параметры загрузки предоставляют другой путь пресидинг ответов на первые вопросы процесса установки. Обычный путь избежания возни с вписыванием параметров загрузки вручную при каждой установки — сохранить их в конфигурации <command>isolinux</command> (в случае CD-ROM) или <command>syslinux</command> (USB-брелок).

en: Creating a Preseed File
ru-RU: Создание preseed-файла

en: A preseed file is a plain text file, where each line contains the answer to one Debconf question. A line is split across four fields separated by whitespace (spaces or tabs), as in, for instance, <literal>d-i mirror/suite string stable</literal>:
ru-RU: Preseed-файл — это простой текстовый файл, в котором каждая строка содержит ответ на один вопрос Debconf. Строка разбита на четыре поля, разделённых между собой пробельными символами (пробелами или символами табуляции), например <literal>d-i mirror/suite string stable</literal>:

en: the first field is the “owner” of the question; “d-i” is used for questions relevant to the installer, but it can also be a package name for questions coming from Debian packages;
ru-RU: первое поле — это «владелец» вопроса; «d-i» используется для вопросов, относящихся к установщику, но это также может быть имя пакета для вопросов, относящихся к пакетам Debian;

en: third, the type of question;
ru-RU: третье — тип вопроса;

en: the fourth and last field contains the value for the answer. Note that it must be separated from the third field with a single space; if there are more than one, the following space characters are considered part of the value.
ru-RU: четвёртое и последнее поле содержит значение ответа. Заметьте, что оно должно быть отделено от третьего поля одним пробелом; если пробелов больше одного, последующие пробелы будут считаться частью значения.

en: The simplest way to write a preseed file is to install a system by hand. Then <command>debconf-get-selections --installer</command> will provide the answers concerning the installer. Answers about other packages can be obtained with <command>debconf-get-selections</command>. However, a cleaner solution is to write the preseed file by hand, starting from an example and the reference documentation: with such an approach, only questions where the default answer needs to be overridden can be preseeded; using the <literal>priority=critical</literal> boot parameter will instruct Debconf to only ask critical questions, and use the default answer for others.
ru-RU: Простейший путь написать preseed-файл — установить систему вручную. После этого <command>debconf-get-selections --installer</command> предоставит ответы, относящиеся к установщику. Ответы о других пакетах могут быть получены с помощью <command>debconf-get-selections</command>. Однако более правильным решением будет написать preseed-файл вручную, руководствуясь примером и справочной документацией: при таком подходе пресидингу подвергнутся только вопросы, для которых следует изменить значение ответа по умолчанию; используя параметр загрузки <literal>priority=critical</literal>, можно указать Debconf, что следует задавать только критические вопросы, и использовать ответ по умолчанию для остальных.

en: <emphasis>DOCUMENTATION</emphasis> Installation guide appendix
ru-RU: <emphasis>ДОКУМЕНТАЦИЯ</emphasis> Приложение к руководству по установке

en: Creating a Customized Boot Media
ru-RU: Создание модифицированного загрузочного носителя

en: Knowing where to store the preseed file is all very well, but the location isn't everything: one must, one way or another, alter the installation boot media to change the boot parameters and add the preseed file.
ru-RU: Знать, где разместить preseed-файл, конечно, уже хорошо, но одного этого знания недостаточно: нужно, так или иначе, внести изменения в загрузочные параметры носителя, с которого осуществляется установка, и добавить preseed-файл.

en: Booting From the Network
ru-RU: Сетевая загрузка

en: When a computer is booted from the network, the server sending the initialization elements also defines the boot parameters. Thus, the change needs to be made in the PXE configuration for the boot server; more specifically, in its <filename>/tftpboot/pxelinux.cfg/default</filename> configuration file. Setting up network boot is a prerequisite; see the Installation Guide for details. <ulink type="block" url="https://www.debian.org/releases/stable/amd64/ch04s05" />
ru-RU: Когда компьютер загружается по сети, сервер, отправляющий элементы для инициализации, также определяет параметры загрузки. Таким образом, изменения надо вносить в конфигурацию PXE на сервере загрузки; точнее, в его конфигурационный файл <filename>/tftpboot/pxelinux.cfg/default</filename>. Предварительно нужно настроить сетевую загрузку; подробности смотрите в инструкции по установке. <ulink type="block" url="https://www.debian.org/releases/stable/amd64/ch04s05" />

en: Preparing a Bootable USB Key
ru-RU: Подготовка загрузочного USB-брелока

en: syslinux.cfg file and preseeding parameters
ru-RU: файл syslinux.cfg и параметры файла ответов

en: Creating a CD-ROM Image
ru-RU: Создание образа CD-ROM

en: A USB key is a read-write media, so it was easy for us to add a file there and change a few parameters. In the CD-ROM case, the operation is more complex, since we need to regenerate a full ISO image. This task is handled by <emphasis role="pkg">debian-cd</emphasis>, but this tool is rather awkward to use: it needs a local mirror, and it requires an understanding of all the options provided by <filename>/usr/share/debian-cd/CONF.sh</filename>; even then, <command>make</command> must be invoked several times. <filename>/usr/share/debian-cd/README</filename> is therefore a very recommended read.
ru-RU: USB-брелок является перезаписываемым носителем, поэтому нам было легко добавить туда файл и изменить несколько параметров. В случае CD-ROM эта процедура усложняется, поскольку требуетс перегенерировать весь ISO-образ. Для этой задачи служит <emphasis role="pkg">debian-cd</emphasis>, но этот инструмент несколько неудобен в использовании: ему требуется локальное зеркало, и для работы с ним необходимо понимать все опции <filename>/usr/share/debian-cd/CONF.sh</filename>; даже при соблюдении этих условий нужно несколько раз запускать <command>make</command>. По этой причине крайне рекомендуется ознакомиться с файлом <filename>/usr/share/debian-cd/README</filename>.

en: Simple-CDD: The All-In-One Solution
ru-RU: Simple-CDD: решение «всё-в-одном»

en: Simply using a preseed file is not enough to fulfill all the requirements that may appear for large deployments. Even though it is possible to execute a few scripts at the end of the normal installation process, the selection of the set of packages to install is still not quite flexible (basically, only “tasks” can be selected); more important, this only allows installing official Debian packages, and precludes locally-generated ones.
ru-RU: Простого использования preseed-файла недостаточно, чтобы удовлетворить всем требованиям, которые могут предъявляться при массовом развёртывании. Несмотря на наличие возможности выполнить некоторые сценарии в конце обычного процесса установки, выбор набора пакетов для установки всё же недостаточно гибок (собственно, можно выбрать для установки только «задачи»); что более важно, возможна установка только официальных пакетов Debian, но не локально собранных.

en: Creating Profiles
ru-RU: Создание профилей

en: Simple-CDD defines “profiles” that match the FAI “classes” concept, and a machine can have several profiles (determined at installation time). A profile is defined by a set of <filename>profiles/<replaceable>profile</replaceable>.*</filename> files:
ru-RU: Simple-CDD определяет «профили», сходные с «классами» FAI, причём у машины может быть несколько профилей (назначенных во время установки). Профиль определяется набором файлов <filename>profiles/<replaceable>profile</replaceable>.*</filename>:

en: the <filename>.description</filename> file contains a one-line description for the profile;
ru-RU: файл <filename>.description</filename> содержит одну строку с описанием профиля;

en: the <filename>.packages</filename> file lists packages that will automatically be installed if the profile is selected;
ru-RU: файл <filename>.packages</filename> содержит список пакетов, которые будут автоматически установлены при выборе профиля;

en: the <filename>.downloads</filename> file lists packages that will be stored onto the installation media, but not necessarily installed;
ru-RU: файл <filename>.downloads</filename> содержит список пакетов, которые будут записаны на установочный носитель, но не обязательно установлены;

en: the <filename>.preseed</filename> file contains preseeding information for Debconf questions (for the installer and/or for packages);
ru-RU: файл <filename>.preseed</filename> содержит информацию для пресидинга вопросов Debconf (для установщика и/или пакетов);

en: the <filename>.postinst</filename> file contains a script that will be run at the end of the installation process;
ru-RU: файл <filename>.postinst</filename> содержит сценарий, который будет запущен по завершении процесса установки;

en: The <literal>default</literal> profile has a particular role, since it is always selected; it contains the bare minimum required for Simple-CDD to work. The only thing that is usually customized in this profile is the <literal>simple-cdd/profiles</literal> preseed parameter: this allows avoiding the question, introduced by Simple-CDD, about what profiles to install.
ru-RU: Профиль <literal>default</literal> играет особую роль, поскольку он всегда выбран; это минимальный профиль, необходимый для работы Simple-CDD. Единственное, что обычно настраивается в этом профиле, — параметр пресидинга <literal>simple-cdd/profiles</literal>: это позволяет избежать вопроса, добавленного Simple-CDD, о том, какие профили необходимо установить.

en: Note also that the commands will need to be invoked from the parent directory of the <filename>profiles</filename> directory.
ru-RU: Заметьте также, что команды потребуется вызывать из родительского каталога по отношению к каталогу <filename>profiles</filename>.

en: Configuring and Using <command>build-simple-cdd</command>
ru-RU: Настройка и использование <command>build-simple-cdd</command>

en: <emphasis>QUICK LOOK</emphasis> Detailed configuration file
ru-RU: <emphasis>КРАТКИЙ ЭКСКУРС</emphasis> Конфигурационный файл в подробностях

en: Simple-CDD requires many parameters to operate fully. They will most often be gathered in a configuration file, which <command>build-simple-cdd</command> can be pointed at with the <literal>--conf</literal> option, but they can also be specified via dedicated parameters given to <command>build-simple-cdd</command>. Here is an overview of how this command behaves, and how its parameters are used:
ru-RU: Simple-CDD для полноценной работы требуется передать множество параметров. Чаще всего они указываются в конфигурационном файле, который передаётся <command>build-simple-cdd</command> с помощью опции <literal>--conf</literal>, но они также могут быть указаны в виде отдельных параметров <command>build-simple-cdd</command>. Вот беглый обзор того, как эта соманда себя ведёт, и как можно использовать эти параметры:

en: the <literal>profiles</literal> parameter lists the profiles that will be included on the generated CD-ROM image;
ru-RU: параметр <literal>profiles</literal> служит для перечисления профилей, которые будут включены на генерируемый образ CD-ROM;

en: based on the list of required packages, Simple-CDD downloads the appropriate files from the server mentioned in <literal>server</literal>, and gathers them into a partial mirror (which will later be given to debian-cd);
ru-RU: на основании списка необходимых пакетов Simple-CDD загружает соответствующие файлы с сервера, указанного в параметре <literal>server</literal>, и собирает их них частичное зеркало (которое будет затем передано debian-cd);

en: the custom packages mentioned in <literal>local_packages</literal> are also integrated into this local mirror;
ru-RU: пользовательские пакеты, указанные в параметре <literal>local_packages</literal>, также включаются в это локальное зеркало;

en: debian-cd is then executed (within a default location that can be configured with the <literal>debian_cd_dir</literal> variable), with the list of packages to integrate;
ru-RU: затем запускается debian-cd (в каталоге по умолчанию, который можно задать с помощью переменной <literal>debian_cd_dir</literal>) со списком пакетов для включения;

en: once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:
ru-RU: когда debian-cd подготовит свой каталог, Simple-CDD вносит в него некоторые изменения:

en: files containing the profiles are added in a <filename>simple-cdd</filename> subdirectory (that will end up on the CD-ROM);
ru-RU: файлы с профилями добавляются в подкаталог <filename>simple-cdd</filename> (который будет записан на CD-ROM);

en: other files listed in the <literal>all_extras</literal> parameter are also added;
ru-RU: также добавляются другие файлы, перечисленные в параметре <literal>all_extras</literal>;

en: the boot parameters are adjusted so as to enable the preseeding. Questions concerning language and country can be avoided if the required information is stored in the <literal>language</literal> and <literal>country</literal> variables.
ru-RU: параметры загрузки изменяются, чобы включить пресидинг. Вопросов о языке и стране можно избежать, если сохранить необходимую информацию в переменных <literal>language</literal> и <literal>country</literal>.

en: debian-cd then generates the final ISO image.
ru-RU: После этого debian-cd генерирует окончательный ISO-образ.

en: Generating an ISO Image
ru-RU: Генерация ISO-образа

en: Monitoring is a generic term, and the various involved activities have several goals: on the one hand, following usage of the resources provided by a machine allows anticipating saturation and the subsequent required upgrades; on the other hand, alerting the administrator as soon as a service is unavailable or not working properly means that the problems that do happen can be fixed sooner.
ru-RU: Мониторинг — это общее понятие, и разные его аспекты преследуют разные цели: с одной стороны, отслеживание использования машинных ресурсов позволяет предсказать их исчерпание и необходимость их увеличения; с другой стороны, уведомление администратора, когда сервис стал недоступен или работает некорректно, означает, что возникающие проблемы будут устраняться скорее.

en: <emphasis>Munin</emphasis> covers the first area, by displaying graphical charts for historical values of a number of parameters (used RAM, occupied disk space, processor load, network traffic, Apache/MySQL load, and so on). <emphasis>Nagios</emphasis> covers the second area, by regularly checking that the services are working and available, and sending alerts through the appropriate channels (e-mails, text messages, and so on). Both have a modular design, which makes it easy to create new plug-ins to monitor specific parameters or services.
ru-RU: <emphasis>Munin</emphasis> покрывает первую область, отображая графики истории ряда параметров (используемой ОЗУ, занятого дискового пространства, загрузки процессора, сетевого трафика, нагрузки Apache/MySQL, и т. п.). <emphasis>Nagios</emphasis> покрывает вторую область, регулярно проверяя, что сервисы работают и доступны, и посылая аварийные уведомления по соответствующим каналам (e-mail, текстовые сообщения и т. п.). Оба построены модульно, что позволяет легко создавать новые плагины для мониторинга специфических параметров и сервисов.

en: <emphasis>ALTERNATIVE</emphasis> Zabbix, an integrated monitoring tool
ru-RU: <emphasis>АЛЬТЕРНАТИВА</emphasis> Zabbix, комплексный инструмент мониторинга

en: <emphasis>ALTERNATIVE</emphasis> Icinga, a Nagios fork
ru-RU: <emphasis>АЛЬТЕРНАТИВА</emphasis> Icinga, ответвление Nagios

en: Setting Up Munin
ru-RU: Настройка Munin

en: The purpose of Munin is to monitor many machines; therefore, it quite naturally uses a client/server architecture. The central host — the grapher — collects data from all the monitored hosts, and generates historical graphs.
ru-RU: Назначение Munin — наблюдать за множеством машин, и вполне естественно, что он имеет клиент-серверную архитектуру. Центральный узел — построитель графиков — собирает данные со всех наблюдаемых узлов и создаёт графики истории.

en: Configuring Hosts To Monitor
ru-RU: Настройка узлов для мониторинга

en: The first step is to install the <emphasis role="pkg">munin-node</emphasis> package. The daemon installed by this package listens on port 4949 and sends back the data collected by all the active plugins. Each plugin is a simple program returning a description of the collected data as well as the latest measured value. Plugins are stored in <filename>/usr/share/munin/plugins/</filename>, but only those with a symbolic link in <filename>/etc/munin/plugins/</filename> are really used.
ru-RU: Первый шаг — установка пакета <emphasis role="pkg">munin-node</emphasis>. Демон, устанавливаемый этим пакетом, слушает порт 4949 и отправляет данные, собранные всеми активными плагинами. Каждый плагин представляет собой простую программу, возвращающую описание собранных данных и последнее измеренное значение. Плагины хранятся в <filename>/usr/share/munin/plugins/</filename>, но на деле используются только те из них, символьные ссылки на которые присутствуют в <filename>/etc/munin/plugins/</filename>.

en: Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves <literal>allow</literal> directives in the <filename>/etc/munin/munin-node.conf</filename> file. The default configuration is <literal>allow ^127\.0\.0\.1$</literal>, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with <command>systemctl restart munin-node</command>.
ru-RU: Когда плагины настроены, следует отредактировать конфигурацию демона, описав правила контроля доступа к собранным данным. Для этого служат директивы <literal>allow</literal> в файле <filename>/etc/munin/munin-node.conf</filename>. Настройка по умолчанию — <literal>allow ^127\.0\.0\.1$</literal>, она разрешает доступ только с локального узла. Обычно администратору требуется добавить аналогичную строку, содержащую IP-адрес узла построения графиков, а затем перезапустить демон с помощью <command>systemctl restart munin-node</command>.

en: <emphasis>GOING FURTHER</emphasis> Creating local plugins
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> Создание локальных плагинов

en: A plugin is best tested when run in the same conditions as it would be when triggered by munin-node; this can be simulated by running <command>munin-run <replaceable>plugin</replaceable></command> as root. A potential second parameter given to this command (such as <literal>config</literal>) is passed to the plugin as a parameter.
ru-RU: Лучше всего тестировать плагин, запуская его в тех же самых условиях, в которых он будет вызываться munin-node; их можно имитировать, запустив <command>munin-run <replaceable>plugin</replaceable></command> от имени суперпользователя. Возможный второй параметр этой команды (например <literal>config</literal>) передаётся как параметр плагину.

en: When a plugin is invoked with the <literal>config</literal> parameter, it must describe itself by returning a set of fields:
ru-RU: Когда плагин вызывается с параметром <literal>config</literal>, он должен описать себя, вернув набор полей:

en: The various available fields are described by the “Plugin reference” available as part of the “Munin guide”. <ulink type="block" url="https://munin.readthedocs.org/en/latest/reference/plugin.html" />
ru-RU: Разные доступные поля описаны в «Справочнике по плагинам», доступному как часть «Руководства Munin». <ulink type="block" url="https://munin.readthedocs.org/en/latest/reference/plugin.html" />

en: When invoked without a parameter, the plugin simply returns the last measured values; for instance, executing <command>sudo munin-run load</command> could return <literal>load.value 0.12</literal>.
ru-RU: Будучи вызванным без параметра, плагин просто возвращает последние измеренные значения; к примеру, вызов <command>sudo munin-run load</command> может вернуть <literal>load.value 0.12</literal>.

en: Finally, when a plugin is invoked with the <literal>autoconf</literal> parameter, it should return “yes” (and a 0 exit status) or “no” (with a 1 exit status) according to whether the plugin should be enabled on this host.
ru-RU: Наконец, когда плагин вызывается с параметром <literal>autoconf</literal>, он должен вернуть «yes» (и статус выхода 0) или «no» (и статус выхода 1) в зависимости от того, следует ли включать плагин на этом узле.

en: Configuring the Grapher
ru-RU: Настройка построителя графиков

en: The “grapher” is simply the computer that aggregates the data and generates the corresponding graphs. The required software is in the <emphasis role="pkg">munin</emphasis> package. The standard configuration runs <command>munin-cron</command> (once every 5 minutes), which gathers data from all the hosts listed in <filename>/etc/munin/munin.conf</filename> (only the local host is listed by default), saves the historical data in RRD files (<emphasis>Round Robin Database</emphasis>, a file format designed to store data varying in time) stored under <filename>/var/lib/munin/</filename> and generates an HTML page with the graphs in <filename>/var/cache/munin/www/</filename>.
ru-RU: «Построитель графиков» — это просто компьютер, собирающий данные и создающий на их основании графики. Необходимое для него программное обеспечение находится в пакете <emphasis role="pkg">munin</emphasis>. Стандартная конфигурация запускает <command>munin-cron</command> (раз в 5 минут), который собирает данные со всех узлов, перечисленных в <filename>/etc/munin/munin.conf</filename> (по умолчанию там указан только локальный узел), сохраняет данные в файлах RRD (<emphasis>Round Robin Database</emphasis> — формат файлов, разработанный для хранения данных, меняющихся со временем), хранящихся в <filename>/var/lib/munin/</filename>, и генерирующий HTML-страницу с графиками в <filename>/var/cache/munin/www/</filename>.

en: All monitored machines must therefore be listed in the <filename>/etc/munin/munin.conf</filename> configuration file. Each machine is listed as a full section with a name matching the machine and at least an <literal>address</literal> entry giving the corresponding IP address.
ru-RU: Итак, все наблюдаемые машины должны быть перечислены в конфигурационном файле <filename>/etc/munin/munin.conf</filename>. Каждая машина указывается как целая секция с именем, соответствующим машине, и как минимум записью <literal>address</literal>, содержащей её IP-адрес.

en: Sections can be more complex, and describe extra graphs that could be created by combining data coming from several machines. The samples provided in the configuration file are good starting points for customization.
ru-RU: Секции могут быть более сложными и описывать дополнительные графики, которые могут быть созданы путём сочетания данных с разных машин. Примеры, приведённые в конфигурационном файле, будут неплохой начальной точкой для настройки.

en: The last step is to publish the generated pages; this involves configuring a web server so that the contents of <filename>/var/cache/munin/www/</filename> are made available on a website. Access to this website will often be restricted, using either an authentication mechanism or IP-based access control. See <xref linkend="sect.http-web-server" /> for the relevant details.
ru-RU: Последний шаг — публикация сгенерированных страниц; для этого требуется настроить веб-сервер таким образом, чтобы содержимое <filename>/var/cache/munin/www/</filename> было доступно на сайте. Доступ к этому сайту зачастую будет ограничен с помощью или механизма аутентификации, или правил контроля доступа по IP-адресам. Подробности см. в <xref linkend="sect.http-web-server" />.

en: Setting Up Nagios
ru-RU: Настройка Nagios

en: Unlike Munin, Nagios does not necessarily require installing anything on the monitored hosts; most of the time, Nagios is used to check the availability of network services. For instance, Nagios can connect to a web server and check that a given web page can be obtained within a given time.
ru-RU: В отличие от Munin, Nagios не требует обязательной установки чего бы то ни было на наблюдаемых узлах; чаще всего Nagios используется для проверки доступности сетевых сервисов. Например, Nagios может подключиться к веб-серверу и проверить, что конкретная веб-страница может быть получена за заданное время.

en: Installing
ru-RU: Установка

en: The first step in setting up Nagios is to install the <emphasis role="pkg">nagios4</emphasis> and <emphasis role="pkg">monitoring-plugins</emphasis> packages. Installing the packages configures the web interface and the Apache server. The <literal>authz_groupfile</literal> and <literal>auth_digest</literal> Apache modules must be enabled, for that execute:
ru-RU: Первым шагом настройки Nagios является установка пакетов <emphasis role="pkg">nagios4</emphasis> и <emphasis role="pkg">monitoring-pluging</emphasis>. При установке настраивается веб-интерфейс и сервер Apache. Модули Apache <literal>authz_groupfile</literal> и <literal>auth_digest</literal> должны быть включены, для этого выполните:

en: Adding other users is a simple matter of inserting them in the <filename>/etc/nagios4/hdigest.users</filename> file.
ru-RU: Для добавления других пользователей надо всего лишь прописать их в файле <filename>/etc/nagios4/hdigest.users</filename>.

en: Pointing a browser at <literal>http://<replaceable>server</replaceable>/nagios4/</literal> displays the web interface; in particular, note that Nagios already monitors some parameters of the machine where it runs. However, some interactive features such as adding comments to a host do not work. These features are disabled in the default configuration for Nagios, which is very restrictive for security reasons.
ru-RU: Открыв в обозревателе <literal>http://<replaceable>server</replaceable>/nagios4/</literal>, можно попасть в веб-интерфейс; заметьте, что Nagios отслеживает некоторые параметры машины, на которой он запущен. Однако некоторые интерактивные функции, такие как добавление комментариев к узлу, не работают. Они выключены в конфигурации Nagios по умолчанию, которая сильно ограничена в целях безопасности.

en: Enabling some features involves editing <filename>/etc/nagios4/nagios.cfg</filename>. We also need to set up write permissions for the directory used by Nagios, with commands such as the following:
ru-RU: Для включения некоторых функций требуется отредактировать <filename>/etc/nagios4/nagios.cfg</filename>. Нам также потребуется дать права на запись в каталог, используемый Nagios, с помощью таких команд:

en: Configuring
ru-RU: Настройка

en: The Nagios web interface is rather nice, but it does not allow configuration, nor can it be used to add monitored hosts and services. The whole configuration is managed via files referenced in the central configuration file, <filename>/etc/nagios4/nagios.cfg</filename>.
ru-RU: Веб-интерфейс Nagios довольно симпатичный, но не позволяет менять настройки или добавлять наблюдаемые узлы и сервисы. Вся конфигурация управляется через файлы, указанные в центральном конфигурационном файле <filename>/etc/nagios4/nagios.cfg</filename>.

en: These files should not be dived into without some understanding of the Nagios concepts. The configuration lists objects of the following types:
ru-RU: В эти файлы не стоит погружаться, не вникнув в некоторые базовые принципы Nagios. В конфигурации перечисляются объекты следующих типов:

en: a <emphasis>host</emphasis> is a machine to be monitored;
ru-RU: <emphasis>host</emphasis> (узел) — машина, которую необходимо наблюдать;

en: a <emphasis>hostgroup</emphasis> is a set of hosts that should be grouped together for display, or to factor some common configuration elements;
ru-RU: <emphasis>hostgroup</emphasis> (группа узлов) — набор узлов, которые следует сгруппировать вместе при отображении или для учёта некоторых общих элементов конфигурации;

en: a <emphasis>service</emphasis> is a testable element related to a host or a host group. It will most often be a check for a network service, but it can also involve checking that some parameters are within an acceptable range (for instance, free disk space or processor load);
ru-RU: <emphasis>service</emphasis> (сервис) — тестируемый элемент, относящийся к узлу или группе узлов. Это, как правило, проверка сетевого сервиса, хотя сюда может входить и проверка, держатся ли некоторые параметры на приемлемом уровне (например свободное дисковое пространство или загрузка процессора);

en: a <emphasis>servicegroup</emphasis> is a set of services that should be grouped together for display;
ru-RU: <emphasis>servicegroup</emphasis> (группа сервисов) — набор сервисов, которые следует сгруппировать вместе при отображении;

en: a <emphasis>contact</emphasis> is a person who can receive alerts;
ru-RU: <emphasis>contact</emphasis> (контакт) — лицо, которому следует направлять аварийные предупреждения;

en: a <emphasis>contactgroup</emphasis> is a set of such contacts;
ru-RU: <emphasis>contactgroup</emphasis> (группа контактов) — набор таких контактов;

en: a <emphasis>timeperiod</emphasis> is a range of time during which some services have to be checked;
ru-RU: <emphasis>timeperiod</emphasis> (временной интервал) — промежуток времени, в течение которого должны быть проверены некоторые сервисы;

en: a <emphasis>command</emphasis> is the command line invoked to check a given service.
ru-RU: <emphasis>command</emphasis> (команда) — командная строка, выполняемая для проверки данного сервиса.

en: According to its type, each object has a number of properties that can be customized. A full list would be too long to include, but the most important properties are the relations between the objects.
ru-RU: У каждого объекта, в соответствии с его типом, есть набор свойств, которые можно менять. Полный список слишком длинен, чтобы приводить его здесь, поэтому отметим только самые важные свойства и отношения между объектами.

en: A <emphasis>service</emphasis> uses a <emphasis>command</emphasis> to check the state of a feature on a <emphasis>host</emphasis> (or a <emphasis>hostgroup</emphasis>) within a <emphasis>timeperiod</emphasis>. In case of a problem, Nagios sends an alert to all members of the <emphasis>contactgroup</emphasis> linked to the service. Each member is sent the alert according to the channel described in the matching <emphasis>contact</emphasis> object.
ru-RU: Сервис использует команду для проверки состояния некой функциональности на узле (или группе узлов) на протяжении временного интервала. В случае проблемы Nagios отправляет предупреждение всем членам группы контактов, привязанной к сервису. Предупреждение отправляется каждому члену в соответствии с каналом, описанным в соответствующем объекте контакта.

en: An inheritance system allows easy sharing of a set of properties across many objects without duplicating information. Moreover, the initial configuration includes a number of standard objects; in many cases, defining new hosts, services and contacts is a simple matter of deriving from the provided generic objects. The files in <filename>/etc/nagios4/conf.d/</filename> are a good source of information on how they work.
ru-RU: Система наследования позволяет легко разделять наборы свойств между объектами без дублирования информации. Более того, начальная конфигурация уже включает набор стандартных объектов; зачастую для определения новых узлов, сервисов и контактов достаточно сделать их потомками стандартных объектов. Файлы в <filename>/etc/nagios4/conf.d/</filename> — хороший источник информации о том, как это работает.

en: The Falcot Corp administrators use the following configuration:
ru-RU: Администраторы Falcot Corp используют следующую конфигурацию:

en: <filename>/etc/nagios4/conf.d/falcot.cfg</filename> file
ru-RU: Файл <filename>/etc/nagios4/conf.d/falcot.cfg</filename>

en: This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a <emphasis>warning</emphasis> is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the <literal>ssh-servers</literal> hostgroup. The matching standard service is defined in <filename>/etc/nagios4/conf.d/services_nagios2.cfg</filename>.
ru-RU: В этом конфигурационном файле описаны два наблюдаемых узла. Первый — веб-сервер, на нём проверяются порты HTTP (80) и HTTPS (443). Nagios также проверяет, что на порту 25 запущен SMTP-сервер. Второй узел — FTP-сервер, для него проверяется среди прочего, что он отвечает в течение 20 секунд. При превышении этого порога отправляется <emphasis>предупреждение</emphasis>; при задержке более 30 секунд ситуация считается критической. Веб-интерфейс Nagios также показывает, что наблюдается сервис SSH: это общая настройка всех узлов группы <literal>ssh-servers</literal>. Соответствующий стандартный сервис определён в <filename>/etc/nagios4/conf.d/services_nagios2.cfg</filename>.

en: Note the use of inheritance: an object is made to inherit from another object with the “use <replaceable>parent-name</replaceable>”. The parent object must be identifiable, which requires giving it a “name <replaceable>identifier</replaceable>” property. If the parent object is not meant to be a real object, but only to serve as a parent, giving it a “register 0” property tells Nagios not to consider it, and therefore to ignore the lack of some parameters that would otherwise be required.
ru-RU: Обратите внимание на использование наследования: то, что объект наследует другому объекту, указывается с помощью «use <replaceable>имя-родителя</replaceable>». Родительский объект должен быть идентифицируемым, для чего ему должно быть установлено свойство «name <replaceable>идентификатор</replaceable>». Если родительский объект не является реальным объектом, а служит только для создания потомков, следует установить есу свойство «register 0»; оно укажет Nagios, что объект не надо учитывать, и тогда нехватка некоторых параметров, которые в ином случае были бы обязательными, будет проигнорирована.

en: <emphasis>DOCUMENTATION</emphasis> List of object properties
ru-RU: <emphasis>ДОКУМЕНТАЦИЯ</emphasis> Список свойств объектов

en: <emphasis>GOING FURTHER</emphasis> Remote tests with NRPE
ru-RU: <emphasis>УГЛУБЛЯЕМСЯ</emphasis> Удалённые проверки с помощью NRPE
