Pull to refresh

Comments 182

Теперь в мире есть ещё один мудрый и образованый IT директор…
Мы недавно отказались от рабочих станций HP и перешли на Lenovo. Причём Lenovo объективно классом ниже: звучит как вертолёт на взлёте и вообще не такое удобное… да и медленнее.

Но отсутствие глюков с прошивками и необходимости ждать год-два пока они все «детские болячки» исправят — решает.
1. Не HP, а HPE, это 2 разные компании
2.
Мы, со спокойной душой, переместили все виртуальные машины

А вот не надо было так делать. Пара недель нагрузочных тестов вероятнее всего избавила бы вас от этих проблем. Никогда не суйте новое железо/ПО сразу в продуктив, если у вас там критические сервисы, никогда!
3.
DELL, насколько мне известно, приобрела VMware

Ага, ещё в 15-м году, только никакой интеграции дополнительной не было и нет. И у любого вендора могут быть проблемы с прошивками/драйверами, эта проблема не только HPE.
Не HP, а HPE, это 2 разные компании

Спасибо, исправил. В целом, именно термин HPE использовал.
А вот не надо было так делать.

Дело в том, что мы так и делали, сначала десяток незначительных машин крутились в новом кластере пару недель, до Нового года. Все было нормально, потом переместили все остальные. Все веселье началось уже к концу января.
а куда старый-то кластер делся? там где 24-часа считали? ну и да — перемещать всё на только что установленную новую систему — бизнес с ножом у горла стоял? или деньги владельца сэкономить решили?
Подскажите, а почему выбрали именно 4-х сокетные системы и топовые процессоры? Хосты по стоимости вышли как самолет…

а по поводу «Не буду покупать самое свежее железо! Лучше годик подождать.» — так проблема могла быть и с новыми драйверами на старом железе (SPP накатили ведь).
Вот честное слово! Новый год на носу — в правильных местах устраивают network freeze, чтобы отдохнуть спокойно и думать о семьях, а не о том, как все внезапно чинить. Что мешало нагрузить новый кластер, уйти пить шампанское и есть салаты, а после окончания праздников уже спокойно заниматься миграцией, убедившись, что за время тестирования никаких багов не вылезло? ;)
Вот честное слово! Новый год на носу — в правильных местах устраивают network freeze, чтобы отдохнуть спокойно и думать о семьях


Мы отлично отдохнули в Новый год. Даже пару недель после каникул поработали нормально.
Подскажите, а почему выбрали...

В целом по ряду причин, основные: а) этот апгрейд на следующие 7 лет, поэтому запас по максимум, б) было стойкое желание не увеличивать число хостов и снизить нагрузку на CPU кластера хотя бы до 25% (на старом железе она дошла до 75%, сейчас общая средняя нагрузка на 12 процессоров кластера составляет 27%), в) даже с этими процессорами, после переноса всех машин и разнесением голодных машин к CPU по разным хостам, мы получили время обработки документов в 7-8 часов. (первоначальные тесты показали результат в 4 часа, когда только одна машина крутилась на новом хосте), г) на данные хосты планировался и был перенесен высоконагруженный кластер с веб приложением из чужого облака, как и прочие ресурсы разбросанные по чужим облакам.

так проблема могла быть и с новыми драйверами на старом железе...

Могла быть, но там сервис пак обычно все решает. А с новым железом, как оказалось, сервис пак приходится ждать пару-тройку месяцев. Это непозволительная роскошь.

а куда старый-то кластер делся? там где 24-часа считали?


Он никуда не делся, но там объем хранилища в 5 раз меньше. Мы же забрали из облаков кучу машин и назад быстро их не перенесешь. Когда договор со сторонней компанией согласуют неделями — это очевидно.
стойкое желание не увеличивать число хостов

Почему? 3 хоста это минимальная адекватная конфигурация vsan (знаю, есть вариант с 2 и witness, но это изврат очевидный). С вашим бюджетом можно было набрать побольше хостов и иметь куда больше свободы с политиками, раз у вас ssd — тут и raid всякие, и сжатие, и возможность пережить больше одного отказа. Понятно, что это все не помогло бы с описанной проблемой, но на будущее как-то вариант не очень по мне.

снизить нагрузку на CPU кластера

Платины с частотой ниже плинтуса как-то не вписываются в это желание.
Платины с частотой ниже плинтуса как-то не вписываются в это желание


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

Почему? 3 хоста это минимальная адекватная конфигурация vsan

Ну, например, потому что увеличение количества хостов влияет на время их обслуживания, а этим у нас занимается один человек, которому лишние «рты» уже «поперек горла», ибо времени не хватает и так, плюс дополнительная штатная единица не вписывается в видение бизнеса пока, плюс рост OpEx на размещение. В нашей Компании это не приветствовалось на тот момент. А вот CapEx — пожалуйста.
тут и raid всякие, и сжатие

Raid как раз, в случае с vSAN — это «прошлый век». У данного решения свой «RAID». Есть и дедупликация и сжатие. Гиперконвергентная инфраструктура, же.
Хотя каюсь, я строил всаны и на Raid0 15к SAS, которые всану отдавались в виде LUN, как один диск. И помечались как SSD, вполне жизнеспособное и уже давно работающее решение. Голь на выдумку хитра.
>Все дело в параллельных процессах.
Если есть 1с, попробуйте сервер самого агента 1с вынести на какой-нибудь десктоп от 3ГГц и сравнить.
На самом деле, на производительность кластера 1С кладу болт, львиная доля клиентов работает с толстым клиентом. Выделил достаточно памяти и ядер кластеру и его не слышно. Основная нагрузка беспокоит в MSSQL и тут уже применяю тонкий подход.
Ну, например, потому что увеличение количества хостов влияет на время их обслуживания,

Если говорим об обслуживании, то рекомендуется хотя бы 4 хоста. Потому что тогда можно потерять один хост или перевести его в режим обслуживания. Объекты смогут переехать на оставшийся хост и данные будут опять в безопасности (если на дисках место позволяет конечно). А с 3 хостами вывод хоста даже на обслуживание это уже опасно, не говоря о выходе из строя. Плюс FT можно повысить.

Странное конечно такое видение, которое идет вразрез рекомендуемым практикам построения распределенных систем (коей vsan является) и повышения надежности кластера. Ладно бы еще денег было мало.

У данного решения свой «RAID

Не так выразился. Имел ввиду Erasure Coding политики самого vsan.
которое идет вразрез рекомендуемым практикам построения распределенных систем

Почему вразрез?
Сейчас я могу высвободить один хост из кластера для обслуживания. Постепенно, по мере роста числа вм, добавляю RAM, чтобы сохранить эту возможность. Единственное, на что влияет — на производительность. Доступность не страдает.

Да, представители VMware говорили, что нужно три узла, а лучше четыре, но можно и два :). Надолго запомнил эту фразу. Не знаю почему.
Ну вот вывели вы один хост. Эвакуировать объекты вы с него не сможете, а значит за оставшиеся объекты vsan уже ответственности не несет. FT=1 политику обеспечить невозможно. И тут бац, еще один хост выходит из строя. Я не знаю, как vsan ведет себе в этих ситуациях и каков шанс вернуть данные, введя обратно в строй хост на обслуживании, но вряд ли это будет приятная ситуация, да еще скорее всего данные будут потеряны хотя бы частично.

Именно для этого вмваре и вообще все, кто занимает распределенными системами, дают одну простую рекомендацию — чем больше хостов, тем лучше. С 4 хостами у вас куда больше свободы. С FT=1 политикой вы можете вывести хост на обслуживание, предварительно эвакуировав с него все объекты. После вы можете пережить выход из строя еще одно хоста. С 5 хостами вы уже можете raid1 с FT=2, что даст пережить потерю двух хостов подряд. Правда с большой платой за дисковое пространство. С 6 хостами благодаря ssd получите доступ к raid6, а это и места нормально, и FT=2.

