Создание надёжного iSCSI-хранилища на Linux, часть 2
Продолжаем Продолжаем создание кластера, начатое первой части. На этот раз я расскажу про настройку кластера. В прошлый раз мы закончили на том, что началась синхронизация DRBD. Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:# cat /proc/drbd version: 8.4.3 (api:1/proto:86–101) GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013–04–30 07:43:49 0: cs: Connected ro: Secondary/Primary ds: UpToDate/UpToDate B r----- ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo: d oos:0 1: cs: Connected ro: Secondary/Primary ds: UpToDate/UpToDate B r----- ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo: d oos:0 Самое интересное поле тут ds: UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны. После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:# drbdadm secondary VM_STORAGE_1 # drbdadm secondary VM_STORAGE_2 Pacemaker Итак, менеджер кластера. Если коротко, то это мозг всей системы, который управляет абстракциями, называемыми ресурсами. Ресурсом кластера может быть, в принципе, что угодно: IP-адреса, файловые системы, DRBD-устройства, программы-службы и так далее. Довольно просто создать свой ресурс, что мне и пришлось сделать для управления iSCSI таргетами и LUN-ами, об этом далее. Установим:# apt-get install pacemaker Corosync Pacemaker использует инфраструктуру Corosync для взаимодействия между узлами кластера, поэтому для начала нужно будет настроить её. Corosync имеет достаточно широкий функционал и несколько режимов для поддержки связи между нодами (unicast, multicast, broadcast), имеет поддержку RRP (Redundant Ring Protocol), которая позволяет использовать несколько разных путей для общения между нодами кластера для минимизации риска получить Split-brain, то есть ситуации, когда связь между нодами полностью пропадает, и они обе считают что сосед умер. В результате обе ноды переходят в рабочий режим и начинается хаос :) Поэтому мы будем использовать как репликационный, так и внешний интерфейсы для обеспечения связности кластера. Читать дальше →
