Виртуальная машина

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

Сегодня вместе с @kvolodin мы расскажем, почему бесконечное увеличение ресурсов ВМ может вредить пользователям и как спланировать рост производительности очевидными, но действенными способами. Статья полезна тем, кто переехал или планирует переезд в облако и еще знакомится с нюансами облачной среды.

Очевидные причины: ограничения железа и бэкапов

Сейчас в нашем облаке добавление ресурсов сверх лимита можно ограничить на уровне софта. Если кто-то попробует выйти за пределы, сразу получит сообщение в интерфейсе Cloud Director:

Но так было не всегда. В старых версиях vCloud Director мы не могли жестко ограничить некоторые параметры и прописывали лимиты только в договоре. К сожалению, иногда информация из контракта даже не попадала к инженерам клиента, и они могли почувствовать последствия на своей шкуре.

Много лет назад мы предоставили клиенту квоту в 20 ТБ и предупредили про ограничение на диск в 16 ТБ. Резервное копирование данных делали с помощью Veeam Backup&Replication. Когда клиент вышел за пределы диска в 16 ТБ, все задачи на создание бэкапов просто зависли. Veeam не успевал забэкапить большую ВМ и на всякий случай оставлял неполный снэпшот, а затем создавал новый. Дерево снэпшотов стало расти слишком быстро, общая производительность диска тоже упала. Пришлось полночи заново создавать дерево снэпшотов, а затем переносить данные на диски поменьше.

В те времена от подобных инцидентов нас защищал мониторинг. Мы сразу видели непорядок на дашбордах и обращали внимание клиента на проблему. Трудность была в том, что в случае IaaS сами виртуалки оставались ответственностью клиента. Инженеру клиента нужно было самому пересоздавать ВМ, иногда с большим трудом.

Клиенту выделили квоту в 40 ТБ на СХД, а для диска ВМ прописали ограничение в 20 ТБ. Администратор клиента создал ВМ в 30 ТБ и разметил все дисковое пространство одним диском. Техподдержка обнаружила проблему, сообщила клиенту, что нужно пересоздать ВМ с дисками меньшего размера, но администраторы долго не выходили на связь.

В это время данные начали записываться на созданный диск большими темпами. Пока на СХД было свободное место, мы увеличивали размер дата-стора и ждали ответа от клиента. Но если бы расширять дата-стор дальше было невозможно, клиенту пришлось бы рисковать данными. Нужно было бы создать новый диск и перегнать данные на него. Миграция такой большой ВМ могла потребовать несколько дней, и оставалась вероятность неудачного переезда.

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

Но даже если физический лимит не превышен, могут возникнуть другие трудности.

Неочевидная работа гипервизора

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

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

Клиенту облака по умолчанию доступна только информация из диспетчера задач и монитора ресурсов. Бывает и так, что на ОС клиент видит загрузкучасти ядер на 100%. В это же время мы на гипервизоре видим, что часть ядер не используется, потому что приложение не рассчитано на многопоточность. В таких ситуациях парадоксальным образом помогает именно уменьшение ресурсов до необходимого и достаточного уровня. После этого гипервизор лучше распределяет небольшие ВМ в очередях.

Некорректный сайзинг приложения в облаке

К сожалению, переезд приложения с физических хостов не всегда возможен в лоб. Даже если все работало на физических 24 процессорах, столько же процессоров в облаке не всегда решают проблему.

Один из клиентов перед переездом на новое железо решил временно разместить в облаке виртуальную АТС. Мы заглянули в документацию вендора и обнаружили явную несовместимость с vCloud Director. Производители АТС изначально не гарантировали стабильную работу своего приложения в облачной среде. Тем не менее, нашим инженерам удалось настроить работу софта с помощью нескольких хитростей. Клиент спокойно работал в облаке, пока не дождался поставки собственного железа. Но если быон захотел внести изменения в настройки, возникли бы трудности.