2 хоста+witness это вообще костыль, который vmware явно со временем прикрутила для упрощения миграции существующих кластеров.
И тут бац, еще один хост выходит из строя

Да там даже не хост, там одного диска будет достаточно, чтобы попадали машины.
HP, HPE — разные компании, бубубу. Да. Вот только именно от хп хпе унаследовала абсолютно плевавший на все саппорт, хитрожопость в изготовлении железа и софта, несовместимого ни с кем и ни с чем и пр. плюшки. Вон, даже образы вмвари свои — ужас!
Я когда проблемный узел вижу и эти три волшебные буквы на фоне рыдающего бизнеса, вложившего в эти буквы много денег, мне всегда грустно становится. Самосбор лучше — чесслово!
Самосбор лучше — чесслово!

Была бы возможность прикрутить к самосбору что нибудь вроде iLo, а так, мыши плакали, кололись, но продолжали кушать кактус. Есть Intel vPro AMT, но не везде, лично мне не встречалось.
Да достаточно взять супермикру, всунуть какие хочешь диски и забыть про этот весь злой энтерпрайз.
кстати, да, бюджетные решения я всегда рекомендую на супермикре. IPMI там есть, достаточно для большинства задач.
Вот только я хз почему, но у меня со стабильной скоростью на SM дохнут встроенные сетевые интерфейсы каждые три-четыре года, уже четыре материнки лежат (X7/X8/X9 семейства и ещё одна Х10 на подходе — уже начинается странная чехарда формата «индикатор горит, но link is down»), физический уровень проверял — перепайка разъема нифига не даёт. Хотя надо сказать — это единственное, к чему я у SM могу прикопаться.
С установленной ОС есть корреляция? У меня бывало так редко, что грешил на драйвера в windows, тк если выключить/включить через панель управления, то все начинало работать.
VMWare ESXI 5.5-6.7, Linux 3.x-4.x, винда была только в виртуалках.
Питание. Серверов и свитчей. Где-то с землей и/или нулем расколбас. Притащите сетевые фильтры из обоих точек и померяйте разность потенциалов на земле, нуле и фазе.
Ну, это первое, что стоить проверить, но не единственное.
Проверено было всё. В стойке от одной фазы запитан сервер, свитч, и ещё одна машина. Разницы потенциалов нет вообще. Наводки тоже измерял. Это в одном месте.
В другом — питается по разным фазам, но расколбаса нет, мониторинг питания даёт идеальную картину по 230В на каждой фазе, земля-ноль тоже идеальные, что по утечке, что по сопротивлению. наводкок нет, но после первого случая заменил UTP на FTP, плюс замерил, не течёт ли ток по экрану — ничего не течёт.
А самая засада, что обычно дело происходит так: через 3-4 года планомерно начинает отваливаться один ethernet, перехожу на второй, на нём глюков нет (если перейти на первый — они сразу появляются), проходит пара-тройка месяцев и второй тоже начинает подыхать, к моменту перехода на 4ый(если он есть) срок работы сокращается до недели. Я даже все электролиты перепроверил по ESR и ёмкости — всё впорядке. Пыли нет, которая там что-то может коротить. Питание осциллографом у чипов смотрел — всё нормально. Диких вибраций — нет. ИМХО остаётся несколько вариантов — либо мне попадались материнки с браком чипов(но их слишком много и они разные, либо мне надо лететь в Лас-Вегас и ставить всё на зеро, т.к. неудачу я выработал, осталась только дикая удача), либо пайка чипов фиговая.
Ну такое себе. У нас за пару месяцев вылетело 40% всего супермикровского оборудования. Менять на 30 серверах материнки в выходные такое себе удовольствие.
Официального ответа не было, неофициальный «бракованная партия».
Что-то вы ребята делаете не так. У меня парк машин на супермикре в общей сложности за сотню перевалил уже наверное. Никаких проблем с ними не испытываю. Допускаю канеш что «бракованная партия», но вы что реально купили 30 матерей с одинаковым партнамбером?
Вот полностью поддерживаю про Супермикру! Собственно ее и подразумевал под самосбором. Ну или интеловые решения.
UFO just landed and posted this here
а как эта супермикра будет работать с ssd

Работать будет, как правило, не хуже, чем у Tier-1 брендов.


а не серверные варианты за ценники в разы дороже?

В "серверных вариантах" главное не ценник, а рабочие характеристики. Если вы абсолютно точно понимаете, что и зачем вам от SSD нужно и обеспечит ли это вон та дешевая модель — нет никакой проблемы поставить в сервер более дешевый диск. Но тут надо либо разбираться в теме, либо следовать рекомендациям вендора решения, под которое вы берете диски. Причем в большинстве случаев всё равно получится так, что по мере углубления в тему понимаешь верность этих рекомендаций. :)

UFO just landed and posted this here

В случае конкретно 970 Pro надо понимать две вещи — у них нет power loss protection и относительно невелика write endurance. Если их write endurance вам достаточна, то в сценарии "просто офисный сервак с дисками" я не предвижу каких-то проблем с ними. А вот под SDS, как у автора, брать крайне рискованно.

UFO just landed and posted this here

Наоборот — c S2D как раз будет больше потенциальных проблем. Консьюмерские диски если и использовать, то в простых как пробка решениях (типа простого зеркала, и то надо понимать, что в случае SSD вероятность отказа обоих дисков одновременно неиилюзорно выше, чем в случае HDD).


А S2D-кластеры крайне капризны к выбору оборудования для дисковой подсистемы (и если просто не заведется, несмотря на то, что все компоненты в списке валидированных — это еще хорошо, куда хуже, если уже в процессе эксплуатации разъедется).

Помнится, лет десять и чуть более назад IPMI (который умеет примерно то же самое) был практически на всех платах Supermicro, которые тогда активно использовались самосборщиками и приравненными к ним местными производителями (особенно мне памятен Kraftway — например, благодаря его замечательному RAID-контроллеру я имел возможность вживую полюбоваться на USN rollback в AD и даже потренироваться в его устранении).
Но с тех пор самосбором и прочими крафтвяеми я дела как-то не имел Что, с тех пор хуже стало?
Лет 10 назад было очень много fake-raid. Хотя с каким-то встроенным «аппаратным» adaptec (вроде aic 9410) тоже было весело, в простой режим HBA его переключить нельзя. А после обновления с win 2003 на 2008 система начала зависать на несколько секунд каждые n-секунд. В итоге где-то в FAQ от супермикро был найден какой-то патченый драйвер, который исправлял проблему, а на сайте самого adaptec такой версии вообще не было.

Образы вмвари у всех крупных вендоров свои — делл, хпе, леново, вроде бы циско тоже.

Но на dell я спокойно поставил esxi из vmware образа, а вот с hpe пришлось подсовывать фирменный ISOшник.
Странно. От G6 до G9 чистый образ VMWare 6.7 встает без проблем. Да, есть странности на DL360 G7 по датчикам железа, но это не сильно напрягает.
Неужели G10 не ставится с чистого образа?
На какой-то DL при установке оно меня покрыло матом, что кроме флешки, на которую его ставят нету других девайсов. Подсовывание фирменного образа всё решило — массив нашелся.

HPE DL360p g10 — esx 6.7 штатный образ без вопросов встал и работает.

Ставил с чистого образа, без пробем

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

Кстати, после заявления производителя о том, что они перестают поддерживать свое оборудование, я также перестаю придерживаться моральных норм для таких железок на покупку дополнительных сервисов и использую народные средства для открытия полного функционала iLO и т.д и считаю это правильной позицией.
Этот вариант казался единственным, поскольку в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA).

