Пятница, 29.03.2024, 02:10
Приветствую Вас Гость | RSS
Мой сайт
Главная
Регистрация
Вход
Форма входа

Меню сайта

Категории раздела
Об ОС Windows [137]
В категории размещаются статьи, касающщиеся операционных систем от Microsoft.
Об ОС *Nix [198]
В данной категории собраны статьи об ОС семейства Unix/Linux/FreeBSD/...
Справочные материалы [351]
Справка по всему разделу.
Виртуализация и Облака [46]
Networks & Routing [86]
DataBases [22]

Наш опрос
Оцените мой сайт
Всего ответов: 209

Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0

Главная » Статьи » Системное администрирование » Об ОС *Nix

Xen поверх DRBD (part 2)

[править] Использование

При старте узлов на каждом из них запускаются домены, закреплённые в переменной domain_home.

Ручной запуск машин.

Запуск машины:

 %# xen-drbd start dns

Запуск всех машин:

 %# xen-drbd start-all

Запуск машин, закреплённых за этим хостом (см. domain_home):

 %# xen-drbd start-my-domains

Миграция машин.

Миграция машины dns на другой узел:

 %# xen-drbd migrate-out dns

Миграция всех машин на второй узел:

 %# xen-drbd migrate-out-all

Миграция обратно машин, закреплённых за этим хостом (см. domain_home):

 %# xen-drbd migrate-my-domains-home

При выключении узла, домены можно смигрировать на другой узел:

 %# xen-drbd migrate-out-all

Или, если такое действие указано в /etc/default/xen:

 %# /etc/init.d/xen-drbd stop

Это действие вызывается автоматически при останове узла.

Подробнее об этих и других командах: xen-drbd

[править] Отдельные вопросы эксплуатации xen-drbd

[править] Создание новых устройств DRBD

При синхронизации множества отдельных томов с помощью DRBD нужно обратить внимание на следующее:

  • Количество синхронизируемых устройств DRBD ограничено (<=255);
  • Для синхронизации отдельных устройств DRBD используются отдельные TCP-порты. При добавлении нового DRBD-устройства обратите внимание на то, что бы порт, который вы назначаете ему для синхронизации, уже не был занят.
  • Используйте внешние метадиски, поскольку в случае когда метадиск является внутренним, поведение DRBD при изменении размера логического тома может оказаться неожиданным.

[править] Множество DRBD-устройств

Количество синхронизируемых устройств DRBD ограничено. Максимальное количество используемых одновременно DRBD-устройств задаётся в качестве параметра minor_count модуля ядра drbd при его загрузке. Этот параметр не может превышать 255.

$ sudo modinfo drbd
filename: /lib/modules/2.6.18-4-xen-686/kernel/drivers/block/drbd.ko
author: Philipp Reisner <phil@linbit.com>, Lars Ellenberg <lars@linbit.com>
description: drbd - Distributed Replicated Block Device v8.0.1
license: GPL
alias: block-major-147-*
vermagic: 2.6.18-4-xen-686 SMP mod_unload 686 REGPARM gcc-4.1
depends: cn
parm: trace_devs:int
parm: trace_type:int
parm: trace_level:int
parm: fault_count:int
parm: fault_rate:int
parm: enable_faults:int
parm: allow_oos:DONT USE! (bool)
parm: minor_count:Maximum number of drbd devices (1-255) (int)

[править] Сетевые порты DRBD

Для синхронизации отдельных устройств DRBD используются отдельные TCP-порты. При добавлении нового DRBD-устройства обратите внимание на то, что бы порт, который вы назначаете ему для синхронизации, уже не был занят.

Кроме того, нужно обратить внимание на то, чтобы доступ к этим портам для парного узла не был ограничен брандмауэром.

В примере конфигурационного файла drbd.conf, приведённом ниже, есть строка:

 address 192.168.1.190:7792;

она показывает, что синхронизация ресурса выполняется с узлом 192.168.1.190 и для синхронизации используется порт 7792.

[править] Метадиск

Лучше не использовать внутренний метадиск (meta-disk internal), особенно если вы собираетесь менять размеры соответствующих томов и файловых систем на них.

Нужно создать отдельный том для- meta-disk'ов DRBD и задать его размер равным 128MB x количество устройств.

В пример конфигурационного файла drbd.conf, приведённом ниже,

 meta-disk /dev/XEN/meta[1];

Она говорит о том, что мета-информация об DRBD-устройстве, к которому относится эта строка, должна находится в мета-диске 1 (нумерация с нуля) на томе /dev/XEN/meta. Подготовка этого тома не выполняется каким-то особенным образом — в данном случае это обычный логический том LVM, но вообще это может быть любое блочное устройство достаточного объёма.

Если метадиск создаётся на отдельном логическом томе LVM, то его можно расширять. Расширять метадиск нужно в том случае, когда количество DRBD-устройств, использующих его, превышает допустимое. Это число можно найти, разделив размер метадиска на объём, необходимый для каждого DRBD-устройства (в настоящий момент 128MB).

