Зеркалирование дисков по сети


Сергей бриз отзывы - инвестиции и трейдинг по методам сергея бриза www.rureviews.ru.

Два сервера могут использовать единственный образ диска. Когда данные записываются на один диск, они автоматически копируются на другой. Эту особенность можно использовать для достижения определенного уровня высокой доступности при использовании аппаратных средств массового потребления. Используйте утилиту ggated(8), чтобы экспортировать диск, и gmirror(8) для его дублирования.

Не забывайте, что скорость передачи данных по сети намного ниже скорости обмена данными с диском, поэтому зеркалирование дисков по сети — не самое лучшее решение при интенсивных операциях ввода-вывода. Например, я ожидаю, что к тому моменту, когда вы будете читать эти строки, широкое распространение получат диски 3Gbps SATA-II. Это три гигабита в секунду, или в три раза больше скорости передачи в гигабитной сети! Если скорость обмена с диском действительно будет составлять 3 Гбит/сек, то, учитывая тот факт, что не все гигабитные сетевые устройства фактически работают на скорости в один гигабит, резервное копирование по сети сильно разочарует вас. Однако в случае приложений с небольшим объемом ввода-вывода зеркалирование по сети дисков с важными данными может оказаться полезным.

В приведенном ниже примере выполняется зеркалирование по сети файловой системы в файле размером 100 Мбайт. Этот объем достаточно велик, чтобы его хватило, скажем, для небольшой базы данных, но слишком мал, чтобы работать в моей скромной сети.

Настройка сервера резервной копии

Создайте файл размером 100 Мбайт на одном сервере и скопируйте его на другой сервер. Таким образом, у нас изначально будет один и тот же файл с данными по обеим сторонам соединения, что поможет уменьшить время синхронизации. Проще всего создать файл с помощью утилиты truncate(1):*

# truncate -s100m /var/db/dbmirrorbackup.img

Ключ -s команды truncate(1) определяет размер создаваемого файла. Допустимы следующие сокращения: k — килобайты, m — мегабайты и G — гигабайты. (Есть еще t — для обозначения терабайтов, но у нас нет дисков такой емкости. Пока.)

Теперь сконфигурируем /etc/gg.exports, чтобы позволить первичному серверу получить доступ к этому диску. Первичный сервер (в примере его IP-адрес 192.168.1.2) требует наличия привилегий доступа к диску «чтение-запись»:

192.168.1.2     RW     /var/db/dbmirrorbackup.img

Теперь запустим ggated(8) — и сервер резервной копии готов к работе.

Настройка первичного сервера

Настроить первичный сервер сложнее, но ненамного. Сначала нужно подключить устройство ggate к удаленному файлу:

# ggatec create backupserver /var/db/dbmirror.img
ggate0

Теперь удаленный файл с файловой системой доступен локально как устройство /dev/ggate0. Затем загрузим gmirror(8) и пометим устройство ggate как зеркало. Здесь наше зеркальное устройство называется remotemirror0:

# gmirror load
# gmirror label remotemirror0 /dev/ggate0

Теперь у нас есть зеркальное устройство. Нам нужно создать локальный файл с файловой системой, точно так же, как был создан резервный файл с файловой системой:

# truncate -s100m /var/db/dbmirrorprimary.img

Подключим локальный файл к устройству памяти, чтобы получить файл устройства, и затем вставим это устройство в зеркало:

# mdconfig -a -t vnode -f /var/db/dbmirrorprimary.img
md0
# gmirror insert remotemirror0 /dev/md0

Вы увидите, насколько быстро произойдет синхронизация. Это потому, что там еще нет данных!

# gmirror status
                Name    Status  Components
mirror/remotemirror0  DEGRADED  ggate0
                                md0 (33%)

По окончании синхронизации зеркала, что должно занять не больше пары минут для файловой системы такого размера, используйте newfs(8) и смонтируйте ее:

# newfs -U /dev/mirror/remotemirror0
# mount /dev/mirror/remotemirror0 /database

Теперь у нас имеется распределенное зеркало, смонтированное в каталоге /database.

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

Аварийные ситуации с зеркалом и восстановление

Зеркальный диск нужен для восстановления данных после выхода из строя диска, а сетевой зеркальный диск — после выхода из строя сервера. В комбинации с зеркальными дисками вы можете использовать программу heartbeat (/usr/ports/sysutils/heartbeat), что позволит реализовать недорогое и высоконадежное решение, когда одна система автоматически принимает на себя функции другой системы в случае ее выхода из строя. При использовании heartbeat резервная система следит за основной системой и приступает к работе, как только основная система исчезает из сети.

В такой схеме основным сервером может быть ваша клиентская машина, которая выполняет все необходимые операции большую часть времени. Но в случае появления неполадок резервная машина возьмет на себя роль основной машины. Резервная машина может активизировать свою копию зеркала с помощью команд mdconfig(8) и mount(8):

# mdconfig -a -t vnode -f dbmirrorbackup.img
md0
# fsck -B /dev/md0
# mount /dev/md0 /database

После этого можно запустить программу сервера базы данных и использовать данные зеркального раздела.

Когда основная система вернется в строй, она снова подключит резервный файл как устройство ggate, пометит его как зеркало, вставит локальный раздел в зеркало и даст зеркалу возможность синхронизироваться из резервной копии. По окончании синхронизации heartbeat сможет переключить работу сервиса обратно на основную машину. Создать сценарий автоматической обработки аварийных ситуаций не так сложно, но для этого нужно учитывать множество деталей реализации и окружения, поэтому его создание оставляю вам.

Высоконадежная система, как в данном примере, станет еще надежнее, если применять базу данных, использующую механизм транзакций, такую как PostgreSQL, в противоположность MySQL.* Будет совсем неплохо, если вам удастся свести к минимуму объем «оперативных» данных на зеркальном разделе и уделить основное внимание периодическому архивированию данных на другом диске удаленного сервера. Высокая надежность требует внимательного отношения к проектированию приложения, и к этому следует относиться серьезно.

На этом мы закончили наш тур по наиболее популярным модулям платформы GEOM. В операционной системе FreeBSD вы найдете множество других интересных модулей, но обладая знаниями, полученными в этой главе, вы безболезненно сможете их использовать. А теперь перейдем к теме, близкой сердцу любого системного администратора: производительность.

Комментарии запрещены.