У крупных производителей софта несовместимость с облаком сразу прописана в документах. Менее очевидно дело обстоит с самописным ПО.

Клиент заказал виртуальную машину для переезда собственного приложения в облако. Через пару месяцев работы софт начал сильно тормозить. При аудите выяснилось, что объемные файлы по умолчанию сохраняются в одну директорию и нагружают файловую систему. За несколько месяцев там накопились уже миллионы файлов, и для решения проблемы понадобилась новая архитектура с несколькими хранилищами.

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

Например, бывают ситуации, когда пользователь привык к быстрой работе на ноутбуке с высокочастотными процессорами, а в облаке сталкивается с низкой скоростью. Характеристики Enterprise-железа в дата-центре рассчитаны на долгосрочную работу в режиме 24/7 и не допускают пограничных состояний. Если такой пользователь разгонял процессоры на своем ноутбуке до опасного максимума, то в облаке он не сможет добиться тех же скоростей от похожего процессора.

Случается и так, что приложение рассчитано на высоконагруженную базу, но размещается в облаке на SATA-дисках. Клиент видит загрузку процессоров и увеличивает ресурс CPU, не подозревая проблемы именно с дисками.

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

Один из клиентов хранил в своей базе данные трекинговой системы за три года такой срок хранения был предусмотрен нормативом. После переезда в облако удалось разделить хранилище на холодное и горячее. Редко используемые данные перемещались на медленные и дешевые холодные диски, а востребованная информация оставалась на быстрых дисках в горячем хранилище.

Подозрительная активность на ВМ

Когда снижение производительности подкрадывается постепенно, то переход на более производительные диски может и правда решить проблему. Если же загрузка ресурсов выросла резко, скорее всего, дело в шифровальщике или залетном майнере криптовалюты.

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

Откуда берутся лимиты на ресурсы в облаке

Ограничения на диск

1. Есть технические ограничения СХД. Яркий пример: блочный том многих моделей NetApp не может быть более 16 ТБ.

2. Мы как провайдер провели тесты производительности СХД и рассчитали оптимальный размер дата-стора.

3. Инфраструктура резервного копирования лучше справляется с бэкапом нескольких мелких объектов, чем одного большого.

Ограничения на CPU и память

1. Ограничен размер физического хоста, на котором располагаются ВМ клиентов.

   При размере хоста 144 vCPU и 2 TБ памяти ВМ большего размера не получится создать при всем желании. (Cпасибо, кэп!)

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

   У клиента может быть сервис, который сам эффективно распределяет ресурсы памяти, тогда проблем не возникнет. В остальных же случаях нужно настраивать лимиты.

3. С помощью некоторых лимитов мы можем управлять виртуальной платформой и предоставлять предсказуемый сервис с соблюдением SLA.

Ограничения на IOPS

В облаке также встречаются клиенты, у которых намного выше среднего параметры IOPS: количество операций ввода/вывода. Чаще всего это происходит в трех случаях:

1. Клиент решил протестировать выделенные мощности на больших нагрузках.

2. У клиента наблюдается аномальная нагрузка, например, из-за некорректной работы самописного софта или вирусов.

3. Клиент установил высокопроизводительное приложение.

На любой из этих случаев мы задаем ограничения потребляемых дисковых мощностей, опираясь на результаты нагрузочного тестирования СХД. Сейчас можем ограничить каждый диск фиксированным значением IOPS или исходить из IOPS на ГБ.

Как новому клиенту вписаться в лимиты и обеспечить производительность

1. При планировании переезда в облако ознакомиться с документацией на ПО. Некоторые производители софта сразу указывают, что их приложение не работает в облачной среде.

2. До переезда протестировать работу приложения в облачной инфраструктуре. Большинство провайдеров позволяют клиентам брать пробный период и запускать синтетические тесты.

3. Не стесняться обращаться в техподдержку. Инженеры могут оценить производительность со стороны гипервизора и дать рекомендации.

