Архив метки: rebuild

VSAN и его работа при node fault может вас неприятно удивить.

Прекрасная во всех отношениях история нашлась на reddit.
С чего все началось: «My VSAN Nightmare»
И чем все закончилось: «Root cause analysis»

В двух словах:
Человек сделал из нескольких своих серверов Dell ноды VSAN, и все было прекрасно, пока однажды одна из нод не упала (PSOD из-за ошибки в DIMM памяти на сервере). Когда ее заменили несколькими днями спустя, и вернули ноду в строй, добавив заодно в нее дисков, через час после ее включения обратно, легла на этот раз ВСЯ система, прямо во время работы.
Какое-то время было потрачено на разбирательство, была подключена поддержка вендора, и все закончилось ответом из техподдержки VMware, привожу его в сокращении и с переводом.

«The RAID controllers that were being used in your environment are the H310s. While this controller is fully functional, it offers very low IO throughput. In particular, its very low queue depth (25) means that it can’t support moderate-to-high IO rates.
While this controller was certified and is in our Hardware Compatibility List, its use means that your VSAN cluster was unable to cope with both a rebuild activity and running production workloads. While VSAN will throttle back rebuild activity if needed, it will insist on minimum progress, as the user is exposed to the possibility of another error while unprotected. This minimum rebuild rate saturated the majority of resources in your IO controller. Once the IO controller was saturated, VSAN first throttled the rebuild, and — when that was not successful — began to throttle production workloads. »

Вы используете в вашей системе RAID контроллер H310s. Хотя это контроллер полностью работоспособен, его производительность на вводе-выводе очень низкая. Кроме этого, у него очень маленькая длина очереди ввода-вывода (25), означающая, что он не может обрабатывать нагрузки уровня от средних до высоких.
Хотя этот контроллер был сертифицирован и находится в нашем Hardware Compatibility List, при его использовании ваш кластер VSAN не смог одновременно обработать трафик ребилда и вашу рабочую нагрузку системы. Хотя VSAN, когда это возможно, и стремится ограничить объем операций по ребилду, для этой задачи требуется хотя бы минимальный прогресс, так как пользователь может столкнуться с новым отказом в то время, пока он остается незащищен (ребилд незакончен). Этот минимум нагрузки ребилда съел большую часть ресурсов ввода-вывода вашего контроллера. Когда контроллер оказался загружен, VSAN сначала ограничила трафик ребилда, а затем, когда это не достигло результата, начала ограничивать рабочий трафик системы.

Какой полезный урок мы можем извлечь из этой истории? Ну, во-первых, стоит отметить, что не всегда присутствие в HCL означает работоспособность. Мне постоянно приходится отвечать на вопрос: «Если вы софтверная компания, то почему вы продаете продукт вместе с платформой, не проще дать HCL и пусть пользователь соберет», вот, не проще, ничуть.
Во-вторых, конечно, история с тем, что трафик ребилда в VSAN настолько большой, что, при использовании некоторых, включенных в HCL контроллеров, нормально работающих в штатной ситуации, может убить «кластер» (не только эту ноду, но вообще весь кластер, Карл!) это, вообще, отлично.
В третьих, это повод получше изучить схему работы VSAN при отказе ноды и ее ребилде, при котором у VSAN создается ТАКОЙ трафик. Пользуясь случаем, скажу, что ничего подобного у Nutanix при «ребилде» нет. Но про это я напишу следующий пост.