Этот вариант не проще?
Есть много нюансов, которые и не снились мудрецам…
Обычно в ERP системах через некоторое время начинает твориться ад и погибель с структуре БД, ибо бизнес хочет вчера, а подумать завтра уже поздно.
Очень часто лезть в структуру БД не даёт производитель софта или их представитель. Физически подключиться к базе и посмотреть список таблиц заказчик конечно может, но вот за попытки там что-нибудь «оптимизировать» могут быть и всякие меры политического воздействия.
Очень часто программист от заказчика умеет только в формошлепство, а за глубокое влезание ручками в систему, могут и по рукам бить.
Программисты от производителя обычно заняты внедрением очередных никому не нужного функционала, который должен быть вчера, и своего DBA у них тоже нет, потому что эффективность и оптимизация…
Ну или производитель софта просто кладёт болт на некоторых заказчиков, ибо у него параллельно горит исполнение госзаказа в соседней области. В итоге заказчику остаётся только надеяться, что конкретно его баг в его БД всплывет ещё у пары клиентов в других местах, и разработчик соблаговолит исправить его в следующей версии, которая выйдет осенью следующего года.
Sad but true.
«Безумству храбрых поем мы славу». Молодцы, правда, справились с ситуацией, и зря читатели зацикливают внимание только на HP. Ситуация, гибридный QNAP (SSD & HDD), слава богам не 30Tb, наиболее часто использующиеся данные (виртуалки) система сама держит на SSD, ситуация — майские выходные, система думает что ВСЕ виртуалки редко используются, мигрирует их на HDD, выходят люди на работу, ВСЕ виртуалки мигрируют на SSD, но из-за ошибок в прошивке, система пытается смигрировать скажем 3tb из HDD на 1tb SSD, все не помещается, но это не останавливает алгоритмы системы и данные пишутся поверх, в результате получаем, что на HDD данных уже нет, а на SSD каша, отлично отдохнули, в тот раз спасли только бэкапы на отдельном NAS, попытка разобраться с ситуацией привела к плачевному результату, для обновления прошивки нужна подписка на Enterprise поддержку, которая за пару лет перекрывает стоимость железа, вопрос закрыли сделав два LUN, быстрый из SSD, и чуть помедленней из HDD.
Странно, почему cat, а не dd используется для копирования файлов образов. Или dd просто нету в ОС от вмваре.
[****@****:~] dd --help
BusyBox v1.22.1 (2017-09-23 07:03:57 PDT) multi-call binary.

Usage: dd [if=FILE] [of=FILE] [ibs=N] [obs=N] [bs=N] [count=N] [skip=N]
[seek=N] [conv=notrunc|noerror|sync|fsync]

В esxi оно точно есть.
Без не относящихся к данному событию свойств, в чем бы мы выиграли?
Ну, например, используя dd можно прервать процесс, или если бы прервался из-за внешних причин (ошибок в фс, дисках и тд), а потом продолжить с нужного блока.
В крайнем случае, если файл образа большой, можно сделать два разных блока, первые 400гб и оставшиеся сколько-то-там, на разных носителях.

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

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

Почему так долго, не могу сказать, честно. А документы — Перепроведение Бухгалтерия 2.0, стандартное закрытие месяца.
да, именно так. конфигурация Бухгалтерия 2.0

спасибо! хорошая статья удачи вам с настройкой!

а чисто для перепроведения документов может лучше сделать отдельную машинку с ssd и памятью быстрой, и быстрым малоядерным процессором? Часто делают так, перепроведение на копии, которая крутится на быстрой «игровой» машине.
Базу 1С делают через механизм распределённых баз, и в «филиале» делают перепроведение, результат перепроведения мигрирует в боевую базу потом по мере необходимости.
Так платформа 1с не параллелится никак, ей частота важней, mssql использует сугубо как хранилище таблиц, туже скорость дал бы просто переход на ssd.
Хорошая история.
Куча дорогого железа, софта, и всё успешно рухнуло из-за кривой версии обновления прошивки рейд-контроллера.

Потому что вах! на всё про всё было 1 хранилище, аппаратная избыточность которого оказалась бесполезна при логическом сбое в прошивке.

А нефиг иметь 1 единственный сторадж на всё.

А как правильно сторадж конфигурировать? Насколько я знал, рабочий сторадж — всегда единственный. Да, внутри у стораджа — RAID или VSAN, но сторадж один.
Отдельный сторадж — для бэкапов.


Или VMWARE умеет high availability с двумя отдельными стораджами?


Поделитесь опытом

Есть особенности сборки VSAN котороя четка прописана в документации
Вы просто тупо накупили дисков и засунули в VSAN
Для тех кто тоже так себе директор ИТ не пользующийся услугами интеграторов
Условия:
Если связка из HDD и SSD
минимум 10% от обьема это должен быть SSD
Диску до 2TB
Условно хотим 8ТВ на сервер
Правильной набор
1 шт 2TB SSD
4 шт 2TB HDD
Одна дисковая группа на сервере
Условно хотим 16ТВ на сервер
Правильной набор
2 шт 2TB SSD
8 шт 2TB HDD
И две дисковые группы на сервере!!! а не диски по 4TB
Вся суть сборки VSAN именно в том что потеря одного диска не должна сказываться никак
вот по этому нельзя собирать VSAN из двух дисков.
Нельзя собирать на БОЛЬШИХ дисках… в случаю потери 1 диска репликация данных по времени будет очень долгой
МИНИМАЛЬНОЕ пустое место на дисках 30%
PS зачем нужны услуги интеграторов хорошо видно на примере покупки серверов.
По первых, сервера не покупаются по принципу больше мощей, быстрее работает.
Как можно было забить диски VSAN до емкости в 70% всего за месяц? Вы там планирование вообще что ли в перед не смотрите?
Грамотный интегратор загнал бы все ваши данные по использования сервисов, посчитал нагрузку, посчитал планируемый рост, собрал аналитику с серверов…
И возможно вы бы вообще купили двух кластерный вариант из 2 серверов в VSAN
С памятью по 256 DDR4 ОЗУ на сервер вы промахнулись в разы, сначала кончается обычно память
Каким образом этот конфиг спас бы от ошибок контроллеров? Две дисковые группы все так же бы сидели на контроллере с багованным драйвером.
От ошибок он не спас.
проблема в том что они взяли не ту конфигурацию оборудования в принципе ( зачем 16 дисков SSD разного обьема ?) и им возможно и не было нужды в покупке контроллера на 16 дисков (P816i-a SR)
Им надо было брать p408i-a в количестве 2 штук и делать 2 дисковые группы
Я как-то тоже столкнулся с такими же проблемами на кластере vSAN, на сфере 6.5 из 5ти нод. И все там с сайзингом было верно чуть более чем полностью. All-flash, несколько дисковых групп, правильный размер кэш-дисков, заполненность около 50%. И слабо понимаю как смена рейд-контроллера, на более младший от того же вендора, в данном случае помогла бы. Особенно в свете Advisory от HPE по указанной проблеме:
support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00071158en_us
Проблема охватывает конкретную версию микрокода и драйвера в ESXi для большого набора raid-контроллеров. Смотреть «Hardware Platforms Affected».

Можно спросить: а вы из какого-то интегратора? Если да — то не скажете из какого?
Мы с Урала и работаем только по Уралу.
Я сертифицированный инженер по vmware
А толку было бы, если бы было два или три стораджа с одинаковой багой — это как грохнуть об пол дисковую полку, а потом, когда контроллер выплюнет один диск, сказать «пофик, тут же рейд!».
Не буду использовать всё доступное пространство ради «хотелок» бизнеса, буду начинать «ныть» о покупке новых «хранилок» сразу после того, как останется менее 30% свободного пространства на всех доступных «железках».
По личному опыту знаю, что после подобных ситуаций решения по таким вопросам примается оперативно и положительно.
UFO just landed and posted this here
По личному опыту знаю, что после подобных ситуаций решения по таким вопросам примается оперативно и положительно.