[править] Пример секции файла drbd.conf

resource dns {
 protocol C;
 net {
 allow-two-primaries;
 after-sb-0pri discard-least-changes;
 after-sb-1pri call-pri-lost-after-sb;
 after-sb-2pri call-pri-lost-after-sb;
 }
 syncer {
 rate 5M;
 }
 on dom0
 {
 device /dev/drbd1;
 disk /dev/XEN/dns;
 address 192.168.1.190:7792;
 meta-disk /dev/XEN/meta[1];
 }
 on dom0m
 {
 device /dev/drbd1;
 disk /dev/XEN/dns;
 address 192.168.1.191:7792;
 meta-disk /dev/XEN/meta[1];
 }
}

[править] Расширение диска DRBD

DRBD-устройство может менять свои размеры. Это возможно в том случае, если меняют размер (как правило, расширяются) устройства на которых базируется DRBD. Когда DRBD работает поверх логических томов LVM, желание расширение DRBD-устройства выглядит весьма естественно, поскольку изменение размеров LVM-томов является вполне простой и часто использующейся операцией; хочется, чтобы то, что работает поверх логического тома LVM, могло отреагировать на изменение размеров.

Расширение DRBD-устройства и файловой системы, находящейся на нём, состоит из следующих шагов:

  1. Расширение логического тома, на котором базируется DRBD-устройство на обоих узлах;
  2. Отражение изменений в метадиске;
  3. Перезагрузка домена Xen, использующего это устройство;
  4. Расширение файловой системы на primary-устройстве;
  5. Проверка правильности выполнения.

Например, пусть:

  • хост называются primary и secondary;
  • с помощью DRBD синхронизируется логический том /dev/TURBO/lv0;
  • размер тома увеличивается на 2G;
  • на томе создана файловая система ext2/ext3;

Все указанные параметры являются необязательными и приведены для удобства повествования.

1) Измените размер тома на обоих машинах.

primary# lvresize -L +2048M /dev/TURBO/lv0
secondary# lvresize -L +2048M /dev/TURBO/lv0

2) Вызовите команду перестроения размера DRBD-устройства на обоих машинах:

primary# drbdadm resize all #(вместо all может быть указан только интересующий диск)
secondary# drbdadm resize all


3)
3.1) Если домен не запущен. На primary-устройстве измените размер файловой системы, расположенной на DRBD-устройстве:

primary# ext2resize /dev/drbd0 # (или другое устройство)

3.2) Если домен, использующий устройство, запущен. Перезагрузите домен, для того чтобы он увидел изменения в размере. После этого выполните ext2resize внутри домена.

Icon-caution.gif

Указать домену Xen, использующему DRBD-устройство, что оно изменило размер, в настоящий момент, к сожалению, невозможно.

В будущем, сообщить об изменении конфигурации дискового устройства домена будет можно, предположительно, с помощью команды xm block-configure.

4) Проверьте, что изменение размера прошло успешно.

primary# df -h /dev/drbd0

Проверка с помощью df возможна только в том случае, если /dev/drbd0 смонтировано в настоящий момент.

Если расширение происходит внутри домена, то проверять наличие свободного места нужно тоже внутри домена.

Размер несмонтированной файловой системы можно тоже посмотреть, но только не в байтах, а в блоках. Для файловых систем ext2/ext3:

%# dumpe2fs /dev/drbd0 | grep ^Block
dumpe2fs 1.40-WIP (14-Nov-2006)
Block count: 979933
Block size: 1024
Blocks per group: 8192


[править] Выключение после синхронизации

Пара DRBD-устройств может находиться в трёх состояниях:

  • Синхронизированном;
  • Синхронизирующемся.
  • Несинхронизирующемся.

В первом случае на обеих частях DRBD-диска находятся одинаковые данные.

Во втором случае правильные данные находятся на одном узле, и они переписываются на второй узел. При этом со временем пара должна прийти к первому состоянию.

В третьем случае неизвестно где именно находятся правильные данные. Для того чтобы решить это требуется административное вмешательство. После того как выяснилось, на каком из узлов данные верны, начинается синхронизация.

Каждый узел при этом характеризуется двумя параметрами:

  • Первичность -- Primary/Secondary;
  • Верность данных -- Inconsistent/Up-to-date.

Первый параметр говорит о том, могут ли записываться данные на этот узел (primary), или он получает данные со второго узла (secondary).

Второй параметр говорит о том, находятся ли на этом диске актуальные данные, или их нужно обновить.

Важно то, что первый параметр не определяет второй и наоборот. Диск может находиться в состоянии secondary и при этом хранить актуальные данные, и наоборот.

В случае когда диск находится в состоянии primary, но при этом состоянии inconsistent, обязательно должно существовать состояние между двумя устройствами. При обращении к Primary-диску DRBD заботится о том чтобы узнать на второй половине актуальные данные и предоставить их. Снаружи это выглядит абсолютно прозрачно. Пользователь работает с DRBD-устройством, не ведая при этом, что данные сейчас синхронизируются между дисками (причём, возможно даже, копируются на тот узел, где DRBD-диск находится в состоянии primary).