4. Расти маленькими шагами: увеличить диски намного проще, чем резко их уменьшить. Увеличивать процессоры тоже лучше постепенно, начинать с одного ядра.

5. Расти не вертикально, а горизонтально. Например, не добавлять 8 процессоров на одну ВМ, а создать 4 ВМ по 2 процессора на каждой. Вдобавок это уменьшит площадь отказа.

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

Начало

Понадобилось нам недавно в конторке перенести данные со старого сервачка на новый, казалось бы невелика задача: спланировал, купил железо, установил новый дистрибутив, перенёс данные и вуаля. НО! Не тут-то было.

Железо купили новенькое, хоть и не мощное, однако имеющийся дистрибутив Calculate в самой своей последней инкарнации CDS на момент сего действа оказался не слишком-то способен распознать новое железо, а именно сетевые интерфейсы. Локальный видит, а вот ethN - нет, постучались в "Телегу" техподдержки, - результат маловнятный. Ну да ладно, решили проверить на других дистрибутивах, из имеющихся был свежий CentOS и gentoo, первый - не смог, второй железо увидел, из чего сделали вывод, что проблема в ядре, в техподдержке намекнули, что ждите дистрибутива или...

...и мы выбрали "или"

Собственно всё нижеследующее - фактически просто протокол работы, то есть то, что мы сделали для того, чтобы создать средствами Calculate Scratch Server (далее CSS) дистрибутив под собственные нужды. Забегая вперёд, скажу, что всё оказалось не так уж и сложно, хоть и не с первого раза, и именно для того, чтобы у нас в последующем и у вас, читатель буде такая нужда возникнет, получилось с первого.

Сходили за образом на https://mirror.lautre.ru/nightly/20201105/ забрали css-20201105-x86_64.iso в вашем случае возможно будет иначе, не суть важно.

Подцепили образ к виртуалке на старом сервере:

qemu-system-x86_64 \-smp 4 \-vnc 192.168.1.240:7 \-m 8192 \-enable-kvm \-boot order=cd,menu=on,reboot-timeout=20 \-hda /mnt/8tb/CSS/CSS-gradient.raw \-cdrom /mnt/8tb/CSS/css-20201105-x86_64.iso

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

qemu-img create -f raw CSS-gradient.raw 40G

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

После загрузки системы в витруалку выполнили подготовку образа системы для модификации под свои нужды:

cl-builder-prepare -d /dev/sda1 --id CSS-Gradient

Система нас оповестила, что подготовка завершена:

Затем выполнили:

cl-builder-update

Внимательно убедившись, что все настройки нас удовлетворяют, конкретно в нашем случае оказались достаточно дефолтных.

Подтвердили введя "Yes" и система обновила образ до последнего, в нашем случае - по минимуму, если образ CSS с которого выполнена загрузка был бы старый, cl-builder подтянул бы необходимое.

После чего:

chroot /run/calculate/mount/CSS-Gradient/ /bin/bash

...и для удобства:

export PS1="(new) ${PS1}"

Просматриваем наличие ядер в системе:

cl-kernel --kver list

* 5.4.57-calculate *

В системе установлено только старое ядро, поэтому будем собирать из исходников, для чего выберем одно из доступных, которое найдём при помощи

eix calculate-sources

В наличии из ветки 5.4 только 5.4.74 как наиболее свежее, поэтому маскируем более ранние, для чего создаём каталог /etc/portage/package.mask и записываем туда файл масок.

mkdir /etc/portage/package.mask

echo "> /etc/portage/package.mask/custom

После чего проверяем маскировку пакетов ядра повторно:

eix calculate-sources

Собственно вот скриншот виртуалки:

Обновляем систему:

cl-update

...и проверяем доступные ядра:

cl-kernel --kver list

* 5.4.72-gentoo

* 5.4.57-calculate *

Но нам нужно ядро calculate, поэтому проверяем доступное ядро:

emerge -s sys-kernel/calculate-sources