— Недостаточный опыт.
В контексте — (с) «Денег нет, но вы держитесь»…
иногда дешевле и надежнее (чем vSAN) просто проверенный сервак с толстыми дисками в массиве, которые отдаются по NFS на несколько гипервизоров.

Насколько я понимаю вы осваивали вполне приличный бюджет.
Стесняюсь спросить, почему вы решили применять vSAN, а не купили для VM внешнее хранилище (из той же серии MSA)?
Все же vSAN на мой вкус, это больше об экономии. А внешнее аппаратное хранилище совершенно другой уровень и даже с точки зрения архитектуры красивее.
В нашей компании мы поигрались с vSAN (они тогда только появлялись 2014 год) и в итоге пришли к связке (вычислительные кластеры для отделений и небольших компаний) корзина + схд ( c3000(7000) + msa). С тех пор вообще забыли о проблемах с данными.
ps схд hpe звучит исключительно на фоне того, что исторически мы его используем. На рынке немало игроков и решений в этом сегменте.

Скорее не экономия, а более эффективное расходование средств. Денежных и человеческих. Сегодня модно гиперконвергенция и commodity железки.
Ну смотрите — entry-level аппаратная СХД это, с точки зрения эффективности, дополнительное место в стойках; с точки зрения производительности — боттлнек в лице ее контроллеров; с точки зрения надежности — все те же контроллеры. Если брать более дорогие СХД (Compellent, XtremIO) и смотреть внутрь — там тот же SDS на general-purpose железе. А если это обычное железо, зачем переплачивать?
Автору не повезло с прошивкой — факт. Но, если вспомнить, и у СХД от HP бывали проблемы и похуже — году в 2011 мне сотрудник HP рассказывал о баге в прошивке HP EVA, приводящем к полному уничтожению всех данных на СХД.
Мы у себя используем SDS и от VMware, и от EMC — при правильном построении системы, в том числе выборе версий прошивок — никаких проблем уже года три, при этом клиентам спокойно отдаются сотни тысяч IOPS, и все это за ценник в несколько раз ниже чем при наличии отдельной СХД, не говоря уже о плотности.
Не хотелось бы холиварить без дополнительных цифр. Достаточно яростных веток можно найти и на реддите, и на самой варе, и еще в куче мест.

По мне, так ваш первый абзац, это несколько ad hominem. Здесь такая история, что нужно конкретно указывать, что там за, например, бутылочное горлышко у контроллеров аппаратных СХД и почему его нет у контроллеров серверов, иопсы, пропускная способность, отказоустойчивость, удобство мейтенса, найтли сервисы и далее по списку… обо всем нужно говорить конкретно и с циферками. Ну иначе можно договорится черт знает до чего. Ну и также говорить о том, сколько кушает ресурсов vsan, сколько стоят лицензии и насколько удобно среднему администратору ловить в нем блох.

Мы достаточно много времени провозились с vsan и больше не хотим. Ну вот для нашего банка оказалось, что практически всегда vsan проблемнее, медленнее и неудобнее при прочих равных (а порой и не дешевле). Пенальти в юниты и дополнительные деньги нас не пугают.

Для других ребят все может быть с точностью до наоборот.

Мне понравилось.
Спасибо за интересную и типичную историю из наших трудовыебудней.
Всегда бывает что-то не так.
Всегда принимаем решения, за которые через 2 года самому стыдно.
Всегда документируем.
И всегда не опускаем руки.


Это наше человеческое ИТ.

Замечательная статья

Я тоже « поигрался с vSAN“. Мода была. Практически все производители обещали « манну небесную». Особенно старались Cisco маркетологи.

3 месяца различные системы тестировали. HPE и Dell/ EMC отвергли первыми. Потом отказались и от Cisco.

Уберёг Господь.

Пошли по пути Упрощения. Добавили новых хостов в VWware и докупили ещё одну внешнюю СХД. Классика.

При выборе нового железа тоже остались у проверенного производителя. Fujitsu. Люблю их сервера. Работают как « калаш». И сервис отличный.

Дополнительная СХД работает на FC, свободные порты на Brocade были. Тоже классика. И свободу манёвра даёт.

Хоть и не « модно», зато надежно. Принцип « Калаша». Ещё со времён службы использую.
Спасибо за статью. Не поймите неправильно, но так и возникает вопрос, почему вы не перевели небольшую часть инфраструктуры на новое железо и не проверили в течении скажем месяца, что все работает нормально?
UFO just landed and posted this here
после опыта работа в дц, оборудование hpe это последнее, что я стал бы покупать для нужд бизнеса

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


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

  1. Хотелось бы увидеть скрин с 1.98 версией, что был рекомендован, прям интересно, куда делся.
  2. Подскажите как были сгруппированы диски в каждом сервере если были 8 SAS 800GB, и 8 SATA или SAS(?) 1,92TB.
  3. Не корректно подобрана спецификация всего кластера, раз туда планировалась миграция всех нагрузок из продуктивна. ( Нужно было не экономить на лицензиях VMware, и воспользоваться услугами интеграторов, в том числе консультацией и настройкой).
  4. Так как поддержка была 8*5, то VMware был куплен в прямом канале, значит кейсы должны были одновременно быть открыты и в НРЕ, и в VMware.
  5. С практики, мне мало вериться, что НРЕ бездействовала или отфутболивала Вас, укажите какой уровень суппорта был приобретен, или была просто гарантия?
  6. Наличие нового драйвера или firmware даже если они есть, является внутренней информацией Вендора, и ее никто бы Вам не донес, тем более в форме — у нас есть, но мы не дадим. В первую очередь был бы предложен вариант отката на предыдущие стабильные версии.
  7. Почему Вы не указываете партномера НРЕ дисков, или вы брали их не в НРЕ канале?
1. Не знаю, куда делся, год прошел. Да и не сохранял я специально скрины. Представляю, сижу я такой с «лежащими» сервисами организации, и думаю, надо срочно собирать доказательства, делать скрины, писать сценарий, который я буду использовать в качестве отмазки и перевода стрелок т.д.
У меня сохранился лишь скрин iLO, с установленными на тот момент компонентами из образа SPP, включая и прошивку контроллера. Вот вырезка:
image
2. Это не имеет значения с точки зрения возникновения проблемы.
3. Это тоже не имеет значения.
4. Кейсы были открыты и там и там, но ответы от HP меня, как клиента, вообще не удовлетворяли.
5. Это ваше право, если у Вас была такая проблема, и у поддержки был иной подход, что ж, могу вам только позавидовать.
6. Не нужно утверждать категорично, все мы люди и у каждого есть знакомства и разного уровня «инсайд». У нас простая гарантия, но право, какая разница, с точки зрения закона о защите прав потребителя, все эти бумажки, подписанные со второй стороной регламентируются законом, и не стоят и выеденного яйца если идут с ним вразрез, пусть скажут спасибо, что у нас появилась информация о существовании данной прошивки, иначе мы вернули бы оборудование взад и потребовали бы вернуть деньги.
7. А зачем? Проблема была связана не с дисками. Я предоставил данные о них, потому что они были «под рукой» и для общей информации.
Не знаю, как у Вас в стране, но в нашей стране, не важно какой Вендор, Dell EMC, HPE люди в продакшн, тем более на 4-х процессорные серверы, приобретают дополнительную расширенную поддержку, это делают для того, что их заявки быстро и качественно обрабатывались, или были подключены самые лучшие специалисты с разносторонним опытом, которые дают дельные советы. В вашем случае нужен сервис Proactive Care CTR HPE, Dell ProSupport Plus 4h MC.
Или толковый интегратор под боком, который разбирается и в «железе», и в софте, его оптимальных настройках.
Подумайте, чтобы заключить договор с таким интегратором, во избежание в будущем подобных ситуаций. Жаль что у вас был такой опыт, надеюсь Вы сделаете ещё выводы, кроме тех что указали в публикации.
Спасибо за ваш отзыв. К сожалению, я не существую в вакууме. Также не считаю себя гуру в технологиях VMware. Поэтому, когда это случилось, оперативно были подключены лучшие знакомые, которые были у нас на тот момент среди интеграторов и специалистов аутсорсинг компаний для решения проблемы. И все они в итоге развели руками. Единственные, кто реально помогли, это специалисты VMware.