Пока оба узла работают, всё в порядке. Проблема возникает, если есть узел находящийся в состоянии secondary/up-to-date, и он выключается.

Необходимо предусмотреть такую возможность, чтобы миграция доменов xen-drbd при выключении производилась только когда синхронизация завершена.

Рекомендуется для этого ввести действия xen-drbd:

  • migrate-out-after-sync domain
  • migrate-out-after-sync-all

Миграция домена в этом случае будет выполняться только после того, как все используемые им устройства полностью синхронизированы. До этого момента команда будет находиться в состоянии ожидания.

Если использовать действие migrate-out-after-sync-all при выключении узла, узел завершит свою работу, только после того как все диски, использующиеся в его доменах, завершат синхронизацию, а домены отмигрируют.


[править] Взаимный контроль узлов с помощью heartbeat

Кластер функционален уже — без настройки и использования heartbeat, однако функциональность его частична: при выходе из строя одного из узлов кластера, доступными останутся только те домены, которые исполнялись на нём в момент выхода из строя второго узла. Оставшиеся домены можно будет поднять, но только вручную. Нужно же, чтобы каждый из узлов имел возможность определить, что его напарник пропал и запустить все недостающие домены. При этом особенно важно избежать случая, когда каждый узел ошибочно решит, что его напарник выключился, в то время как оба они будут работать, но по какой-то причине перестанут видеть друг друга. В этом случае может наступить опасная ситуация, касающаяся взаимной противоречивости данных на DRBD-устройствах, и названная split-brain.

[править] Благодарности

  • Олександру Юдіну и Олегу Дорохину — за помощь при разработке и тестировании и ценные идеи

[править] См. также

Xentaur
Дисковая подсистема
Linux | FreeBSD


Диски и разделы
Файлы устройств: Блочное устройство | Символьное устройство | Raw-устройство | loop-устройство
Диски: IDE | SATA | SCSI | USB
RAID-массивы: Аппаратный RAID | Linux RAID | FreeBSD RAID
Дисковые разделы: Раздел | MBR | fdisk | parted | disklabel

Управление томами
Логический том | Физический том | Группа томов | Снимок | Клон
device-mapper | dm-ioband | dm-crypt | dm-userspace | multipath
Системы управления томами: LVM | CLVM | EVMS | Btrfs* | ZFS* | AdvFS* | Zumastor

Сетевые хранилища и репликация
Отказоустойчивость: DRBD | Xen + DRBD | ggate + gmirror
Сетевые хранилища: AoE | iSCSI | GNBD

Файловые системы
Монтирование | Проверка целостности | Дефрагментация | Суперблок | inode | Журнал | Кэш | VFS | UUID | FUSE
Локальные: ext3 | ext3cow | ext4 | JFS | Reiser4 | XFS | ZFS | Btrfs | AdvFS | ISO
Сетевые: NFS | CIFS | AFS | POHMELFS
Кластерные: GFS | OCFS2 | Lustre | VMFS

* Btrfs, ZFS и AdvFS — это файловые системы с возможностями управления томами
Xen
Xen


Виртуализация и паравиртуализация
Эмуляция | Виртуализация | Паравиртуализация | Рекурсивная виртуализация
Паравиртуальные драйверы | Виртуализация ввода/вывода

Общие вопросы по Xen
Аппаратные требования Xen | Поддержка Xen операционными системами | Поддерживаемые аппаратные архитектуры |
Примеры использования Xen | Сравнение виртуальных машин |
Хостинг на Xen
Альтернативы Xen

свободные: KVM | OpenVZ | VServer | QEMU | VirtualBox
проприетарные: Hyper-V | VMware ESX Server

Технические вопросы
Инсталляция Xen | Конфигурационный файл домена
ОС в Xen: Linux small icon.png Linux | Solaris small icon.png OpenSolaris | Freebsd small icon.png FreeBSD | Openbsd small icon.png OpenBSD | Netbsd small icon.png NetBSD | Windows xp small icon.png Windows XP | Windows vista small icon.png Windows Vista
Устройства: Блочные | USB | SCSI | Сеть | PV-драйверы для Linux | PV-драйверы для Windows | Консоль

Распределение ресурсов между доменами | Перенос системы внутрь Xen | HVM -> PV

Управление и кластеризация | Enomalism | Xen+DRBD | Ganeti | Convirt 2.0


Источник: http://xgu.ru/wiki/%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B4%D0%BE%D0%BC%D0%
Категория: Об ОС *Nix | Добавил: admin (07.08.2011)
Просмотров: 3257 | Комментарии: 1 | Теги: lvm, Cluster, xen, config, Linux, gfs | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *:
Поиск

Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz


  • Copyright MyCorp © 2024