Здравствуйте!

Третья часть статьи является своеобразным приложением к двум предыдущим, в которых я рассказывал о работе с Proxmox-кластером. В этой части я опишу проблемы, с которыми мы сталкивались в работе с Proxmox, и способы их решения.

Авторизованное подключение к iSCSI

Если вам понадобилось при подключении к iSCSI указать креденшиалы — лучше это делать в обход Proxmox. Почему?

• Во-первых, потому что через web-интерфейс Proxmox невозможно создать авторизованное iSCSI-подключение.
• Во-вторых, даже если вы решите создать в Proxmox неавторизованное подключение с тем, чтобы указать авторизационную информацию вручную, то вам придется бодаться с системой за возможность изменить конфигурационные файлы таргетов, так как при неудачной попытке подключения к iSCSI-хосту Proxmox перезаписывает информацию о таргетах и производит повторную попытку подключения.

Здравствуйте!

Это вторая часть статьи о работе c кластерным хранилищем в Proxmox. Сегодня поговорим о подключении хранилища к кластеру.

В начале хочу привести выдержку из прошлой статьи, чтобы никто не забыл, зачем нам весь огород с кластером:

В нашем случае проблема организации общего хранилища сводится к двум аспектам:

1. У нас есть блочное устройство, отдаваемое по сети, к которому будут иметь доступ несколько хостов одновременно. Для того, чтобы эти хосты не подрались за место на устройстве, нам нужен CLVM — Clustered Logical Volume Manager. Это то же самое, что LVM, только Clustered. Благодаря CLVM каждый хост имеет актуальную информацию (и может ее безопасно изменять, без риска нарушить целостность) о состоянии LVM-томов на Shared Storage. Логические тома в CLVM живут точно так же, как в обычном LVM. В логических томах находятся либо KVM-образы, либо кластерная FS.
2. В случае с OpenVZ у нас есть логический том, на котором расположена файловая система. Одновременная работа нескольких машин с некластерной файловой системой ведет к неминуемым ошибкам в работе всего — это лебедь, рак и щука, только хуже. Файловая система обязательно должна знать о том, что она живет на общем ресурсе, и уметь работать в таком режиме.

В качестве кластерной файловой системы мы используем Global File System 2.

Здравствуйте!

Хочу рассказать о том, как мы используем у себя Proxmox Virtual Environment.

Я не буду описывать установку и первоначальную настройку — Proxmox очень прост и приятен и в установке, и в настройке. Расскажу о том, как мы используем систему в кластерном окружении.

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

Proxmox работает с двумя типами виртуализации: уровня операционной системы, на основе OpenVZ и аппаратной, на основе KVM. В этих двух типах используется разный подход к утилизации дискового пространства. Если в случае с OpenVZ-контейнерами работа с диском виртуальной машины осуществляется на уровне файловой системы хоста, то в случае с KVM-машинами используется образ диска, в котором находится собственная файловая система виртуальной машины. Операционная система хоста не заботится о размещении данных внутри KVM-диска. Этим занимается гипервизор. При организации работы кластера вариант с образами диска реализуется проще, чем работа с файловой системой. Данные KVM-машины с точки зрения операционной системы хоста могут просто находиться "где-то" в хранилище. Эта концепция замечательно ложится на схему работы LVM, когда образ KVM-диска находится внутри логического тома.

В случае же с OpenVZ мы имеем дело с файловой системой, а не просто с областями данных на Shared Storage. Нам нужна полноценная кластерная файловая система.

О кластерной файловой системе речь пойдет не в этой части статьи. О работе с KVM — тоже. Сейчас поговорим о подготовке кластера к работе с общим хранилищем.

Здравствуйте.

Хочу поделиться опытом миграции боевой базы данных с MySQL 5.0 на Percona Server 5.5 под нагрузкой почти без отрыва от производства.

Опишу вкратце эволюцию нашей базы до текущего состояния

База у нас древняя, пережила несколько апгрейдов MySQL. Начинали с MySQL 3.x. С ростом нагрузки, уже на MySQL 5.0, настроили репликацию и подключили еще один сервер для чтения. Тогда мы это делали стандартными средствами MySQL, без привлечения xtrabackup — полностью блокировали сервер на время создания мастер-дампа и вывешивали на сайтах заглушки.

Затем встала следующая проблема — на томе с данными стало заканчиваться место. Плюс InnoDB-хранилище исторически располагалось в одном файле. Было рассмотрено много вариантов решения. Начиная от размещения базы на iSCSI-томе и заканчивая перетыканием в рейд более емких дисков, расширением на них volume group / logical volume с последующим расширением файловой системы.

В качестве временного варианта решили подключить iSCSI-том из виртуалки под VMWare vCloud (не реклама, честно!). vCloud стоит у нас под боком.