Да товарищ судя по всему из мира где живут только пони, которые питаются радугой какают бабочками.
Спасибо что поделились опытом и болью, сам проходил через такое, 12 филиалов 24/7/365 и всё лежит, такое не забываешь и самоё главное это опыт который при правильном использовании делает из "обезьяны" хорошего профессионала, а факапы бывают у всех, даже Яндексы с Гуглами и Амазонами лежат не смотря на все контракты и кучу специалистов ) Тем более когда идёт связка железо — драйвер — гипервизор, тут никто не застрахован, и кластеры тут не помогут кмк, вы будете скорее всего их делать на идентичном железе

хорошая статья, но не понял куда старый рабочий кластер делся после переноса…
Чуть выше уже отвечал на похожий вопрос.
Клауды — это просто та же самая инфраструктура, только в чужих руках
именно, в чужих, квалифицированных руках.

С квалификации как повезёт. Вернее 100% SLA никто не даёт, а сколько реально окажется девяток можно узнать только постфактум

Облака уже много лет в проде. Можно взять статистику по отказам того же Амазона. По памяти, основные сервисы(EC2, S3, RDS, networking) отваливались аж пару раз на несколько часов.

Клауды идут глубоко лесом.


Во-первых, они раздуют бюджет автора раз в 5-10.
А во-вторых, там вообще нет персонала, чтобы разрулить то, с чем столкнулся автор.
А если и есть, то ещё раз см. пункт первый.

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

Как правильно заметили выше, практика показывает, что она другого мнения.

Какая практика? Единичные громкие случаи? Облака это огромная отлаженная инфраструктура, в которой тысячи клиентов болтаются одновременно. Это несравнимые условия против офиса, который себе 3 сервера поиграться купил и словил баги молодой платформы, строя свой сторадж с нуля.
Да мне тоже весело, что народ минусы в карму ставит, а сказать толкового ничего не может. Только выдумывать сказки, что своя инфраструктура надежнее облака.
Как показывает обширная практика, Клауды на 100% выполняют только одну функцию — перевод CapEx в OpEx, все остальное — как повезет
Единичные громкие случаи?

Ну так описанный автором случай тоже подходит под описание единичного.
Причем фейл случился не из-за криворукости ТС, а полноценный факап «огромной отлаженной ВМвари» в том что в список рекомендуемых ими прошивок попала нерабочая версия (если автор не врет). Но и респект им за то что бросили своих специалистов на решение этой проблемы.
в которой тысячи клиентов болтаются одновременно

При наборе определенной критической массы это начинает работать в обратную сторону. Не так давно же была тут же новость как робот ютуба снес кучу пользовательского контента. Из реакций — ну сорян, ошиблись ¯\_(ツ)_/¯. Вы готовы поставить свой продакшн бизнес в подобное облако?
Конечно если вы клиент уровня условного Газпрома с сотнями тысяч арендованных мощностей и многомиллионными контрактами на саппорт в течении 5 минут — да, облако сможет подключить к вам специалистов самого высокого класса и поставить на уши полдолины, о которых при самосборном решении вы не можете даже мечтать. Но если вы обычный вася с тремя серверами — максимальным уровнем саппорта будет являться почтовый робот-автоответчик. И в ситуации как у автора это будет проблемой
несмотря на наши увещевания об отказе от ответственности и всё такое, мол нам главное решить проблему с хранилищем и всё.

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

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

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

Сказки, не сказки, cloud vs standalone это холивар почище intel vs amd и у каждого своя правда и свое решение по какому пути пойти. У облаков миллионы плюсов по гибкости и масштабируемости, но фейлы бывают у всех и FAANG не исключение.
Все таки давайте более релевантные примеры. В AWS были потери данных по вине провайдера?
Все таки давайте более релевантные примеры.

А чем пример с ютубом неревелантнен? Пользовали доверили свой контент облаку. Причем не какому-то там Айхору, где по желанию левой пятки директора могут обесточить цод, а вполне себе гуглу. Гугл их контент по ошибке снес. Чем отличается видеоконтент который точно так же монетизировался и приносил доход владельцам от какого-нить магазина на вордпрессе в амазоне мне не очень понятно.
Ну или Яндекс который полгода назад зафакапил 0.77% клиентских машин.
В AWS были потери данных по вине провайдера?

Да. Со смешным SLA в виде мы вернем вам деньги за объем потерянных данных по 3 цента за килограмм
Пользовали доверили свой контент облаку.

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

Еще один нерелевантный пример, и то менее 1(!!!)% пользователей поимели проблемы.
Да. Со смешным SLA в виде мы вернем вам деньги за объем потерянных данных по 3 цента за килограмм

Но вот почему то
а) треть интернета у них хостится и доверяет SLA
б) случаи факапов — очень редкие и многомиллиардные бизнесы, соглашаются на такие SLA.
в) Uptime гарантированный SLA в разы выше теоретически возможного аптайма своего датацентра
г) судя по приведенным примерам вы совершенно не в теме.
и то менее 1(!!!)% пользователей поимели проблемы.

Простите, после такого заявления, дискутировать с Вами, смысла не имеет.
Да вам ответить попросту нечего, вот и приделались к тезису, который вам не понравился. Проблемы происходят регулярно по разным причинам и некоторые из них докатываются до пользователей. Но ни в одном частном датацентре вы не получите гарантий надёжности хранения данных с вероятностью в 99,999999999 % и доступностью в 99,99 % в течении года, как предлагает S3 к примеру.
А если попробуете — то это будет стоить столько денег, что никакой бизнес не потянет.
Вы серьезно сравниваете
и то менее 1(!!!)% пользователей поимели проблемы

и
гарантий надёжности хранения данных с вероятностью в 99,999999999 %

?
Кстати, где Вы последнюю цифру взяли?
Разница, как бы в миллиард раз… Это как Луну с Черной Дырой перепутать. Первая цифра с трудом подойдет для фотографий котиков. Вторая вряд ли вообще достижима и, как минимум неизмерима.
Вы не понимаете, что ваш пример яндекса совершенно нерелевантен моему примеру Амазона? Для вас все клауды и все сервисы — одинаковые? Я вас разочарую, это не так. Не надо смешивать все в одну кучу и говорить, что «раз у яндекса все плохо, то и у всех остальных тоже». Цифру для S3 вся вот тут aws.amazon.com/s3/faqs/?nc1=h_ls
Повторюсь, пожалуйста не спутайте ее с яндексом, это совсем разные компании и сервисы!
Это не мой пример. Это Вы к фразе «менее 1%» три восклицательных знака поставили. И одиннадцати девяток я по приведенной вами ссылке не нашёл. Максимум четыре (доступность).
И поверьте, доступность в четыре девятки вполне достижима в частном датацентре.
Это не мой пример. Это Вы к фразе «менее 1%» три восклицательных знака поставили.

