Недавно вышел в свет один из важнейших документов, содержащий в себе концентрацию лучших практик для обеспечения производительной работы VMware vSphere с поправками на последнюю, седьмую, версию.
Данная серия постов, скорее, вырезка интересующих меня моментов из гайда, которыми можно поделиться с коллегами, с моими комментариями и дополнениями, но не в коем случае не попытка перевести полностью и дословно данный документ.
Мой перевод и понимание документа могут содержать неточности и, возможно, ошибки, поэтому в первую очередь настоятельно рекомендую самостоятельно ознакомиться с документом в его оригинальном виде.
Недавно столкнулся с проблемой обновления прошивок на серверах Dell R640, оборудованных iDRAC 9 (4.10.10.10) через сервер управления Dell OpenManage Enterprise.
Начать стоит с того, что ранее я уже успешно обновлял данные сервера через OME, но далее управляющий сервер был развернут на другой площадке и начались проблемы.
Состоялся релиз второго патча для Veeam Backup and Replication V10 с номером 10.0.0.4461 P2.
Патч несет с собой ряд изменений и исправлений, большинство из которых адресованы для Cloud Connect и для пользовательского интерфейса.
Но самое главное, что приносит этот патч – официальную поддержку резервного копирования VMware vSphere 7. Конечно, бэкап работал и ранее, но вот официально не поддерживался и, в случае возникновения каких-либо проблем, в технической поддержке могли отказать. Данный патч дает зеленый свет на обновление площадок виртуализации до vSphere 7 всем тем, кто ждал официального подтверждения полной совместимости с используемой системой резервного копирования.
Патч можно устанавливать поверх всех версий VBR V10 (а их всего две: build 10.0.0.4461 or 10.0.0.4461 P1). После обновления версия VBR будет 10.0.0.4461 P2.
С выходом 7 версии vSphere, в vCenter появился интересный модуль под названием «Update Planner», который должен помочь системным администраторам в обновление этого, достаточно важного, компонента виртуальной инфраструктуры.
Этот модуль должен оказывать помощь администраторам в проверке совместимости компонентов кластера и внешних систем с новой версией vCenter, а также выполнять ряд проверок перед обновлением.
Совсем недавно вышел первый апдейт на vCenter за версией 7.0.0a с билдом 16189094, что выглядит как отличная возможность проверить Update Planner в действии.
В процессе обслуживания кластеров Nutanix, иногда приходится прибегнуть к процедуре остановки виртуальных машин CVM, которые являются неотъемлемой частью кластера и предоставляют дисковые ресурсы виртуальным машинам и не только.
Сразу отмечу, что не стоит останавливать виртуальную машину следующими способами:
Классической Linux командой shutdown из операционной системы CVM;
С гипервизора AHV с помощью virsh (я удивился, когда увидел подобный совет на одном форуме).
Каждый из вышеуказанных типов отключения CVM приводит к «внеплановой», с точки зрения кластера, остановке, что может вызвать временные (скорее всего не сильно заметные) задержки в дисковом трафике у ряда виртуальных машин.
Для корректной остановки CVM Nutanix необходимо использовать специально подготовленный скрипт cvm_shutdown, который находится на каждой CVM в кластере. Аргументы данного скрипта аналогичны аргументам, которые можно передать стандартной команде shutdown.
Если обратиться к исходному коду скрипта, можно определить, что он, в отличии от классического отключения ОС, выполняет ряд операций, способствующих корректному отключению CVM с минимизацией влияния на виртуальные машины.
cvm_shutdown:
Логирует свои действия;
Выполняет проверку состояния кластера на наличие запущенной процедуры обновления;
Переводит дисковый трафик на другую доступную CVM;
Выполняет остановку процессов CVM и отключает\перезагружает ОС, в зависимости от переданных аргументов.
Вот что сказано в документации к скрипту: This script signals HA when shutting down the CVM (Controller VM) to forward the storage traffic to another healthy CVM. Instead of using “sudo shutdown” or “sudo reboot” commands, this script should be used to minimize I/O hit in user VMs running on the present hypervisor host.
Как видно из описания, использование данного скрипта минимизирует проблемы с дисковым вводом-выводом виртуальных машин, использующих данную CVM и является в большинстве случаев единственно правильным вариантом остановки.
Отличный подарок для любителей виртуализации – более 1500 обучающих видео по продуктам VMware (vSphere, NSX, vSAN, Cloud), 60+ курсов для самостоятельной подготовки, а так же несколько курсов для подготовки к сертификациям VCP, VCAP.
Прекрасная возможность почерпнуть новые знания, либо подготовиться к сдаче экзаменов.
Еще одна хорошая новость от Nutanix. С 22 апреля 2020 года по 31 июля, участники Nutanix University со статусом партнера имеют возможность на одну бесплатную попытку сдачи экзаменов NCP, NCAP, NCSA L1 . Получить ваучеры на бесплатную сдачу экзамена можно на Nutanix University в разделе сертификации.
Иногда, в интерфейсе управления Dell iDRAC зависают ранее запущенные задачи, которые препятствуют последующему запуску различных процедур на сервере, например, обновлению Fimrware.
Задачи висят в очереди (jobqueue) на различном проценте выполнения от 1 до 99% и не двигаются дальше. Подобное можно встретить при первоначальной настройке сервера из ранее подготовленного шаблона. В моем случае процесс «встал» на нескольких серверах при конфигурации raid-контроллера.
Если удалить задачу через web интерфейс не получается, перезапуск iDRAC так же не помогает и задачи продолжают находиться в очереди, можно попробовать воспользоваться командным интерфейсом racadm. Для этого необходимо подключиться к iDRAC по SSH.
Получить текущую очередь задач: jobqueue view
В выводе команды будет необходимый нам ID, например:JID_876343082193
Если задача продолжает находиться в зависшем состоянии, можно принудительно попытаться прервать все задачи в очереди (нужно быть осторожным и не прервать что-то действительно нужное и работающее, те же обновления firmware): jobqueue delete -i JID_CLEARALL_FORCE
Скорее всего, после этой команды очередь задач будет очищена и можно будет выполнять дальнейшие работы по настройке\обновлению сервера.
В этот раз у нас никаких гайдов, новостей, а только классические «сисадминские байки» про бубны, магию и вот это вот все. История будет немного поучительная, немного про собственную глупость, но кому-то может оказаться в дальнейшем полезной.
Я всегда считал, что баги прошивок случаются у кого-то другого, и меня это не касается. Но не в этот раз.
История одного бага, собственной глупости и «шаманства» ниже.
