Записки о виртуализации и о жизни
Столкнулись со странной проблемой – Lenovo XClarity Administrator (LXCA) не может обновить прошивку сетевой карты Intel, при это все остальные компоненты обновляет без проблем.
Решение не менее странное – нужно отключить SAN:
1920 февраля 2020 года ожидается выход новой версии бесплатного мониторинга систем хранения Stor2RRD.
Поддержка новых систем хранения и ПО:
Stor2RRD от поддержки корпоративных систем переходит к поддержке популярных SOHO решений, если в версии 2.70 поддержан FreeNAS, то во втором-третьем кварталах 2020 года планируется поддержать и другие очень популярные решения начального уровня:
Самое главное – обещают поддержать отечественную систему хранения RAIDIX!
UPDATE:
Также анонсирована дорожная карта для мониторинга виртуальных сред LPAR2RRD:
Q2 2020
Q3 2020
UPDATE 2.0:
В платной версии STOR2RRD v2.80 будет доступная полная топологическая схема SAN через инструмент Mapping.
Всем привет и с НГ праздниками!
В декабре 2019 Интернет бурлил от новости о том, что в SSD-накопителях HPE обнаружена критическая неуязвимость, выводящая SSD из строя после трех лет работы. Прочитать об этом можно, например, в блоге Алексея.
К сожалению, у меня практически не использовались SSD от HPE, за исключением пачки VK000240GWJPD, установленной в блейд-серверах, поэтому я с радостью выдохнул и продолжил ничего не делать работать.
Всем привет!
Пятница, вечер, дождик…
1) В одной компании вышел из строя RAID6 на HP Proliant Gen6, виртуальные машины на VMware ESXi стали частично недоступны.
Пошли за бэкапами на систему хранения QNAP – оказалось, что она тоже потеряла два диска в RAID5, вследствие чего бэкапов тоже нет.
Владелец взял где-то два брендовых SATA-диска IBM, объединил их в программное зеркало (динамический диск MS Windows) и скинул туда данные с сервера Hyper-V. Сервер Hyper-V был переформатирован под ESXi.
Когда через месяц-два он раздобыл новый сервер под Hyper-V, оказалось, что оба IBM-диска неживые.
Я не уточнял у него, как он вышел из этой ситуации.
2) В другой компании внезапно стали недоступными виртуальные машины, находящиеся на одном из RAID-массивов. Как оказалось, LUN3, состоящий из двух SSD-дисков в зеркала, решил что ну его…
У нас же есть бэкапы, заявил мой тезка. Угу-угу, VMware Data Protection 6.1.2 не загружался, в консоли висела надпись:
|
1 |
/usr/local/vdr/configure/bin/checkforddrpreset.pl", exit status=0 |
Перезагрузка не помогла, через час все было точно также.
vDP пытались оживить сначала вручную, потом через техподдержку VMware. Третий по счету инженер из EMC смог оживить бэкапы и мы узнали… что последний бэкап сделан год назад. Так как “Retention Policy” требует хранить бэкапы за последние 90 дней…
Тут мой тезка и говорит “у меня есть еще одна система резервного копирования, сохраняющая файлы на сервер в Amazon. Но я залогиниться туда не могу 🙁
В общем, сервер с бэкапами на Amazon оказался заражен каким-то ransomware…
Параллельно была сделана попытка выключить и включить система храения с выдергиванием/втыканием SSD-дисков (потому что она еще и на RAID-контроллер ругалась)…
После включения массива сдохло еще 4 SAS-диска (2 уже не работали), вследствие чего Lun2 ушел следом за Lun3. Как оказалось, MD3220i более 7 лет.
Какие выводы (кроме настройки уведомлений) вы бы сделали из обоих историй?
Какие epic fail были у вас?
Однажды мы решили закопать стюардессу поменять наш прокси-сервер Microsoft TMG на что-то более новое. И вот как-то ночью звонит инженер из HPE и срывающимся голосом сообщает, что наша система хранения данных HPE 3PAR перестала отсылать отчеты о своем самочувствии. Так как звонил не круглосуточный диспетчер, было ясно, что это фигня!
На следующий же день я зашел на веб-интерфейс Virtual Service Processor (далее VSP) и выполнил операцию SPmaint -> 2. Network Configuration -> 7. Test 3PAR Secure Service Collector Server.
Ошибка HTTP 407 намекает, что текущий прокси-сервер перестал принимать учетные данные с HPE 3PAR VSP.
Continue reading “HPE 3PAR VSP сброс пароля cpmaint и настройка Proxy”
Коллеги поделились решением проблемы установки ESXi на HPE Superdom в режиме Boot from SAN.
—
У нас есть партиция Superdom из двух лезвий gen8, процессоры серии Intel Xeon E7-2800 v2 и HBA Qlogic HP QMH2672 16Gb с версией fw 8.07.16.
Я хотел установить туда HPE ESXi 6.0u3 (preGen9), так как именно она является последней поддерживаемой версией по данным матриц совместимости HPE и VMware.
При установке столкнулся с тем, что Wizard не видит презентованный диск для установки в режиме Boot from FC SAN.
Рядом стоит точно такая же партиция, состоящая из одного лезвия с такой же HBA. Проблем при установке ESXi там не было.
В поисках решения я перепробовал все сборки HPE’шных образов ESXi (а также оригинальных) – только HPE 6.7U1 увидел диск для установки, но его поставить нельзя 🙂
Я начал сравнивать драйверы для QMH2672 в различных образах ESXi и выяснил, что:
В VMware HCL написано, при HBA с прошивкой 8.07.xx в ESXi 6.0U3 должны работать версии драйвера от 2.1.63 до 2.1.70.
Странно – на первую патрицию успешно установился ESXi с версией драйвера 2.1.50, которая отсутствует в HCL 🙂
Затем я попробовал собрать свой образ с драйвером 3.1.16 из offline bundle, но при сборке получил ошибку зависимости, которой нет в 6.0. Не зря этот драйвер входит только в дистрибутив 6.7 😉
На всякий случай, для чистоты эксперимента я снес все зоны и сделал только зонинг только на одну систему хранения, где расположен загрузочный LUN.
УРА! После перезагрузки хост успешно увидел LUN для установки 🙂
Продолжив эксперименты, я нашел причину такого поведения – HPE StoreOnce!!!111
В ESXi до версии 6.7 существует ограничение в 1024 пути. Catalyst, расположенный на StoreOnce, с лихвой переполнял это ограничение.
И только в ESXi 6.7 количество возможных путей увеличено до 4096, вследствие чего хост нормально видел загрузочный лун!
Последние 8 лет я администрирую преимущественно серверы HPE. Интерфейс удаленного управления серверами называется iLO, за эти годы он прошел по пути развития от iLO100 до iLO5.
Для работы с консолью сервера было всего два варианта: .NET-надстройка (Integrated Console), поддерживаемая только в Internet Explorer и Java, устанавливаемая дополнительно.
В силу определенных проблем, случающихся с Java, я не любитель использовать их на серверах.
Я как-то привык к IE за годы работы с iLO2, однако, в iLO4 открытия консоли необходимо было ждать порядка минуты.
Когда у нас появился iLO5, я обнаружил в нем третий вариант: HTML5-реализацию консоли сервера. Внезапно консоль поверх HTML5 оказалась столь же шустрой, что и у Java, а у меня появился новый любимец.
Особенно грустно было сравнивать скорость открытия консоли в iLO4 и iLO5.
Какова же была моя радость, когда после обновления прошивки iLO4 до версии 2.70, я увидел HTML5 консоль и там.
Чтение Release notes показало, что HPE любезно добавили в iLO4 этот вариант работы.
Опыт эксплуатации серверов Lenovo ThinkSystem выявил одну болячку. При использовании M.2 Mirror комплекта для размещение гипервизора неожиданно виртуальный диск в RAID распадается на два – каждому накопителю свой виртуальный диск, система сыпет ошибками.
Решение довольно простое – надо удалить второй дубликат в меню F1 Setup –> UEFI Setup –> System Settings –> Storage –> M.2 + Mirroring Kit Configuration Utility –> Virtual Disk Management и дождаться ребилда. Если диск не ребилдится, а пишет Foreign, то выбрать Import.
Проблеме уже года полтора, но только сейчас Lenovo официальное её признала, выпустив заметку в базе знаний M.2 + Mirror Kit RAID 1 splits into 2 foreign RAID 1 drives with possible rebuild failure – Lenovo ThinkSystem.
Для предупреждения необходимо обновить прошивку M.2 Mirror до версии v2.3.10.1194 (она же 2.3.10.1098).
HPE StoreOnce – это такой аппаратно-программный апплайнс, на который можно делать резервные копии.
К программной части периодически выходит обновление, к аппаратной части – прошивки.
StoreOnce даже имеет встроенное оповещение:
|
1 2 |
The following event occurred: d2d.software.upgrade.notify Root Cause:The software on this device has not been upgraded in the past six months. |
Так как под рукой не оказалось гайда по обновлению, а сайт HPE был недоступен в силу каких-то очередных преобразований, я решил черкнуть заметку тут.
На новом кластере с Gen10 и vSphere 6 была обнаружена новая проблема: ряд хостов не видели ряд хранилищ с HP EVA 8400.
Лун презентован и виден в списке устройств, однако…
Операция Rescan не помогает, в журнале событий хоста написано “Lost access to volume aaa-aaa-aaa-aa (VMFS Datastore) due to connectivity issues. Recovery attempt is in progress and outcome will be reported shortly”