xg-scale

annotate xen/drbd.tex @ 6:4a790b55d005

find changesets by author, revision, files, or words in the commit message
Обновлен раздел по Windows XP. Исправлен стиль, добавлены некоторые уточнения по конфигурационному файлу
author Igor Chubin <igor@chub.in>
date Wed Jul 09 08:50:18 2008 +0300 (2008-07-09)
parents
children
rev   line source
igor@0 1 \section{Построение отказоустойчивого кластера виртуальных машин Xen + DRBD}
igor@0 2
igor@0 3 \subsection{Идея}
igor@0 4 Компоненты:
igor@0 5 \begin{itemize}
igor@0 6 \item \textbf{Xen} — монитор виртуальных машин (VMM, Virtual Machine Monitor) или гипервизор (hypervisor) с поддержкой паравиртуализации (para-virtualization) для процессоров x86 архитектуры, распространяющийся с открытым исходным кодом (opensource). Xen может организовать совместное безопасное исполнение нескольких виртуальных машин на одной физической системе с производительностью близкой к непосредственной (native).
igor@0 7 \item \textbf{LVM} (Logical Volume Manager) — менеджер логических томов операционной системы Linux. LVM предоставляет собой дополнительный уровень абстракции между физическими/логическими дисками и файловой системой.
igor@0 8 \item \textbf{DRBD} (Distributed Replicated Block Deice) — блочное устройство, предназначенное для построения отказоустойчивых кластерных систем на операционной системе Linux. DRBD занимается полным отражением (mirroring) по сети всех операций с блочным устройством. Можно считать, что DRBD это сетевой RAID-1.
igor@0 9 \end{itemize}
igor@0 10
igor@0 11 Терминология:
igor@0 12 \begin{itemize}
igor@0 13 \item узел — физический сервер, на котором исполняются виртуальные машины;
igor@0 14 \item DRBD-устройство — дисковый раздел или логический том LVM, синхронизируемый с помощью DRBD;
igor@0 15 \item домен — работающая виртуальная машина Xen;
igor@0 16 \item кластер — два узла, которые имеют общие DRBD-устройства, поверх которых выполняются общие домены Xen.
igor@0 17 \end{itemize}
igor@0 18
igor@0 19 Идея заключается в том, чтобы в качестве дисковых устройств для виртуальных машин Xen,
igor@0 20 использовать DRBD-устройства. DRBD устройства в свою очередь размещаются поверх LVM томов машин входящих в кластер.
igor@0 21
igor@0 22 DRBD отвечает за полную синхронизацию операций с дисковыми системами, выполняющимися доменами Xen.
igor@0 23
igor@0 24 С точки зрения внешнего наблюдателя не имеет значения, на каком из узлов кластера
igor@0 25 в настоящий момент выполняется виртуальная машина.
igor@0 26
igor@0 27 При плановом выведении узла из эксплуатации,
igor@0 28 машины, работающие на нём, мигрируют на второй узел кластера.
igor@0 29 Это совершенно незаметно с точки зрения внешнего наблюдателя.
igor@0 30
igor@0 31 При внезапной остановке одного из узлов машины,
igor@0 32 работавшие на нём, запускаются на втором узле.
igor@0 33 С точки зрения внешнего наблюдателя, работавшего с виртуальной машиной,
igor@0 34 которая исполнялась на внезапно выключившемся узле, это выглядит
igor@0 35 как перезагрузка машины.
igor@0 36
igor@0 37 Виртуальные машины могут быть произвольно распределены по узлам кластера.
igor@0 38
igor@0 39 \begin{center} \resizebox{10cm}{!}{\includegraphics{/var/lib/mediawiki/images/4/4b/Xen-drbd.png}}\\ \textit{}\end{center}
igor@0 40
igor@0 41 \subsection{Инсталляция и управление кластером}
igor@0 42 \subsubsection{Подготовка узлов}
igor@0 43
igor@0 44 Подготовка узлов может выполняться вручную или с помощью
igor@0 45 вспомогательных средств, таких, например, как скрипт \textit{xen-drbd-install}.
igor@0 46 Скрипт \textit{xen-drdb-install} предназначен для облегчения
igor@0 47 рутинных операций, выполняющихся при инсталляции
igor@0 48 нового кластера виртуализации с повышенной отказоустойчивостью,
igor@0 49 построенного на основе Xen и DRBD.
igor@0 50
igor@0 51 В результате работы \textit{xen-drbd-install}
igor@0 52 создаётся сценарий командного интерпретатора,
igor@0 53 который выполняет такие действия:
igor@0 54 \begin{enumerate}
igor@0 55 \item Подготовка LVM томов;
igor@0 56 \item Настройка DRBD устройств;
igor@0 57 \item Наполнение файловых систем доменов.
igor@0 58 \end{enumerate}
igor@0 59
igor@0 60 Полученный сценарий может быть доработан вручную,
igor@0 61 а может использоваться непосредственном в том
igor@0 62 виде, как его сгенерирует \textit{xen-drbd-install}.
igor@0 63
igor@0 64 \subsubsection{Управление узлами}
igor@0 65
igor@0 66 Скрипт \textit{xen-drbd}
igor@0 67 обеспечивает взаимное соответсвие
igor@0 68 состояния DRBD-устройств и доменов Xen, использующих их.
igor@0 69 Он следит за тем, чтобы при выполнении таких
igor@0 70 операций как запуск и миграция доменов,
igor@0 71 используемые DRBD-устройства
igor@0 72 переключались основное (primary) или резервное (secondary) состояние
igor@0 73 в зависимости от точки запуска или направления миграции.
igor@0 74
igor@0 75 Он также следит за тем, чтобы один и тот же домен
igor@0 76 нельзя было запустить на разных узлах кластера
igor@0 77 несколько раз.
igor@0 78
igor@0 79 Кроме этого, \textit{xen-drbd} контролирует процесс запуска и останова узлов:
igor@0 80 он инициирует миграцию доменов с одного узла на другой в случае
igor@0 81 останова первого; и обратную миграцию при запуске узла.
igor@0 82
igor@0 83 \subsection{Взаимный контроль узлов с помощью heartbeat}
igor@0 84 Кластер функционален уже — без настройки и использования heartbeat —
igor@0 85 однако функциональность его частична:
igor@0 86 при выходе из строя одного из узлов кластера
igor@0 87 доступными останутся только те домены, которые
igor@0 88 исполнялись на нём в момент выхода из строя второго узла.
igor@0 89 Оставшиеся домены можно будет поднять, но только вручную.
igor@0 90 Нужно же, чтобы каждый из узлов имел возможность определить,
igor@0 91 что его напарник пропал, и запустить все недостающие домены.
igor@0 92 При этом особенно важно избежать случая, когда каждый узел
igor@0 93 ошибочно решит, что его напарник выключился, в то время как
igor@0 94 оба они будут работать, но по какой-то причине перестанут видеть друг друга.
igor@0 95 В этом случае может наступить опасная ситуация, касающаяся взаимной противоречивости данных на DRBD-устройствах, и названная \textit{split-brain}.
igor@0 96
igor@0 97 \subsection{Резервирование коммутаторов и сетевых адаптеров}
igor@0 98 \subsubsection{Использование аггрегированных каналов}
igor@0 99 Сетевые адаптеры узлов могут быть зарезервированы
igor@0 100 путём аггрегирования каналов,
igor@0 101 соединяющих узел с коммутатором.
igor@0 102
igor@0 103 В каждом сервере должно быть по два сетевых адаптера,
igor@0 104 каждый из которых подключается к коммутатору.
igor@0 105 Они работают как единое целое, то есть два канала
igor@0 106 выглядят как один аггрегированный.
igor@0 107
igor@0 108 При пропадении одного из соединений (это может быть связано
igor@0 109 с неполадками адаптера, соединительного кабеля или порта коммутатора)
igor@0 110 система продолжает работу на оставшемся.
igor@0 111 В системном журнале появляется сообщение о
igor@0 112 возникшей проблеме.
igor@0 113
igor@0 114 Для работы аггрегированного канала необходима поддержка
igor@0 115 со стороны коммутатора:
igor@0 116 \begin{itemize}
igor@0 117 \item он должен поддерживать аггрегированные каналы;
igor@0 118 \item он должен быть настроен соответствующим образом.
igor@0 119 \end{itemize}
igor@0 120
igor@0 121 \subsubsection{Использование виртуального моста и STP}
igor@0 122 Построить аггрегированный канал на два независимых коммутатора
igor@0 123 нельзя (за некоторыми проприетарными исключениями).
igor@0 124
igor@0 125 Можно отказаться от использования аггрегированного канала
igor@0 126 и с некоторой потерей функциональности перейти на использование
igor@0 127 протокола STP и виртуального моста.
igor@0 128 Это позволит сделать резервирование коммутатора, однако
igor@0 129 у такого решения есть недостаток:
igor@0 130 в отдельно взятый момент времени будет работать один из каналов.
igor@0 131
igor@0 132 Подключение одного узла выглядит так:
igor@0 133 \begin{verbatim}
igor@0 134 +---------------------------+
igor@0 135 |HOST peth0 |
igor@0 136 | +--+ | +--------------+
igor@0 137 | +------+ +-+------| switch1 |
igor@0 138 | | +--+ | +---+----------+
igor@0 139 |veth0+---------+----+ | |
igor@0 140 | ---+ linux bridge | | |
igor@0 141 | +---------+----+ | |
igor@0 142 | | +--+ | +---+----------+
igor@0 143 | +------+ +-+------+ switch2 |
igor@0 144 | +--+ | +--------------+
igor@0 145 | peth1 |
igor@0 146 +---------------------------+
igor@0 147 \end{verbatim}
igor@0 148
igor@0 149 Соединения с коммутаторами происходят не напрямую
igor@0 150 а через виртуальных мост (linux bridge) внутри хоста.
igor@0 151 Этот мост поддерживает протокол STP
igor@0 152 и в этом контексте может рассматриваться как обычный
igor@0 153 коммутатор, который не может выйти из строя (точнее,
igor@0 154 может, но только вместе с хостом, внутри которого он работает).
igor@0 155
igor@0 156 Соединенние двух коммутаторов и двух узлов выглядит так
igor@0 157 (соединения heartbeat может и не быть, в этом случае
igor@0 158 в качестве heartbeat-канала будут использоваться
igor@0 159 основные соединения):
igor@0 160 \begin{verbatim}
igor@0 161 +---------------------------+
igor@0 162 |HOST1 peth0 |
igor@0 163 | +--+ | +--------------+
igor@0 164 | +------+ +-+------| switch1 |
igor@0 165 | | +--+ | ++--+----------+
igor@0 166 |veth0+---------+----+ | +---+ |
igor@0 167 | ---+ linux bridge | | | |
igor@0 168 | +---------+----+ | | |
igor@0 169 | | +--+ | | +---+----------+
igor@0 170 | +------+ +-+---|--+ switch2 |
igor@0 171 | +--+ | | +---+----------+
igor@0 172 | peth1 | | |
igor@0 173 +-------+-------------------+ | |
igor@0 174 | | |
igor@0 175 |heartbeat | |
igor@0 176 +-------+-------------------+ | |
igor@0 177 |HOST2 peth0 | | |
igor@0 178 | +--+ | | |
igor@0 179 | +------+ +-+---+ |
igor@0 180 | | +--+ | |
igor@0 181 |veth0+---------+----+ | |
igor@0 182 | ---+ linux bridge | | |
igor@0 183 | +---------+----+ | |
igor@0 184 | | +--+ | |
igor@0 185 | +------+ +-+----------+
igor@0 186 | +--+ |
igor@0 187 | peth1 |
igor@0 188 +---------------------------+
igor@0 189 \end{verbatim}
igor@0 190
igor@0 191 \subsubsection{Сравнение использования аггрегированных каналов и виртуального моста}
igor@0 192 Минусы:
igor@0 193
igor@0 194 \begin{enumerate}
igor@0 195 \item Каналы не объединияются, а используются попеременно.
igor@0 196 \item Переключение с одного канала на другой происходит достаточно долго. При настройках коммутатора по умолчанию процесс переключения может занять до минуты. Это связано с работой STP. В RSTP было бы быстрее, но RSTP Linux Bridge пока не поддерживает.
igor@0 197 \end{enumerate}
igor@0 198
igor@0 199 Плюсы:
igor@0 200
igor@0 201 \begin{enumerate}
igor@0 202 \item От коммутаторов ничего не требуется кроме поддержки STP;
igor@0 203 \item Можно подключаться к двум независимым коммутаторам;
igor@0 204 \item Не требуется никакая дополнительная настройка коммутаторов.
igor@0 205 \end{enumerate}
igor@0 206
igor@0 207 \subsection{Отдельные вопросы эксплуатации xen-drbd}
igor@0 208 \subsubsection{Создание новых устройств DRBD}
igor@0 209 При синхронизации множества отдельных томов с помощью DRBD
igor@0 210 нужно обратить внимание на следующее:
igor@0 211 \begin{itemize}
igor@0 212 \item Количество синхронизируемых устройств DRBD ограничено (<=255);
igor@0 213 \item Для синхронизации отдельных устройств DRBD используются отдельные TCP-порты. При добавлении нового DRBD-устройства обратите внимание на то, что бы порт, который вы назначаете ему для синхронизации, уже не был занят.
igor@0 214 \item Используйте внешние метадиски, поскольку в случае когда метадиск является внутренним, поведение DRBD при изменении размера логического тома может оказаться неожиданным.
igor@0 215 \end{itemize}
igor@0 216
igor@0 217 \paragraph{Множество DRBD-устройств}
igor@0 218 Количество синхронизируемых устройств DRBD ограничено.
igor@0 219 Максимальное количество используемых одновременно DRBD-устройств
igor@0 220 задаётся в качестве параметра \texttt{minor\_count} модуля ядра \textbf{drbd}
igor@0 221 при его загрузке. Этот параметр не может превышать 255.
igor@0 222
igor@0 223 \begin{verbatim}
igor@0 224 $ sudo modinfo drbd
igor@0 225 filename: /lib/modules/2.6.18-3-xen-686/kernel/drivers/block/drbd.ko
igor@0 226 author: Philipp Reisner <phil@linbit.com>, Lars Ellenberg <lars@linbit.com>
igor@0 227 description: drbd - Distributed Replicated Block Device v8.0.0
igor@0 228 license: GPL
igor@0 229 alias: block-major-147-*
igor@0 230 vermagic: 2.6.18-3-xen-686 SMP mod_unload 686 REGPARM gcc-4.1
igor@0 231 depends: cn
igor@0 232 parm: trace_devs:int
igor@0 233 parm: trace_type:int
igor@0 234 parm: trace_level:int
igor@0 235 parm: fault_count:int
igor@0 236 parm: fault_rate:int
igor@0 237 parm: enable_faults:int
igor@0 238 parm: allow_oos:DONT USE! (bool)
igor@0 239 parm: minor_count:Maximum number of drbd devices (1-255) (int)
igor@0 240 \end{verbatim}
igor@0 241
igor@0 242 \paragraph{Сетевые порты DRBD}
igor@0 243 Для синхронизации отдельных устройств DRBD используются отдельные TCP-порты.
igor@0 244 При добавлении нового DRBD-устройства обратите внимание на то, что бы порт,
igor@0 245 который вы назначаете ему для синхронизации, уже не был занят.
igor@0 246
igor@0 247 Кроме того, нужно обратить внимание на то, чтобы доступ к этим портам
igor@0 248 для парного узла не был ограничен брандмауэром.
igor@0 249
igor@0 250 В пример ниже есть строка:
igor@0 251 \begin{verbatim}
igor@0 252 address 192.168.1.190:7792;
igor@0 253 \end{verbatim}
igor@0 254 она показывает, что синхронизация ресурса
igor@0 255 выполняется с узлом 192.168.1.190 и для сихнронизации используется
igor@0 256 порт 7792.
igor@0 257
igor@0 258 \paragraph{Метадиск}
igor@0 259 Лучше не использовать внуренний метадиск (meta-disk internal),
igor@0 260 особенно если вы собираетесь менять размер логического тома
igor@0 261 LVM и файловой системы на нём.
igor@0 262
igor@0 263 Нужно создать отдельный том для-
igor@0 264 meta-disk\rq{}ов DRBD и задать его размер
igor@0 265 равным 128MB x количество устройств.
igor@0 266
igor@0 267 В пример конфигурационного файла <tt>drbd.conf</tt>,
igor@0 268 приведённом ниже, есть строка:
igor@0 269 \begin{verbatim}
igor@0 270 meta-disk /dev/XEN/meta[1];
igor@0 271 \end{verbatim}
igor@0 272 Она говорит о том, что мета-информация
igor@0 273 об DRBD-устройстве, к которому относится эта строка,
igor@0 274 должна находится в мета-диске 1 (нумерация с нуля)
igor@0 275 на томе \texttt{/dev/XEN/meta}.
igor@0 276 Подготовка этого тома не выполняется каким-то
igor@0 277 особенным образом — в данном случае это обычный
igor@0 278 логический том LVM, но вообще это может быть любое блочное
igor@0 279 устройство достаточного объёма.
igor@0 280
igor@0 281 Если метадиск создаётся на отдельном логическом
igor@0 282 томе LVM, то его можно расширять.
igor@0 283 Расширять метадиск нужно в том случае,
igor@0 284 когда количество DRBD-устройств, использующих
igor@0 285 его, превышает допустимое.
igor@0 286 Это число можно найти, разделив размер метадиска
igor@0 287 на объём, необходимый для каждого DRBD-устройства
igor@0 288 (в настоящий момент 128MB).
igor@0 289
igor@0 290 \paragraph{Пример секции файла drbd.conf}
igor@0 291
igor@0 292 \begin{verbatim}
igor@0 293 resource dns {
igor@0 294 protocol C;
igor@0 295 net {
igor@0 296 allow-two-primaries;
igor@0 297 after-sb-0pri discard-least-changes;
igor@0 298 after-sb-1pri call-pri-lost-after-sb;
igor@0 299 after-sb-2pri call-pri-lost-after-sb;
igor@0 300 }
igor@0 301 syncer {
igor@0 302 rate 5M;
igor@0 303 }
igor@0 304 on dom0
igor@0 305 {
igor@0 306 device /dev/drbd1;
igor@0 307 disk /dev/XEN/dns;
igor@0 308 address 192.168.1.190:7792;
igor@0 309 meta-disk /dev/XEN/meta[1];
igor@0 310 }
igor@0 311 on dom0m
igor@0 312 {
igor@0 313 device /dev/drbd1;
igor@0 314 disk /dev/XEN/dns;
igor@0 315 address 192.168.1.191:7792;
igor@0 316 meta-disk /dev/XEN/meta[1];
igor@0 317 }
igor@0 318 }
igor@0 319 \end{verbatim}
igor@0 320
igor@0 321 \subsubsection{Расширение диска DRBD}
igor@0 322 DRBD-устройство может менять свои размеры.
igor@0 323 Это возможно в том случае, если меняют размер (как правило, расширяются)
igor@0 324 устройства на которых базируется DRBD.
igor@0 325 Когда DRBD работает поверх логических томов LVM,
igor@0 326 желание расширение DRBD-устройства выглядит весьма естественно,
igor@0 327 поскольку изменение размеров LVM-томов
igor@0 328 является вполне простой и часто использующейся операцией;
igor@0 329 хочется, чтобы то, что работает поверх логического тома LVM
igor@0 330 могло отреагировать на изменение размеров.
igor@0 331
igor@0 332 Расширение DRBD-устройства и файловой системы, находящейся на нём, состоит из
igor@0 333 следующих шагов:
igor@0 334 \begin{enumerate}
igor@0 335 \item Расширение \textit{логического тома}, на котором базируется DRBD-устройство на обоих узлах.
igor@0 336 \item Отражение изменений в метадиске.
igor@0 337 \item Расширение \textit{файловой системы} на primary-устройстве.
igor@0 338 \item Проверка правильности выполнения.
igor@0 339 \end{enumerate}
igor@0 340
igor@0 341 Например, пусть:
igor@0 342 \begin{itemize}
igor@0 343 \item машины называются \textit{primary} и \textit{secondary}
igor@0 344 \item с помощью DRBD синхронизируется логический том /dev/TURBO/lv0
igor@0 345 \item размер тома увеличивается на 2G
igor@0 346 \item на томе создана файловая система ext2/ext3
igor@0 347 \end{itemize}
igor@0 348 Все указанные параметры являются необязательными
igor@0 349 и приведены для удобства повествования.
igor@0 350
igor@0 351 1) Измените размер тома на обоих машинах.
igor@0 352
igor@0 353 \begin{verbatim}
igor@0 354 primary# lvresize -L +2048M /dev/TURBO/lv0
igor@0 355 secondary# lvresize -L +2048M /dev/TURBO/lv0
igor@0 356 \end{verbatim}
igor@0 357
igor@0 358 2) Вызовите команду перестроения размера
igor@0 359 DRBD-устройства на обоих машинах:
igor@0 360
igor@0 361 \begin{verbatim}
igor@0 362 primary# drbdadm resize all #(вместо all может быть указан только интересующий диск)
igor@0 363 secondary# drbdadm resize all
igor@0 364 \end{verbatim}
igor@0 365
igor@0 366 3) На primary-устройстве измените размер файловой системы,
igor@0 367 расположенной на DRBD-устройстве:
igor@0 368
igor@0 369 \begin{verbatim}
igor@0 370 primary# ext2resize /dev/drbd0 # (или другое устройство)
igor@0 371 \end{verbatim}
igor@0 372
igor@0 373 4) Проверьте, что изменение размера прошло успешно.
igor@0 374
igor@0 375 \begin{verbatim}
igor@0 376 primary# df -h /dev/drbd0
igor@0 377 \end{verbatim}
igor@0 378
igor@0 379 Проверка с помощью df возможна только в том случае,
igor@0 380 если \texttt{/dev/drbd0} смонтировано в настоящий момент.
igor@0 381
igor@0 382 Размер несмонтированной файловой системы можно тоже посмотреть,
igor@0 383 но только не в байтах, а в блоках.
igor@0 384 Для файловых систем ext2/ext3:
igor@0 385
igor@0 386 \begin{verbatim}
igor@0 387 %# dumpe2fs /dev/drbd0 | grep ^Block
igor@0 388 dumpe2fs 1.40-WIP (14-Nov-2006)
igor@0 389 Block count: 979933
igor@0 390 Block size: 1024
igor@0 391 Blocks per group: 8192
igor@0 392 \end{verbatim}
igor@0 393
igor@0 394 Указать домену Xen, использующему DRBD-устройство,
igor@0 395 что оно изменило размер, в настоящий момент,
igor@0 396 к сожалению, невозможно.
igor@0 397
igor@0 398 В будущем, сообщить об изменении конфигурации
igor@0 399 дискового устройства домена будет можно, предположительно,
igor@0 400 с помощью команды \textbf{xm block-configure}.
igor@0 401
igor@0 402 \subsubsection{Проверка DRBD перед стартом виртуальной машины}
igor@0 403 Можно сделать так, чтобы виртуальная машина
igor@0 404 вообще не стартовала до тех пор,
igor@0 405 пока соответствующее DRBD-устройство не будет переведено
igor@0 406 в состояние primary
igor@0 407 (на устройстве в состоянии secondary она может начать работать,
igor@0 408 но, когда внутреняя операционная система дойдёт до момента
igor@0 409 монтирования корневой файловой системы, загрузка прекратится;
igor@0 410 в действительности это устройство вообще не используется до момента
igor@0 411 монтирования корневой системы, поэтому первый этап загрузки
igor@0 412 операционной системы домена проходит без ошибок).
igor@0 413
igor@0 414 Предположим, машина использует в качестве своего хранилища
igor@0 415 устройство /dev/drbd4. В таком случае,
igor@0 416 проверка будет выглядеть так:
igor@0 417
igor@0 418 \begin{verbatim}
igor@0 419 import os
igor@0 420 if os.system("grep '4:.*Primary/Secondary' /proc/drbd") != 0:
igor@0 421 print "DRBD for this virtual machine not in primary state."
igor@0 422 print "Exiting."
igor@0 423 exit(1)
igor@0 424 \end{verbatim}
igor@0 425
igor@0 426 Эти строки нужно добавить в конфигурационный файл соответствующего
igor@0 427 домена Xen.
igor@0 428
igor@0 429 Пример использования:
igor@0 430
igor@0 431 \begin{verbatim}
igor@0 432 %$ sudo drbdadm secondary vpn
igor@0 433
igor@0 434 %$ sudo xm create -c vpn
igor@0 435 Using config file "/etc/xen/vpn".
igor@0 436 DRBD for this virtual machine not in primary state.
igor@0 437 Exiting.
igor@0 438 Error: 'str' object is not callable
igor@0 439
igor@0 440 %$ sudo drbdadm primary vpn
igor@0 441
igor@0 442 %$ sudo xm create -c vpn
igor@0 443 Using config file "/etc/xen/vpn".
igor@0 444 4: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
igor@0 445 Started domain vpn
igor@0 446 Linux version 2.6.18-4-xen-686 (Debian 2.6.18.dfsg.1-11)
igor@0 447 (waldi@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian
igor@0 448 4.1.1-21)) #1 SMP Wed Feb 21 20:46:15 UTC 2007
igor@0 449 BIOS-provided physical RAM map:
igor@0 450 Xen: 0000000000000000 - 0000000004800000 (usable)
igor@0 451 0MB HIGHMEM available.
igor@0 452 72MB LOWMEM available.
igor@0 453 .......
igor@0 454 \end{verbatim}
igor@0 455
igor@0 456 Когда DRBD-устройство \textit{vpn} было в резервном состоянии (secondary),
igor@0 457 создать домен не удалось.
igor@0 458 После того как оно было переведено
igor@0 459 в основное состояние (primary), домен успешно стартанул.
igor@0 460
igor@0 461 Если для управления доменами Xen используется скрипт \textit{xen-drbd},
igor@0 462 то эту проверку выполнять не нужно.
igor@0 463 Она автоматически выполняется скриптом.
igor@0 464
igor@0 465 \subsection{Дополнительная информация}
igor@0 466 \begin{itemize}
igor@0 467 \item \htmladdnormallinkfoot{Использование доменов Xen поверх DRBD-устройств}{http://xgu.ru/wiki/xen/drbd} (рус.)
igor@0 468 \end{itemize}