В конце 2012 года, Cybera (некоммерческая организация с мандатом на наблюдение за развитием киберинфраструктуры в Альберте, Канада) развернула модернизированное облако OpenStack для своего проекта DAIR (http://www.canarie.ca/en/dair-program/about). Через несколько дней работы один вычислительный узел завис. После перезагрузки узла, я проверил какие экземпляры были размещены на этом узле, чтобы я мог загрузить их от имени клиента. К счастью, там был только один экземпляр.

Команда nova reboot не работала, поэтому я воспользовался virsh, но она сразу же вернула с ошибку заявив, что не смогла найти диска поддержки (backing disk). В данном случае, диском поддержки являлся образ Glance, который копируется в /var/lib/nova/instances/_base при первом использовании образа. Почему не возможно его найти? Я проверил каталог и убедился, что он был на месте.

Я рассмотрел базу данных nova и увидел запись для данного экземпляра в таблице nova.instances. Образ, который использовал экземпляр соответствовал тому, о котором сообщал virsh, следовательно никакого не соответствия не существует.

Я проверил Glance и заметил, что этот образ был созданным пользователем моментальным снимком. По крайней мере, это была хорошая новость, что только этот один пользователь был затронут.

Наконец, я проверил StackTach и рассмотрел события пользователя. Это были создания и удаления нескольких моментальных снимков, скорее всего, экспериментальных. Хотя временные метки не совпадали, мой вывод состоял в том, что они запускали свой экземпляр, а затем удаляли снимок, и он был каким-то образом удален из /var/lib/nova/instances/_base.

Оказывается, причина того, что это вычислительный узел зависал, была в проблеме с аппаратурой. Мы удалили ее из облака DAIR и вызвали Dell для обслуживания. Dell приехал и начал работать. Так или иначе (или кривые руки), но другой вычислительный узел был вставлен и загружен. Отлично.

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

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

Примечание об архитектуре DAIR: /var/lib/nova/instances является подключением совместно используемой NFS. Это означает, что все вычислительные узлы имеют к нему доступ, причем он включает в себя каталог _base. Другой централизованной областью является /var/log/rsyslog в контроллере облака. Этот каталог содержит все журналы OpenStack со всех вычислительных узлов. Я задался вопросом, существуют ли какие-либо записи для файла, о котором сообщает virsh:

dair-ua-c03/nova.log:Dec 19 12:10:59 dair-ua-c03
2012-12-19 12:10:59 INFO nova.virt.libvirt.imagecache
[-] Removing base file:
/var/lib/nova/instances/_base/7b4783508212f5d242cbf9ff56fb8d33b4ce6166_10
            

А-ага! Так OpenStack удалил его. Но почему?

В Essex была введена функция для периодической проверки и поиска того, существуют ли какие-либо не используемые файлы _base. Если бы они существовали, Nova бы удалила их. Эта идея звучит вполне невинно и имеет некоторые хорошие свойства. Но как эта функция в конечном итоге включилась? По умолчанию она была выключена в Essex. Как это и должно быть. В Folsom было decided to be turned on in Folsom (принято решение включить ее https://bugs.launchpad.net/nova/+bug/1029674). Я не могу не подчеркнуть, что:

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

В настоящее время дисковое пространство дешево. А восстановление данных нет.

Во-вторых, совместно используемый каталог /var/lib/nova/instances в случае DAIR способствовал проблеме. Так как все вычислительные узлы имеют доступ к этому каталогу, все вычислительные узлы периодически просматривают каталог _base. Если существует только один экземпляр, использующий образ, и единственный узел, на котором находится экземпляр, отключится на несколько минут, он не сможет пометить образ как все еще используемый. Таким образом, образ кажется не используемым и удаляется. Когда вычислительный узел возвращается во включенное состояние, экземпляр, размещенный на этом узле не в может запуститься.