Не ваш, пример яндекса привел выше по треду 3й человек. Отмотайте выше для контекста.
И одиннадцати девяток я по приведенной вами ссылке не нашёл.

Держите картпнкой, если у вас с Ctrl-F все плохо.
monosnap.com/file/RijPoespb9i3bY8v8McKL8NRzSsvgZ
И поверьте, доступность в четыре девятки вполне достижима в частном датацентре.

Меньше часа даунтайма в год, по честному? Сколько это будет стоить?
Меньше часа даунтайма в год, по честному? Сколько это будет стоить?

На уровне хранения данных, легко. У нас хранилки EMC. За 13 лет поменяли CX3 -> CX4 -> VNX5200.
CX4 была когда то сертифицирована на пять девяток. По вине хранилок даунтайма не было ни разу. Миграции, обновления — всё на лету. Один раз электричество отключалось, один раз VMWare сглючило — датасторы переименовала. Но суммарная недоступность за 13 лет — часа 4. А они ещё и реплицируются на другой ЦОД…
А сколько у вас железяк было и сколько данных хранили?
Петабайт для крупной корпорации — немного, а тут уже на статистике начнутся приключения…
Данные доросли до 40Тбайт примерно. Две хранилки — по одной на площадке. Между ними репликация. Официальная поддержка. Для бОльших масштабов есть свои решения. Петабайт, в принципе, можно и в midrange систему засунуть, но надо смотреть на производительность. Статистика на больших масштабах только помогает :-) Ну воткните больше hot spare дисков. Примените Raid6 вместо Raid5. Есть системы с бОльшим (чем два) количеством контроллеров… Можно High End систему рассмотреть, там и контроллеров больше, и на большие объемы она лучше рассчитана. То есть с точки зрения надежности, чем крупнее, тем лучше, потому что есть, где с избыточностью развернуться. Другое дело, что и цена то же растет, и с переходом на high end — сильно растет, и где то окажется программно определяемый storage оптимальным.
Цена железа растет, цена поддержки растет, диски начнут вылетать… и получается что с клаудом гемору меньше, надежней и быстрей.
Где то получается, где то не получается. Где то бизнес хочет опексную систему, где то капексную. Где то безопасники против, где то вообще канал в Интернет слишком узкий (попробуйте петабайт в облако залить). Каждый конкретный случай надо считать отдельно, и деньги и риски. Учитывая максимально всё от скиллов сотрудников до киловаттов и климата на улице и американских санкций. Вряд ли кто то пойдет мигрировать свой петабайт в облако потому что Сергей Прокофьев сказал на Хабре, что это круто.
Скажем так, действительно уникальных бизнесов не так и много. Точней каждый клиент, с которым я работал был уверен что у него супер уникальная специфика, которой ни у кого нет. А на самом деле, оказывалось что это немного не так. Ясна ж есть везде своя специфика, под которые нужно рихтовать типовые схемы. И есть тараканы в голове, что «Амазон узнает супер уникальный список клиентов Васи Пупкина Ltd и сольет их конкурентам», «Амазон теряет данные» и тд и тп.
Безусловно, есть сферы, в которых есть реальные ограничения на только все свое, но сколько их на рынке?
где то вообще канал в Интернет слишком узкий (попробуйте петабайт в облако залить)

Ну конечно же никто об этом не подумал, там же одни идиоты сидят :)
aws.amazon.com/snowball
Это вы серьезно?
Нашему проекту уже полгода. У нас зарегистрировались более 22 000 пользователей.

Вы вот это поделие сравниваете с амазоном? Ну что вам сказать, не все клаудные провайдеры одинаково надежны, капитан очевидность.
треть интернета хостится в амазоне. При таком масштабе говорить о «проблемах в клаудах» смешно.
Треть интернета, если не больше, накуй никому не вперлась. Сдохнет — никто и не заметит. А свое, родное, если сдохнет — начальство все кишки вымотает, хорошо, если не прибьет, за потери. Вы не путайте сервисики, сайтики от гугля, микрософтика и других новомодных смузихлебо-говнокодеров и корпоративные сервисы.
Вот в том то и дело, что овердофига всего всякого ентерпрайза в клаудах и мигрируют туда дикими темпами. Вот зовут помочь смигрировать полностью бизнес одной healthcare компании, 800 приложений самых разных.
У тогоже Майкрософта офис365 хостится… правильно в ажуре, а уж на него сколько разного бизнеса завязано.
Нетфликс полностью в амазоне.
Вы просто не представляете масштабов.
Мигрируют «оттуда» еще более дикими темпами. Достаточно один раз обжечься и развести руками в стороны перед начальством. Мол нифига починить не можем, проблема у гребаных провайдеров. На Офис365 завязываться может не Бизнес, только разве что «бизнесишко». Не спорю может таких больше чем «БИЗНЕСОВ», но важно СВОЕ, а не чужое. Нетфликс — всего лишь доставщик контента. Еще раз, не путайте «сервисики» и КОРПОРАТИВНЫЕ ПРИЛОЖЕНИЯ.
У вас плохо с пониманием написанного текста? Я же прямо говорю: миллиардные бизнесы массово мигрируют свою ИТ инфраструктуру в клауда уже многолет. Потому что так гораздо надежней и зачастую дешевле. Это именно корпоративный софт крупного ентерпрайза. Если в вашем селе не так — подождите пару лет, и до вас тоже волна докатится. Амазон активно осваивает российский рынок.
Назвать крупнейшую медиа фирму мира, c чистой прибылью в почти 2 ярда баксов, снимающей огромное кол-во фильмов и сериалов «всего лишь доставщиком контента»… ну я не знаю.
Не надо «прямо говорить» — Ваше понимание «миллиардных бизнесов» ниже плинтуса. Трепать языком — не мешки ворочать. Не надежнее и не дешевле — это однозначно.
Закончим на этом, у Вас понимание Бизнеса на уровне менеджера, которому надо «подешевле», а там хоть трава не расти.
Слишком толсто либо слишком глупо. Ознакомьтесь с aws.amazon.com/solutions/case-studies/?customer-references-cards.sort-by=item.additionalFields.headline&customer-references-cards.sort-order=asc&awsf.customer-references-location=*all&awsf.customer-references-segment=customer-segment%23enterprise
потом найдите тут www.contino.io/insights/whos-using-aws список самых крупных пользователей амазона.
В общим, повторюсь, уровень надёжности и отказоустойчивость Амазона недостижим в вашем колхозе принципиально. Может так дойдет.
Надо тогда держать в нескольких датацентрах, в идеале еще и на разном наборе софта чтобы они работали, в этом случае, к примеру, особенности поведения амазоновского софта будут компенсироваться особенностями поведения гугловского софта. А с поправкой на РосКомТогоКогоНельзяНазывать, надо один экземпляр держать на территории РФ, на случай особенностей сетевой маршрутизации.

Это увеличивает объемы оплаты в 2-3 раза, дополнительно головняки тому, кто это всё дружит между собой и заставляет работать. Зато надёжность — да, довольно неплоха.

Пример, почему нельзя доверять только одному датацентру:
Удар молнии, попавший в один из центров обработки данных Google в Бельгии, уничтожил часть содержавшейся там информации. В результате некоторые пользователи безвозвратно потеряли доступ к своим файлам.
www.bbc.com/russian/international/2015/08/150819_google_lightning_data
>>Во-первых, они раздуют бюджет автора раз в 5-10.
В 500-1000, что уж стесняться!
UFO just landed and posted this here

Я не в курсе, это не ко мне вопрос.
А про розовых пони здесь уже писали...

