У меня есть требование предоставить высокодоступную базу данных MySQL с шифрованием в состоянии покоя на ядре Linux 2.6.32. Часть «высокая доступность» не так уж и сложна, но «с шифрованием в состоянии покоя» оказывается проблемой при использовании в сочетании с высокой доступностью.
Ключевая проблема связана с установкой зашифрованного хранилища. Во всех других наших системах с шифрованием в состоянии покоя есть команда, которую должен запустить человек, которому затем предлагается ввести ключ шифрования. Эта модель имеет довольно очевидный недостаток, когда речь идет о кластерной структуре, при которой службы должны запускаться. автоматически.
В настоящее время я не понимаю, как обеспечить шифрование в состоянии покоя в среде высокой доступности, а также не хранить ключевые парольные фразы в той же системе.
Я вижу два возможных сценария, каждый из которых будет работать с моей средой, но я не уверен в деталях, которые заставят их работать. Или даже если это возможно.
Таким образом, работающие узлы получают доступ к тому CLVM, чтобы они могли запускать службы по команде диспетчера кластера. Для перезагрузки узлов по-прежнему потребуется участие человека, а кодовая фраза шифрования никогда не хранится на диске.
Как и в случае с настройкой CLVM, узлы не присоединяются к кластеру, пока не получат видимость предположительно общего хранилища.
Дело в том, что я не уверен, работает ли что-либо из вышеперечисленного таким образом. Оба предполагают, что можно наложить LVM PV поверх зашифрованного тома (например, pvcreate /dev/mapper/cryptmysql). Это может быть невозможно.
Основная проблема, по-видимому, заключается в вмешательстве человека для ввода ключа. В этом есть некоторая помощь: dm-crypt поддерживает TPM, который может быть доступен на вашей платформе. Видеть этот план IBM для подробностей конфигурации. Также LUKS / cryptsetup поддерживает чтение ключа слота из файла / из стандартного ввода. Если вы можете где-нибудь безопасно хранить свой ключ (как на смарт-карте), это может быть жизнеспособным вариантом.
Что касается вашего вопроса, можете ли вы иметь LVM PV на томе dm-crypt: вы можете, вам просто понадобится запуск pvscan / vgchange -a -y после разблокировки слота. Мы запускали такую установку с гораздо более старыми ядрами пару лет назад. В конце концов, мы отказались от него в пользу использования SED для приложений с требованиями к шифрованию данных в состоянии покоя из-за соображений производительности (dm-crypt в то время использовался для использования одного потока на зашифрованное устройство, что привело к узкое место ЦП в нашей настройке).
Оказывается, это полностью выполнимо с LVM, как предлагал syneticon-dj. С тех пор я убедился, что он работает с конфигурациями кластера. Однако сделать это не так просто, как вы думаете.
Прежде чем группы томов cLVM станут видимыми, их необходимо расшифровать с помощью cryptsetup luksOpen на устройстве, нуждающемся в шифровании. Это по необходимости происходит после того, как службы кластера были запущены, поэтому любые ресурсы, основанные на нем, не должны входить в состав чего-либо критически важного, например, каменного устройства.
Настройка кластера такая же, как и всегда, но с некоторыми отличиями:
cryptsetup luksOpen /dev/sdd cryptmysql)vgcreate ClusterMySQLVG /dev/mapper/cryptmysql)Поскольку узел требует ручного вмешательства, чтобы иметь право на отработку отказа, рекомендуется иметь более двух узлов в отказоустойчивом кластере.
После того, как группа томов и логические тома созданы как обычно, установите MySQL. На этом этапе установка выполняется как обычные установки кластеризации.
Когда узел перезагружается:
/dev/mapper, который затем подхватывает LVM.