По умолчанию предлагается последнее 5.9.3,

которое мы не проверяли на работоспособность, а gentoo-шное 5.4.72 работает без проблем, поэтому в /etc/portage/package.mask/custom добавляем >sys-kernel/calculate-sources-5.4.74, чтобы ограничить выбор одной версией:

nano /etc/portage/package.mask/custom

получилось, что в файле /etc/portage/package.mask/custom содержится вот это:
>sys-kernel/calculate-sources-5.4.74
<sys-kernel/calculate-sources-5.4.74

Нужная версия стала доступной, далее выполняем повторно

cl-update

Осталось сгенерировать образ и записать его на флешку. Для этого выходим из окружения создаваемого образа (Ctrl+D) и уже из основной системы выполняем:

cl-builder-image --compress xz --isohybrid ON

Который создаёт образ с именем по умолчанию, который кладёт в каталог по умолчанию, что нам не принципиально.

Поскольку всё действо творится в виртуалке, а ISO-шник с которого мы сию виртуальную машину запустили автоматом не обновляется, да и флешку мы забыли подмонтировать к виртуальной машине, постольку копируем образ на виртуальный диск в какой-нибудь из каталогов, да например /root/, который после перезагрузки останется неизменным. Для этого просто копируем его из оперативки на образ диска, который создал cl-builder-prepare. Ну лентяй я:

cp /var/calculate/linux/css-20201111-x86_64.iso /run/calculate/mount/CSS-Gradient/root/

А потом перезагрузив виртуалку с подцепленной флешкой

qemu-system-x86_64 \-smp 4 \-vnc 192.168.1.240:7 \-m 8192 \-enable-kvm \-boot order=cd,menu=on,reboot-timeout=20 \-hda /mnt/8tb/CSS/CSS-gradient.raw \-hdb /dev/sdd \-cdrom /mnt/8tb/CSS/css-20201105-x86_64.iso

пишем при помощи dd образ на неё (помните флешку /dev/sdd, которая после загрузки виртуалки стала в ней /dev/sdb) из подмонтированного образа сборки, в который ранее мы записали ISO-шник:

mount /dev/sda1 /mnt

cd /mnt/root

dd if=css-20201111-x86_64.iso of=/dev/sdb bs=8MB;sync

Гасим виртуалку (halt -p), вставляем флешку в рабочую машину, которая не хотела работать со штатным диструбутивом CSS и наслаждаемся доступом в сеть.

Финиш

Собственно, как вы могли заметить, ничего особо сложного в данной процедуре не оказалось, CSS внезапно оказался вполне дружелюбен к пользователю и не так страшен, как многие подозревают. На очереди формирование полноценного дистрибутива под собственные нужды, с почтой, DNS и прочими облаками и сервисами, но это уже другая история... ;-)

Использованные источники

https://old.calculate-linux.org/main/ru/calculate-builder

https://wiki.calculate-linux.org/ru/kernel

https://wiki.gentoo.org/wiki/Handbook:X86/Full/Portage/ru

https://wiki.gentoo.org/wiki/Handbook:X86/Full/Installation/ru#Chrooting

В первой части Разработка стековой виртуальной машины и компилятора под неё (часть I) сделал свою элементарную стековую виртуальную машину, которая умеет работать со стеком, делать арифметику с целыми числами со знаком, условные переходы и вызовы функций с возвратом. Но так как целью было создать не только виртуальную машину, но и компилятор C подобного языка, пришло время сделать первые шаги в сторону компиляции. Опыта никакого. Буду действовать по разумению.

Одним из первых этапов компиляции является синтаксический анализ (parsing) исходного кода нашего "C подобного языка" (кстати, надо какое-то название дать как только он станет более формальным). Задача простая - "нарубить" массив символов (исходный код) на список классифицированных токенов, чтобы последующий разбор и компиляция не вызывали сложности.