UFO just landed and posted this here
А стоило так убиваться с неделей почти бессонных ночей, если это косяк вендора? Не приходили мысли, что коллеги из поддержки VMware были правы и «война войной, а обед по рсаписанию»?
ну, что тут скажешь, я держусь за свое рабочее место…
Интересно, хоть кто-то из бухгалтеров так же держится?
Думаю, они готовы к сверхурочным только под угрозой уголовного дела :)

Не знаю как вообще, но за клиента (или работодателя) держишься ибо он денюшку платит, и будешь если нужно и неделю сидеть без сна и отдыха.

Это локальная, чисто московская «фишка» и вредит она просто всем (кроме собственников, наверное). Может пора уже перестать играть в дикий капитализм, выгляните в окно — уже давно проехали эту станцию.

Какая такая фишка? Есть клиент (работодатель) который платит за то, чтобы у него все работало как часы и судя по всему не самый скупой в плане покупки железа для бизнеса. Есть исполнитель работник(аутсорсер) которому тоже нормально платят каждый месяц за работу(прямо скажем не всегда пыльную), случился форс-мажор, всё встало наглухо, ваши предложения?
После 7 часов разбирательство, позвонить собственнику бизнеса и сказать, что мол извините, но я так работать не буду, решайте свои проблемы сами? У меня например для бизнеса который работает 24/7 коэффициент на стоимость +80%, и да бывает решаем проблемы и в 5 утра и в 20:00 31.12, но это бизнес, не будешь решать эти проблемы ты, будут решать их другие, ничего личного просто бизнес ))

С коэфицентом за овертайм согласен, но про это речи не было в посте, да и не аутсорсер вроде ТС. Я так понял что у него рабочий день внезапно стал ненормированным без увеличения компенсации, до устранения проблемы. Вот это имхо неправильно и мириться с таким фу-фу. Если всё было не так, а по обоюдной любви — пардон.
Не знаю кто там куда «проехал» но спальники в War Room весьма крупных компаний у SRE я видел и в Европе и в Штатах.

Да они получают больше, чем разработчики зачастую, но их и в выходной могут дёрнуть и они могут несколько дней на рабочем месте провести… Не каждый месяц конечно — ну так и автор статьи этим развлекается реже раза в год…
Вот поверьте, директору вообще пофигу на хпе-шмэпе, вмваре всякое, ему надо чтобы бизнес крутился и работал, а не чтобы к нему с матом нёсся главбух с идеей «повесить этих уродов из IT, у нас сдача квартальной отчётности и всё сдохло».
А объясни бизнесу почему тебе вот 5 Лямов дали, а оно не работает. Ты же просил. Сказал будет хорошо, а оно не хорошо. И мало кого волнует почему. А там ещё затраты от простоя.
Рядом с этим кластером поднимите 2ноды е3(типа 1271) на бесплатном проксмоксе и перебросьте туда бд и 1с. И Вы поймёте, что в 2020году (для задач, связанных с бд) по прежнему рулит частота проца, а не ядра.
Благодарю за то, что поделились реальной историей из реальной жизни. Потому как стандарные «истории успеха» читать тут уже поднадоело.
PS А HPE (которая раньше была известна как просто HP) мне всегда не нравилась своими шибко хитрыми подходами: использованием несовместимой со стандарной комплектухой начинкой серверов, постоянной увязко обновления прошивок с обновлениями драйверов и т.п. привычками поставщиков двора Его величества AKA «enterprise level».
Потому я всегда был сторонником закупки вместо пары серверов HP 3-4 серверов локальных сборщиков за те же деньги, одному из коих было предназначено быть в теплом резерве (с использованием его в качестве «песочницы» для поиграться и т.п.).
Вместо (в сумме) 12 процеccоров Intel® Xeon® 8164 по 26 ядер можно было б купить ~15 64-ех ядерных Threadripper 3990X…
Ну или ~30-40 32-ух ядерных threadripper'ов 3970x))

Жаль что на момент покупки ваших серверов наверное они еще не вышли :(
UFO just landed and posted this here
Тредриперы — это не серверные процы, а для рабочих станций.

А что вы вкладываете в это понятие? Чисто технически:


  • один тредриппер 3990X заменяет по количеству ядер 2 Xeon 8164 + ещё 8 ядер;
  • частота гораздо выше;
  • L3-кеш втрое больше;
  • поддерживает ECC DDR4 как и Интел (правда памяти втрое меньше).

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


P.S: Я не фанат ни красных, ни синих.

UFO just landed and posted this here
Чисто технически же — максимум один процессор.

А зачем два если один мощнее двух?) По сути мало что топовую десктопную линейку отличает от серверной, кроме поддержки связи между камнями. Но ведь межпроцессорная связь медленнее чем внутрипроцессорная. Поэтому я вижу одни только преимущества.


Но если кто подкинет мне вариант шаси под него с двумя бп (с HOT SWAP, естественно), то было бы интересно)

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

Два потому что места в стойке ещё меньше займёт(и надо будет жидкостную или фреоновую систему охлаждения изобретать гыгы).
UFO just landed and posted this here
Эксплуатирую 2 vsan кластера суммарно на 11 нод. Лет семь назад попадал в похожую ситуацию с массивом HP EVA 4400(падал на ~12 часов, проблема была в прошивке доп. полки, смог вызвать инженера через сейлов, поддержки не было). Сейчас vsan(кстати, как вы базовую поддержку купили? её уже в прошлом году уже не продавали.) и сервера на поддержке, регулярные резервные копии, все боевые сервера реплицирую veeam несколько раз в день на выделенный сервер набитый жёсткими дисками.
Вот поэтому я и не люблю отказоустойчивость на уровне виртуализации.
Стройте отдельные отказоустойчивые решения — у MS SQL и Exchange (да и другого серьезного ПО) есть отличные средства для этого. Это конечно сложнее, но более надежно.
Отдельное, несвязанное друг с другом (т.е. не имеющее единой точки отказа) железо, хранилки, минимум 2 провайдера, а в идеале — отдельное электропитание и ИБП, отдельный ЦОД.

Из описания мне показалось, что:


  1. SSD с целью экономии закупались не у HPE
  2. От HPE была только стандартная гарантия на сервера, какие-то доп. контракты на поддержку не заключались?

Так ли это?


В итоге, проблему удалось окончательно решить лишь через три месяца, когда вышла версия прошивки 1.99 для контроллера дисков!

А почему даунгрейд прошивки не сделали-то? Зачем 1.99 ждали?

Бизнес у HP ничего не закупал. Все железо приобреталось у разных дистрибьюторов, ООО и т.д. Но на все есть гарантия. Доп. контракты на премиум поддержку не заключались.

А почему даунгрейд прошивки не сделали-то? Зачем 1.99 ждали?

Потому, что инженеры VMware в рамках кейса не давали такой команды. Но пробовали устанавливать разные сборки драйверов.
Возможно, что на тот момент никто не знал, какая из предыдущих прошивок не страдала таким багом. Железо то новое. Но если верить, что прошивка уже была создана в виде беты, то значит баг уже был ранее обнаружен, или кто-то с похожими симптомами сталкивался и открывал кейс (надеюсь, не критическая инфраструктура страдала), и все ждали, поскольку дальше все зависело от бюрократии.

:). И так понятно, что покупали не напрямую у HPE, а через партнеров. Ок, переформулирую. Вот квикспек вашей модели сервера — https://h20195.www2.hpe.com/v2/GetDocument.aspx?docname=a00008181enw. Там в разделе Core Options — HPE Drives перечислены модели совместимых дисков. Те, которые вы купили — из этого списка? Или просто куплены на стороне, потому что дешевле?

