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 при «ребилде» нет. Но про это я напишу следующий пост.

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

    1. romx Автор записи

      Платформа в HCL? — Да. Контроллер в HCL? — Да. Откуда человеку знать, что вот может быть так? HCL же.

        1. romx Автор записи

          Думаете, многое поменялось с тех пор в отношении обработки node fault?

          1. romx Автор записи

            Спасибо, да. Но проблема же даже не в том, чтобы выкинуть «не кошерные» контроллеры, проблема в том, что такая простая операция, как замена ноды после отказа, и накопившегося объема изменений в кластере, вызывает такой объем трафика ребилда, что требует его ограничивать с одной стороны, с другой — не ограничивать, потому что до завершения ребилда система находится в незащищенном состоянии. Это все мне напоминает какой-то дремучий RAID-5 с соответствующими проблемами.

  1. yaus

    Конец истории то
    Since the outage, we have had no issues. Since receiving the official statement about the fact that our H310 controllers are not sufficient for our environment, I’ve also been working with VMware on a path to upgrade our controllers to H710P’s (which are on the HCL and have much better performance). Their guys have been great, and have really come through to try to find the cause of this issue. I’m very happy with how things have turned out, and will continue to expand our VSAN deployment (carefully ;) over the coming weeks and months.
    Thanks again to everyone who posted and messaged me with advice and guidance. I’ve learned a lot about storage over the past week and have been very impressed with the community here and the team at VMware.
    TL;DR: Our VSAN outage was caused by our Dell H310 HBA’s, which didn’t provide sufficient performance in our failover scenario due to increased IO load from rebuilds on top of an already reduced cluster. VSAN did what it was supposed to, but our hardware just couldn’t keep up.

  2. Gostan

    VMware предлагает для VSAN так называемые VSAN Ready Nodes. В документе перечислены платформы разных производителей вплоть до парт номеров всех компонентов. Это рекомендованный путь. Если кто-либо решит использовать другие компоненты, и главное это касается контроллера дисков, то стоит изучить дополнительные рекомендации. Сommand queue depth — это первое, что упоминается во многих источниках. Этот параметр указан в списке HCL непосредственно в списке. Нормальный параметр это 1000. А размер в 25 смехотворен. Приведенный кейс лишний раз иллюстрирует важность не только чтения, но и понимания документации ;-)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *