Когда заказчик видит две (вроде бы) одинаковые железки — Dell EMC VxRail и «точно такой же» сервер Dell vSAN ReadyNode по цене отличающейся в три раза — у него из ушей начинает валить пар, лицо краснеет и он начинает возмущаться, что его здесь пытаются развести.
Готовые решения, подобные VxRail, удобны, обычно имеют упрощенный единый интерфейс развертывания и управления, но стоят как самолет и (опять-таки) не гарантируют 100% защиты от проблем с прошивками и обновлениями. Да, все тестируется и накатывается в комплексе, но всегда найдется уникальный случай у заказчика, факапер-тестировщик у производителя или админ «шаловливые ручки».
1. Назовите хотя бы одного производителя первого эшелона, который не подвержен риску ухода и России. Вам известен хотя бы один сервер, собранный в России из российских компонентов? Сервера Huawei и т.п. с бумажной наклейкой «Сделано в России» не предлагать…
2. А почему компании используют брэндовые серверы HPE/DELL/Lenovo и т.п., а не собирают из «open source» железа свои собственные? Можно же купить вполне приличные компоненты и даже сборку заказать, да еще и дешевле выйдет…
Если есть контракт на поддержку, то «посылать» для вендора проблематично.
Качество поддержки зависит от конкретного человека «с той стороны» или возможности на него выйти через заслоны 1-2 линий.
Вообще, мое стойкое убеждение, что при любом уровне поддержки нужно и самому поработать — поиск сходных сообщений об ошибке, поиск корневой причины проблемы, статьи в базах знаний вендора оборудования и ПО.
Примеры из собственной практики:
1. Обновили один ESXi 6.5 хост в кластере VMware, отвалились все Датасторы с СХД DELL SCv2020. Откатил обновления, все ОК. Ищу по симптомам — нахожу статью «SC Storage Customer Notification: Driver Compatibility with Front End SAS Connectivity». Одна команда и перезагрузка — все работает с последними обновлениями.
2. Другой случай описывал выше (проблема с vMotion) — кейс в техподдержке догнали до 3-го уровня, но так ничего и не решили. Нашел статью у VMware: ESXi 6.7 U2/U3 unresponsive when running Dell OpenManage Server Administrator 9.3.0 (74696). Удалил проблемный VIB (он был только на одном хосте в кластере!) и все заработало.
Комментарии из личного опыта и попытка развеять некоторые иллюзии у коллег.
Мы решим программные проблемы «железными» методами:
mrzar:
… в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA)
Naves:
… Очень часто лезть в структуру БД не даёт производитель софта или их представитель. Физически подключиться к базе и посмотреть список таблиц заказчик конечно может, но вот за попытки там что-нибудь «оптимизировать» могут быть и всякие меры политического воздействия.
1. Мысль — если софт работает медленно (1С, SAP, etc.) надо купить быструю flash-хранилку, мощные многоядерные процы и база данных «полетит», период в 1С закроется за 5 минут, OLAP-кубы построятся за 15 минут и т.д.
Реальная жизнь — да, софт обычно начинает работать быстрее, но тех же или схожих результатов можно добиться «даром» — выбрав и правильно настроив «виртуальное железо» ВМ на платформе виртуализации, тип виртуального диска у ВМ, сам SQL-сервер, параметры рабочих и служебных баз, план обслуживания в SQL для регулярной реиндексации, чистки кэша и т.п., да просто разнести нагруженные базы по двум разным SQL’ям на разных хостах! Для этого не нужен крутой DBA, изменение структуры БД и ручная оптимизация запросов — для той же 1С найти толковое руководство по настройке нет никаких проблем.
2. Купить N штук мощного «железа» с запасом и потом не париться с докупкой новых «коробок» при увеличении нагрузки, вместо N*X «железа» попроще.
Предыдущие комментаторы уже заметили, что вывод на обслуживание/сбой одного хоста из трех имеющихся – это «потеря» 1/3 всей мощности кластера. Если у нас в кластере будет 6 двухсокетных хостов с той же общей кластерной ресурсной емкостью, то вывод такого хоста на обслуживание приведет к «потере» 1/6 всей мощности кластера – есть разница?
Аргумент mrzar, что… увеличение количества хостов влияет на время их обслуживания, а этим у нас занимается один человек… мне кажется спорным. Да, нужно будет обслуживать (условно) в 2 раза больше хостов, но в системе виртуализации такие работы не требуют «ночных бдений» или ожидания окна обслуживания раз в квартал. Влияние 1/6 нагрузки (с выведенного на обслуживание) хоста, размазанной на 5 оставшихся несопоставимо с 1/3 размазанной на 2 – добавить на каждый оставшийся хост 16,6% или 3,3%.
В случае гиперконвергенции дополнительный аргумент за большее количество «коробок» — выше отказоустойчивость и производительность SDS.
3. mrzar:… на аналогичных серверах 7-го и 8-го поколений… никаких проблем не было до тех пор, пока компания HPE не отказалась от их поддержки и обновить ESXi с версии 6.0, хотя бы до 6.5, без бубна не получилось…
Что-то из серии «я не нашел»…
На сайте VMware в разделе Custom ISOs при загрузке файла фирменного образа HPE есть ссылка Click Here for Pre-Gen9 Custom Image. Пользуемся этими исошниками ESXi 6.5 в нашей инфраструктуре, как раз 7 и 8 поколение Proliant’ов.
Вариант для «кулибиных» — загрузить стандартный образ ESXi 6.5 и добавить в Update Manager’е фирменный HPE репозиторий с драйверами и расширениями.
4. mrzar:… И это решение, в последствии, и спасло Компанию от потери актуальных данных, включая почтовые ящики сотрудников, базы данных и общие файлы. В совокупности, речь идет о 30+ терабайтах информации.
Если в компании нет никакой системы резервного копирования, то потеря данных просто вопрос времени – аппаратный/программный сбой, злонамеренный или криворукий пользователь – от них не поможет никакой RAID, snapshot’ы и т.п.
Не дают денег на ленточную библиотеку или backup-appliance, делай «костыли» на внешнем usb-диске за 5.000 руб. и проводи показательные «падения» сервисов и (как бы) «потерю» данных для руководства с последующим долгим восстановлением под «брюзжание» — вот была бы у нас нормальная СРК, мы бы «за 5 секунд» восстановились… Почему-то в этих «контролируемых» случаях и деньги находятся и разговор на деловое русло сворачивает.
5. mrzar:… Проблема оказалась в некорректной работе прошивки RAID контроллера и драйвера HPE с vSAN… Не буду покупать самое свежее железо! Лучше годик подождать… HPE — эта компания показала во всей красе качество своей поддержки в критической ситуации. И в целом, количество багов в оборудовании Enterprise сегмента заставляет меня тревожиться за наше будущее… для VMware я больше не буду покупать железки для крупных компаний, каких-либо вендоров, отличных от DELL…
Жаль разочаровывать коллег, но текущая ситуация такова, что для подавляющего числа производителей серверов/СХД/коммутаторов (добавьте свое) компоненты делает один-два гиганта типа Avago/Broadcom, который засосал в себя LSI (RAID-контроллеры и т.п.), Brocade и Emulex (Fiber Channel и около него), и т.д. и т.п.
Поэтому проблема с кривой прошивкой для 10G адаптеров абсолютно одинаково затронула серверы производства HPE, DELL, Huawei и всех остальных.
Вот пример с описанием фиксов (в том числе и VMware VSAN) в прошивке для RAID-контроллера LSI, который «типа» Dell PERC H730/H730P/H830/FD33xS/FD33xD Mini/Adapter RAID Controllers.
Firmware version 25.5.6.0009 fixes
-Controller is less likely take a logical drive offline in VSAN
-Controller now passes the proper drive group while creating a configuration using HII
-Controller now retains HII device setting after a boot
-Controller now gives status on all drives including failed drives with Perc CLI «show all» command
-Controller now performs Patrol Read on SSD drives to better align with the industry
-Reinserting a drive from a VD will no longer lead to a foreign state
-Controller now handles crypto erase on Micron 5100 SSD drives
-Controller reduces delay if there is a bad PHY condition at boot
-Controller now reports smart trip condition on non-Raid drives
-Reduces PL errors 0x3110e03 and 0x31110d01 after resetting a SATA target
-Controller now gives correct messaging when a power supply is hot removed from an enclosure
-Controller better handles poorly formed ATA passthrough CDBs.
-Unsupported «Raid00» option in HII has been removed
В предыдущей прошивке тоже «лечили» VSAN.
Никто, даже в первом эшелоне, не делает все полностью свое. Кривой драйвер или firmware одинаково повлияет на всех.
6. Про «грамотных» интеграторов/вендоров и их услуги:
Обращение к системному интегратору или покупка услуги поддержки/внедрения/инсталляции от интегратора/вендора не дает никаких гарантий качества работы решения. Видел хосты виртуализации, подключенные только к одному контроллеру СХД (работа инженера-установщика HPE в одном из филиалов). Развертывал у заказчика решение Cisco HCI, для которого «специалисты» интегратора из первой тройки предусмотрели подключение хостов с 40G карточками в 10G порты Fabric Interconnect’а гидра-кабелями (сетевики оценят юмор). Получал рекомендацию 3-го (!!!) уровня поддержки DELL обновить vCenter appliance 6.7 до последней версии апдейтов, т.к. она не поддерживает наш текущий ESXi (VMware уверена в обратном) – проблема с жуткими тормозами vMotion в итоге была в несовместимом релизе DELL OpenManage VIB. Слышал предложение системного архитектора известного интегратора воткнуть FCoE оборудование в классический Ethernet коммутатор: «он же over Ethernet, в чем проблема»?
Итого – имя вендора/интегратора вообще ничего не значит в реальной жизни, если ты сам не понимаешь, что и как будут внедрять. Криворукий установщик может «убить» грамотно проработанное решение. Безграмотный архитектор может «напроектировать» такое, что самый замечательный инженер не сможет заставить работать.
Готовые решения, подобные VxRail, удобны, обычно имеют упрощенный единый интерфейс развертывания и управления, но стоят как самолет и (опять-таки) не гарантируют 100% защиты от проблем с прошивками и обновлениями. Да, все тестируется и накатывается в комплексе, но всегда найдется уникальный случай у заказчика, факапер-тестировщик у производителя или админ «шаловливые ручки».
2. А почему компании используют брэндовые серверы HPE/DELL/Lenovo и т.п., а не собирают из «open source» железа свои собственные? Можно же купить вполне приличные компоненты и даже сборку заказать, да еще и дешевле выйдет…
Качество поддержки зависит от конкретного человека «с той стороны» или возможности на него выйти через заслоны 1-2 линий.
Вообще, мое стойкое убеждение, что при любом уровне поддержки нужно и самому поработать — поиск сходных сообщений об ошибке, поиск корневой причины проблемы, статьи в базах знаний вендора оборудования и ПО.
Примеры из собственной практики:
1. Обновили один ESXi 6.5 хост в кластере VMware, отвалились все Датасторы с СХД DELL SCv2020. Откатил обновления, все ОК. Ищу по симптомам — нахожу статью «SC Storage Customer Notification: Driver Compatibility with Front End SAS Connectivity». Одна команда и перезагрузка — все работает с последними обновлениями.
2. Другой случай описывал выше (проблема с vMotion) — кейс в техподдержке догнали до 3-го уровня, но так ничего и не решили. Нашел статью у VMware: ESXi 6.7 U2/U3 unresponsive when running Dell OpenManage Server Administrator 9.3.0 (74696). Удалил проблемный VIB (он был только на одном хосте в кластере!) и все заработало.
Мы решим программные проблемы «железными» методами:
mrzar:
… в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA)
Naves:
… Очень часто лезть в структуру БД не даёт производитель софта или их представитель. Физически подключиться к базе и посмотреть список таблиц заказчик конечно может, но вот за попытки там что-нибудь «оптимизировать» могут быть и всякие меры политического воздействия.
1. Мысль — если софт работает медленно (1С, SAP, etc.) надо купить быструю flash-хранилку, мощные многоядерные процы и база данных «полетит», период в 1С закроется за 5 минут, OLAP-кубы построятся за 15 минут и т.д.
Реальная жизнь — да, софт обычно начинает работать быстрее, но тех же или схожих результатов можно добиться «даром» — выбрав и правильно настроив «виртуальное железо» ВМ на платформе виртуализации, тип виртуального диска у ВМ, сам SQL-сервер, параметры рабочих и служебных баз, план обслуживания в SQL для регулярной реиндексации, чистки кэша и т.п., да просто разнести нагруженные базы по двум разным SQL’ям на разных хостах! Для этого не нужен крутой DBA, изменение структуры БД и ручная оптимизация запросов — для той же 1С найти толковое руководство по настройке нет никаких проблем.
2. Купить N штук мощного «железа» с запасом и потом не париться с докупкой новых «коробок» при увеличении нагрузки, вместо N*X «железа» попроще.
Предыдущие комментаторы уже заметили, что вывод на обслуживание/сбой одного хоста из трех имеющихся – это «потеря» 1/3 всей мощности кластера. Если у нас в кластере будет 6 двухсокетных хостов с той же общей кластерной ресурсной емкостью, то вывод такого хоста на обслуживание приведет к «потере» 1/6 всей мощности кластера – есть разница?
Аргумент mrzar, что… увеличение количества хостов влияет на время их обслуживания, а этим у нас занимается один человек… мне кажется спорным. Да, нужно будет обслуживать (условно) в 2 раза больше хостов, но в системе виртуализации такие работы не требуют «ночных бдений» или ожидания окна обслуживания раз в квартал. Влияние 1/6 нагрузки (с выведенного на обслуживание) хоста, размазанной на 5 оставшихся несопоставимо с 1/3 размазанной на 2 – добавить на каждый оставшийся хост 16,6% или 3,3%.
В случае гиперконвергенции дополнительный аргумент за большее количество «коробок» — выше отказоустойчивость и производительность SDS.
3. mrzar:… на аналогичных серверах 7-го и 8-го поколений… никаких проблем не было до тех пор, пока компания HPE не отказалась от их поддержки и обновить ESXi с версии 6.0, хотя бы до 6.5, без бубна не получилось…
Что-то из серии «я не нашел»…
На сайте VMware в разделе Custom ISOs при загрузке файла фирменного образа HPE есть ссылка Click Here for Pre-Gen9 Custom Image. Пользуемся этими исошниками ESXi 6.5 в нашей инфраструктуре, как раз 7 и 8 поколение Proliant’ов.
Вариант для «кулибиных» — загрузить стандартный образ ESXi 6.5 и добавить в Update Manager’е фирменный HPE репозиторий с драйверами и расширениями.
4. mrzar:… И это решение, в последствии, и спасло Компанию от потери актуальных данных, включая почтовые ящики сотрудников, базы данных и общие файлы. В совокупности, речь идет о 30+ терабайтах информации.
Если в компании нет никакой системы резервного копирования, то потеря данных просто вопрос времени – аппаратный/программный сбой, злонамеренный или криворукий пользователь – от них не поможет никакой RAID, snapshot’ы и т.п.
Не дают денег на ленточную библиотеку или backup-appliance, делай «костыли» на внешнем usb-диске за 5.000 руб. и проводи показательные «падения» сервисов и (как бы) «потерю» данных для руководства с последующим долгим восстановлением под «брюзжание» — вот была бы у нас нормальная СРК, мы бы «за 5 секунд» восстановились… Почему-то в этих «контролируемых» случаях и деньги находятся и разговор на деловое русло сворачивает.
5. mrzar:… Проблема оказалась в некорректной работе прошивки RAID контроллера и драйвера HPE с vSAN… Не буду покупать самое свежее железо! Лучше годик подождать… HPE — эта компания показала во всей красе качество своей поддержки в критической ситуации. И в целом, количество багов в оборудовании Enterprise сегмента заставляет меня тревожиться за наше будущее… для VMware я больше не буду покупать железки для крупных компаний, каких-либо вендоров, отличных от DELL…
Жаль разочаровывать коллег, но текущая ситуация такова, что для подавляющего числа производителей серверов/СХД/коммутаторов (добавьте свое) компоненты делает один-два гиганта типа Avago/Broadcom, который засосал в себя LSI (RAID-контроллеры и т.п.), Brocade и Emulex (Fiber Channel и около него), и т.д. и т.п.
Поэтому проблема с кривой прошивкой для 10G адаптеров абсолютно одинаково затронула серверы производства HPE, DELL, Huawei и всех остальных.
Вот пример с описанием фиксов (в том числе и VMware VSAN) в прошивке для RAID-контроллера LSI, который «типа» Dell PERC H730/H730P/H830/FD33xS/FD33xD Mini/Adapter RAID Controllers.
Firmware version 25.5.6.0009 fixes
-Controller is less likely take a logical drive offline in VSAN
-Controller now passes the proper drive group while creating a configuration using HII
-Controller now retains HII device setting after a boot
-Controller now gives status on all drives including failed drives with Perc CLI «show all» command
-Controller now performs Patrol Read on SSD drives to better align with the industry
-Reinserting a drive from a VD will no longer lead to a foreign state
-Controller now handles crypto erase on Micron 5100 SSD drives
-Controller reduces delay if there is a bad PHY condition at boot
-Controller now reports smart trip condition on non-Raid drives
-Reduces PL errors 0x3110e03 and 0x31110d01 after resetting a SATA target
-Controller now gives correct messaging when a power supply is hot removed from an enclosure
-Controller better handles poorly formed ATA passthrough CDBs.
-Unsupported «Raid00» option in HII has been removed
В предыдущей прошивке тоже «лечили» VSAN.
Никто, даже в первом эшелоне, не делает все полностью свое. Кривой драйвер или firmware одинаково повлияет на всех.
6. Про «грамотных» интеграторов/вендоров и их услуги:
Обращение к системному интегратору или покупка услуги поддержки/внедрения/инсталляции от интегратора/вендора не дает никаких гарантий качества работы решения. Видел хосты виртуализации, подключенные только к одному контроллеру СХД (работа инженера-установщика HPE в одном из филиалов). Развертывал у заказчика решение Cisco HCI, для которого «специалисты» интегратора из первой тройки предусмотрели подключение хостов с 40G карточками в 10G порты Fabric Interconnect’а гидра-кабелями (сетевики оценят юмор). Получал рекомендацию 3-го (!!!) уровня поддержки DELL обновить vCenter appliance 6.7 до последней версии апдейтов, т.к. она не поддерживает наш текущий ESXi (VMware уверена в обратном) – проблема с жуткими тормозами vMotion в итоге была в несовместимом релизе DELL OpenManage VIB. Слышал предложение системного архитектора известного интегратора воткнуть FCoE оборудование в классический Ethernet коммутатор: «он же over Ethernet, в чем проблема»?
Итого – имя вендора/интегратора вообще ничего не значит в реальной жизни, если ты сам не понимаешь, что и как будут внедрять. Криворукий установщик может «убить» грамотно проработанное решение. Безграмотный архитектор может «напроектировать» такое, что самый замечательный инженер не сможет заставить работать.