На дисках написано HPE, это всё, что я знаю. С разделом Core Options я не знакомился.
Мыши плакали, кололись, но продолжали кушать хардварный рейд.
VMWare очень давно прописывает популярный туристический маршрут любителям софтового рейда, конечной точкой которого является очень знаменитая горная вершина в Перу. В этот-же самый маршрут она посылает тех, кто пытается поднять всё это дело на старых проверенных аппаратных рейдах.
Комментарии из личного опыта и попытка развеять некоторые иллюзии у коллег.

Мы решим программные проблемы «железными» методами:
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, в чем проблема»?

Итого – имя вендора/интегратора вообще ничего не значит в реальной жизни, если ты сам не понимаешь, что и как будут внедрять. Криворукий установщик может «убить» грамотно проработанное решение. Безграмотный архитектор может «напроектировать» такое, что самый замечательный инженер не сможет заставить работать.
А поделитесь, пожалуйста опытом, поддержка DELL (IBM, cisco, lenovo и т д) то же в таких случаях на фиг посылает? Или как то всё-таки пытается помочь?
40G в 10G гидры это те самые красавцы «4 в 1»?
Да, с одной стороны 40G QSFP+ с другой 4 SFP+ по 10G Breakout-кабель. Используются для «нарезки» 40G порта с коммутатора на 4 линка по 10G.
Если есть контракт на поддержку, то «посылать» для вендора проблематично.

Качество поддержки зависит от конкретного человека «с той стороны» или возможности на него выйти через заслоны 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 (он был только на одном хосте в кластере!) и все заработало.
ну Dell\VMware не просто так пропихивает свое решение — VxRail… перед каждым обновлением — все неоднократно тестируется и проверяется, кроме того — обновления идут паками: vSphere совместно с firmware для железа. а еще — для vSAN рекомендуют использовать all-flash конфигурации и контроллеры дисков только из списка рекомендуемых… мы когда мигрировали на VxRail первым делом настроили непрерывную репликацию на старое оборудование, одновременно с бэкапом (так как первое это не про сохранность данных).
Когда заказчик видит две (вроде бы) одинаковые железки — Dell EMC VxRail и «точно такой же» сервер Dell vSAN ReadyNode по цене отличающейся в три раза — у него из ушей начинает валить пар, лицо краснеет и он начинает возмущаться, что его здесь пытаются развести.

Готовые решения, подобные VxRail, удобны, обычно имеют упрощенный единый интерфейс развертывания и управления, но стоят как самолет и (опять-таки) не гарантируют 100% защиты от проблем с прошивками и обновлениями. Да, все тестируется и накатывается в комплексе, но всегда найдется уникальный случай у заказчика, факапер-тестировщик у производителя или админ «шаловливые ручки».
1. Брендовое железо от HP в нынешних отечественных реалиях, когда завтра, напр., HP рискует вообще уйти из РФ и полностью прекратить поддержку? Вполне реальный сценарий. Ну, ОК.
2. Vmware? Прошу сильно не бить, но почему не KVM в кач-ве системы вирт-ции + Ceph? Мало будет Proxmox VE — пользуем Opennebula.
По второму пункту вопрос, конечно интересный.
Осталось только решить вопросы с горячей миграцией машин как по хостам, так и по стораджам.
Ну и придумать как делать бэкап. Горячий. Инкрементный по измененным блокам на дисках виртуалок.
А, да, еще это должно поддерживаться не уникальным специалистом, который внезапно едет в отпуск, а быть типовым решением.
Вы считаете, что умением правильно готовить vSan обладает простая кухарка?
Для этого также необходим специалист, несмотря на то, что vSan — типовое решение.
И специалист не самый «простой».
vSAN это, все-таки, типовое решение. Со стандартной документацией. И специалисты (возможно и дорогие) не уникальны.
И нет того неловкого момента, что цена специалиста по вышеприведенной сборке будет не ниже, чем по решению с vSAN, но понять как это решение построено и почему вообще работает этот специалист не сможет.
Мне приходилось, скажем так, общаться с людьми, от которых ушел очередной (пятый по счету) гениальный админ. И каждый из этих гениев строил инфраструктуру под себя. При этом были в цепочке и и любители Windows, и любители Linux, и любители FreeBSD. И даже знатоки Netware.
С тех пор я очень осторожно отношусь к нестандартным решениям и стараюсь максимально документировать свою работу. Хотя бы ради того, чтобы спокойно проводить отпуск.
1. Назовите хотя бы одного производителя первого эшелона, который не подвержен риску ухода и России. Вам известен хотя бы один сервер, собранный в России из российских компонентов? Сервера Huawei и т.п. с бумажной наклейкой «Сделано в России» не предлагать…
2. А почему компании используют брэндовые серверы HPE/DELL/Lenovo и т.п., а не собирают из «open source» железа свои собственные? Можно же купить вполне приличные компоненты и даже сборку заказать, да еще и дешевле выйдет…
1. Я и не говорил, что в РФ реально производится серверное оборудование. Оно и не может производиться не имея СВОЕЙ микроэлектроники.
2. Да хоть из-за того же ILO\iDrac etc — удобно же. Плюс (якобы ?) более надежные комплектующие, из к-ых собрано брендовое. И да, я пока не видел готовое рабочее решение для удаленного управления «самосбором» (

Но есть и минусы. Напр., в последних поколениях серверов от HP нельзя вот так просто взять и заменить HDD на «небрендовый», т.к. в салазки теперь встроен специальный чип. Что является простым впариванием с огромной накруткой обычных HDD с наклейкой от HP.
А вы не пробовали поискать в продаже такие салазки? Возможно вы удивитесь, но даже есть выбор — взять б/у или китайские. У китайских, правда, качество литья пластика и сборки похуже — не так красиво выглядит.
KVM в качестве виртуализации… да легко, Nutanix завется.
Коммерческая система, поддержкой и обновлениями и тестированием.
А… так это за деньги…

Хотите надежность получайте из за деньги.
Хотите поставьте бесплатный ceph как ростреест, не проблема. Потеряете данные и уголовное дело в подарок.
Не бывает бесплатно и надежно.
Бизнесу требуется гарантии:
что система будет обновлятся
решение вопросов по эксплуатации
надежность
и самое главное… компенсация убытков по простоям.
Готовы подписаться с Opennebula в SLA 99,99% и штрафами 10% от контракта за каждый час простоя? Если готовы… добро пожаловать в большой бизнес.
Давайте не передергивать про потерю данных на Ceph. Такой софт еще и «готовить» уметь надо. Все можно испортить некомпетентностью, каким бы софт «золотым» не был.

Зы. Тот же Proxmox имеет и платную поддержку, к слову.
Тоесть помимо разовой большой платы за железо(в клаудах она размазывается тонким слоем, зачастую выгодней бизнесу), риска ошибиться в объёмах закупки в обе стороны(купили мало — технология не тянет бизнес, много — выкинули баблос вникуда), появляется еще и фактор персонала. Надо найти профи, отличить их от непрофи, мотивировать, платить зарплату, быть готовыми к тому что они могут в любой момент времени уволиться/заболеть/умереть…
Просто прекрасно для бизнеса :)
Просто прекрасно для бизнеса :)

Ага. Куда проще ведь просто выплачивать себе дивиденты, а всю работу переложить на широкие плечи аутсорса. :) Странно, что не все так делают.

Все крупные игроки так делают. Включая майкрософт, эппл, фейсбук, твиттер, гугл и прочих. Не аутсорсят только ядро бизнеса.
А где-нибудь выкладывали, что же именно случилось с росреестром?
Публичных данных нет.
Все на уровне одна бабка сказала.
Пока последная версия событий выглядела как попытка обновить ceph, которая пошла не удачно.
Умные люди говорят что надо параллельно поднадь новую версию ceph и мигрировать данные.
Sign up to leave a comment.

Articles