Итак, первый шаг - определиться с типами токенов (интуитивно будем ориентироваться на синтаксис C), символами которые будут отделять токены друг от друга, а также определить структуру для хранения токена (тип, текст токена, длина, строка и столбец в исходном коде).

constexpr char* BLANKS = "\x20\n\t";constexpr char* DELIMETERS = ",;{}[]()=><+-*/&|~^!.";enum class TokenType {NONE = 0, UNKNOWN, IDENTIFIER,CONST_CHAR, CONST_INTEGER, CONST_REAL, CONST_STRING,COMMA, MEMBER_ACCESS, EOS, OP_BRACES, CL_BRACES, OP_BRACKETS, CL_BRACKETS, OP_PARENTHESES, CL_PARENTHESES,BYTE, SHORT, INT, LONG, CHAR, FLOAT, DOUBLE, STRING, IF, ELSE, WHILE, RETURN,ASSIGN, EQUAL, NOT_EQUAL, GREATER, GR_EQUAL, LESS, LS_EQUAL,PLUS, MINUS, MULTIPLY, DIVIDE, AND, OR, XOR, NOT, SHL, SHR,LOGIC_AND, LOGIC_OR, LOGIC_NOT};typedef struct {TokenType type;          char* text;              WORD length;             WORD row;                WORD col;                } Token;

Далее напишем класс для разбора, ключевым методом которого станет parseToTokens(char*). Тут алгоритм простой: идем до разделителя (BLANKS и DELIMETERS), определяем начало и конец токена, классифицируем его и добавляем в вектор (список) токенов. Особые случаи разбора - это отличать целые числа от вещественных, вещественные числа (например, "315.0") отличать от применения оператора доступа к членам структуры/объекта ("obj10.field1"), а также отличать ключевые слова от других идентификаторов.

