xg-scale
annotate xen/drbd.tex @ 0:4730a0d07d88
Исходники курса после первого прочтения.
Правки (которых должно быть много),
ещё пока не вносились.
Правки (которых должно быть много),
ещё пока не вносились.
author | Igor Chubin <igor@chub.in> |
---|---|
date | Tue Jul 01 16:16:44 2008 +0300 (2008-07-01) |
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} |