void VMParser::parseToTokens(const char* sourceCode) {TokenType isNumber = TokenType::UNKNOWN;bool insideString = false;                                         // inside string flagbool isReal = false;                                               // is real number flagsize_t length;                                                     // token length variablechar nextChar;                                                     // next char variablebool blank, delimeter;                                             // blank & delimeter char flagstokens->clear();                                                   // clear tokens vectorrowCounter = 1;                                                    // reset current row counterrowPointer = (char*)sourceCode;                                    // set current row pointer to beginningchar* cursor = (char*)sourceCode;                                  // set cursor to source beginning char* start = cursor;                                              // start new token from cursorchar value = *cursor;                                              // read first char from cursorwhile (value != NULL) {                                            // while not end of stringblank = isBlank(value);                                          // is blank char found?delimeter = isDelimeter(value);                                  // is delimeter found?length = cursor - start;                                         // measure token length    // Diffirentiate real numbers from member access operator '.'isNumber = identifyNumber(start, length - 1);                    // Try to get integer part of real numberisReal = (value=='.' && isNumber==TokenType::CONST_INTEGER);     // Is current token is real numberif ((blank || delimeter) && !insideString && !isReal) {          // if there is token separator                   if (length > 0) pushToken(start, length);                      // if length > 0 push token to vectorif (value == '\n') {                                           // if '\n' found rowCounter++;                                                // increment row counterrowPointer = cursor + 1;                                     // set row beginning pointer}nextChar = *(cursor + 1);                                      // get next char after cursorif (!blank && isDelimeter(nextChar)) {                         // if next char is also delimeterif (pushToken(cursor, 2) == TokenType::UNKNOWN)              // try to push double char delimeter tokenpushToken(cursor, 1);                                      // if not pushed - its single char delimeterelse cursor++;                                               // if double delimeter, increment cursor} else pushToken(cursor, 1);                                   // else push single char delimeterstart = cursor + 1;                                            // calculate next token start pointer}else if (value == '"') insideString = !insideString;             // if '"' char - flip insideString flag else if (insideString && value == '\n') {                        // if '\n' found inside string// TODO warn about parsing error}cursor++;                                                        // increment cursor pointervalue = *cursor;                                                 // read next char}length = cursor - start;                                           // if there is a last tokenif (length > 0) pushToken(start, length);                          // push last token to vector}

Наряду с методом parseToTokens, помогать в разборе и классификации нам будут простые методы, определяющие разделители и тип найденного токена. Плюс метод добавления токена в вектор.

class VMParser {public:VMParser();~VMParser();void parseToTokens(const char* sourceCode);Token getToken(size_t index);size_t getTokenCount();  private:vector<Token>* tokens;WORD rowCounter;char* rowPointer;  bool isBlank(char value);bool isDelimeter(char value);TokenType pushToken(char* text, size_t length);TokenType getTokenType(char* text, size_t length);TokenType identifyNumber(char* text, size_t length);TokenType identifyKeyword(char* text, size_t length);};

Попробуем используя класс VMParser разобрать строку исходного кода C подобного языка (исходный код бессмысленный, просто набор случайных токенов для проверки разбора):

int main(){    printf ("Wow!");    float a = 365.0 * 10 - 10.0 / 2 + 3;while (1 != 2) {    abc.v1 = 'x';}if (a >= b) return a && b; else a || b; };

В итоге получаем в консоли следующий перечень классифицированных токенов:

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

Для простоты сначала реализуем компилятор арифметических выражений с целыми числами (приоритет "*" и "/" над "+" и "-" учитывается), без скобок, унарных операций и других важных вещей, в том числе проверки синтаксических ошибок. Разбор выражений напишем вот так:

void VMCompiler::parseExpression(size_t startIndex, VMImage* destImage) {Token tkn;currentToken = startIndex;parseTerm(destImage);tkn = parser->getToken(currentToken);while (tkn.type==TokenType::PLUS || tkn.type==TokenType::MINUS) {  currentToken++;  parseTerm(destImage);  if (tkn.type==TokenType::PLUS) destImage->emit(OP_ADD); else destImage->emit(OP_SUB);  tkn = parser->getToken(currentToken);}}void VMCompiler::parseTerm(VMImage* destImage) {Token tkn;parseFactor(destImage);currentToken++;tkn = parser->getToken(currentToken);while (tkn.type == TokenType::MULTIPLY || tkn.type == TokenType::DIVIDE) {  currentToken++;  parseFactor(destImage);  if (tkn.type == TokenType::MULTIPLY) destImage->emit(OP_MUL); else destImage->emit(OP_DIV);  currentToken++;  tkn = parser->getToken(currentToken);}}void VMCompiler::parseFactor(VMImage* destImage) {Token tkn = parser->getToken(currentToken);char buffer[32];strncpy(buffer, tkn.text, tkn.length);buffer[tkn.length] = 0;destImage->emit(OP_CONST, atoi(buffer));}

Попробуем скормить этому компилятору выражение "3+5*6+2*3+15/5", запускаем компилятор с выводом скомпилированных команд и сразу запускаем виртуальную машину. Ожидаем, что результат вычисления должен остаться на вершине стека - 42.

Ура! Получилось! Первые шаги в сторону компилятора сделаны.

Многие администраторы VMware ESXi сталкивались с такой проблемой, как фиолетовый экран смерти. Самое неприятное в этой проблеме, что у вас возникает недоверие к своей собственной инфраструктуре. В голове постоянно крутятся мысли о том, что такая же проблема может повториться и на другом сервере.

Что такое PSOD?

PSOD расшифровывается, как Purple Screen of Diagnostics, часто называемый Purple Screen of Death от более известного Blue Screen of Death, встречающегося в Microsoft Windows.

Это диагностический экран, отображаемый VMware ESXi, когда ядро обнаруживает фатальную ошибку, при которой оно либо не может безопасно восстановиться, либо не может продолжать работу.

Он показывает состояние памяти во время сбоя, а также дополнительные сведения, которые важны для устранения причины сбоя: версия и сборка ESXi, тип исключения, дамп регистра, обратную трассировку, время безотказной работы сервера, сообщения об ошибках и информацию о дампе ядра. (файл, созданный после ошибки, содержащий дополнительную диагностическую информацию).

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

Почему появляется PSOD?

PSOD- этосбой в ядре. Все мы знаем, что ESXi не основан на UNIX, но механика сбоя соответствует определению UNIX. Ядро ESXi (vmkernel) запускает эту меру безопасности в ответ на события или ошибки, которые невозможно исправить, это будет означать, что продолжение работы может создать высокий риск для служб и виртуальных машин. Проще говоря: когда хосты ESXi чувствуют, что они повреждены, они совершают харакири и, истекая пурпурной кровью, пишут предсмертную записку с подробным описанием причин, по которым они это сделали!

Наиболее частые причины PSOD:

1. Аппаратные сбои, в основном связанные с RAM или CPU. Обычно они выдают ошибку MCE или NMI.

MCE исключение проверки компьютера, которое представляет собой механизм в ЦП для обнаружения и сообщения о проблемах с оборудованием. В кодах, отображаемых на фиолетовом экране, есть важные детали для определения основной причины проблемы.

NMI немаскируемое прерывание, то есть аппаратное прерывание, которое не может игнорироваться процессором. Поскольку NMI является очень важным сообщением об отказе HW, ответ по умолчанию, начиная с ESXi 5.0 и более поздних версий, должен запускать PSOD. Более ранние версии просто регистрировали ошибку и продолжали. Как и в случае с MCE, фиолетовый экран, вызванный NMI, предоставляетважные коды, которые имеют решающее значение для устранения неполадок.

2. Программные ошибки

неверное взаимодействие между компонентами ESXi SW (см.KB2105711)

условия гонки (см.KB2136430)

из ресурсов: память, динамическая область памяти, буфер (см.KB2034111,KB2150280)

бесконечный цикл + переполнение стека (см.KB2105522)

неверные или неподдерживаемые параметры конфигурации (см.KB2012125,KB2127997)

3. Некорректно функционирующие драйвера;ошибки в драйверах, которые пытаются получить доступ к некорректному индексу или несуществующему методу (см.KB2146526,KB2148123)

Какое влияние оказывает PSOD?

Когда возникает сбой, хост выходит из строя изавершает работу всех служб, работающих на нем, вместе со всеми размещенными виртуальными машинами. Виртуальные машины отключаются резко ине завершаютсвою работу корректно. Если хост является частью кластера и вы настроили HA, эти виртуальные машины будут запущены на других хостах в кластере. Помимо простоя и недоступности виртуальных машин во время их простоя, грязное завершение может повлиять на некоторые критически важные приложения, такие как серверы баз данных, очереди сообщений или задания резервного копирования.

Кроме того, все другие службы, предоставляемые хостом, будут прекращены, поэтому, если ваш хост является частью кластера VSAN, PSOD также повлияет на vSAN.

Что делать?

1. Проанализируйте сообщение на фиолетовом экране.

Одна из самых важных вещей, которые нужно сделать при появлении фиолетового экрана - это сделать снимок экрана. Если вы подключаетесь к консоли удаленно (IMM, iLO, iDRAC, ), будет легко сделать снимок экрана, если нет такой возможности, хотя сфотографируйте экран на телефон. На этом экране много полезной информации о причине сбоя.

2. Обратитесь в службу поддержки VMware.

Прежде чем приступить к дальнейшему исследованию и устранению неполадок, рекомендуется обратиться в службу поддержки VMware, если у вас есть контракт на поддержку. Параллельно с вашим расследованием они смогут помочь вам в проведении корневого анализа причин (RCA).

3. Перезагрузите затронутый хост ESXi.

Чтобы восстановить сервер, вам необходимо перезагрузить его. Я бы также посоветовал оставить его в режиме обслуживания, пока вы не выполните полный анализ RCA, пока не будет определена и исправлена ошибка. Если вы не можете позволить себе держать его в режиме обслуживания, по крайней мере, точно настройте свои правила DRS, чтобы на нем работали только второстепенные виртуальные машины, чтобы в случае возникновения другого PSOD влияние было минимальным.

4. Получите coredump

После загрузки сервера вы должны собрать дамп ядра -coredump. Coredump, также называемый vmkernel-zdump, представляет собой файл, содержащий журналы с более подробной информацией, чем та, что отображается на фиолетовом экране диагностики, и будет использоваться при дальнейшем устранении неполадок. Даже если причина сбоя может показаться очевидной из сообщения PSOD, которое вы проанализировали на шаге 1, рекомендуется подтвердить ее, просмотрев журналы из coredump.

В зависимости от вашей конфигурации у вас может быть дамп ядра в одной из следующих форм:

а. Во временномразделе

b. В виде файла.dumpв одном из хранилищ данных хоста

c. В виде файла.dumpна vCenter через службу netdump

Coredump становится особенно важным, если конфигурация хоста должна автоматически сбрасываться после PSOD , и в этом случае вы не увидите сообщение на экране. Вы можете скопировать файл дампа с хоста ESXi с помощью SCP, а затем открыть его с помощью текстового редактора (например, Notepad ++). Он будет вмещать содержимое памяти на момент сбоя, и первые его части будут содержать сообщения, которые вы видели на фиолетовом экране. Служба поддержки VMware может запросить весь файл, но у вас лишь будет возможность извлечь только журнал vmkernel, который более нагляден:

5. Расшифруйте ошибку.

Устранение неполадок и анализ причин позволяют почувствовать себя Шерлоком Холмсом. Самый важный симптом, с которого вам следует начать, - это сообщение об ошибке, создаваемое фиолетовым экраном.К счастью, количество выдаваемых сообщений об ошибках ограничено:

Exception Type 0 #DE: Divide Error
Exception Type 1 #DB: Debug Exception
Exception Type 2 NMI: Non-Maskable Interrupt
Exception Type 3 #BP: Breakpoint Exception
Exception Type 4 #OF: Overflow (INTO instruction)
Exception Type 5 #BR: Bounds check (BOUND instruction)
Exception Type 6 #UD: Invalid Opcode
Exception Type 7 #NM: Coprocessor not available
Exception Type 8 #DF: Double Fault
Exception Type 10 #TS: Invalid TSS
Exception Type 11 #NP: Segment Not Present
Exception Type 12 #SS: Stack Segment Fault
Exception Type 13 #GP: General Protection Fault
Exception Type 14 #PF: Page Fault
Exception Type 16 #MF: Coprocessor error
Exception Type 17 #AC: Alignment Check
Exception Type 18 #MC: Machine Check Exception
Exception Type 19 #XF: SIMD Floating-Point Exception
Exception Type 20-31: Reserved
Exception Type 32-255: User-defined (clock scheduler)

Поскольку сбой в ядре обрабатывается процессором, для получения дополнительной информации об этих исключениях см. Руководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 1: Базовая архитектура иРуководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 3A.

Наиболее распространенные случаи описаны в отдельных статьях базы знаний VMware. Поэтому используйте эту таблицу в качестве индекса для ошибок PSOD:

6. Проверьте журналы

Может случиться так, что причина не очень очевидна при просмотре фиолетового сообщения на экране или журнала дампа ядра, поэтому следующее место, где искать подсказки, - это журналы хоста, особенно во временном интервале, непосредственно предшествующем PSOD.Даже если вы чувствуете, что нашли причину, все же рекомендуется подтвердить ее, просмотрев журналы.

Если вы администрируете корпоративную среду, вероятно, у вас под рукой есть специализированное решение для управленияжурналами(например,VMware Log Insight или SolarWinds LEM), поэтому их будет легко просматривать, но если у вас нет управления журналами, вы можете легкоэкспортировать их.

Наиболее интересные файлы журналов для изучения: