Comments 182
2.
Мы, со спокойной душой, переместили все виртуальные машины
А вот не надо было так делать. Пара недель нагрузочных тестов вероятнее всего избавила бы вас от этих проблем. Никогда не суйте новое железо/ПО сразу в продуктив, если у вас там критические сервисы, никогда!
3.
DELL, насколько мне известно, приобрела VMware
Ага, ещё в 15-м году, только никакой интеграции дополнительной не было и нет. И у любого вендора могут быть проблемы с прошивками/драйверами, эта проблема не только HPE.
Не HP, а HPE, это 2 разные компании
Спасибо, исправил. В целом, именно термин HPE использовал.
А вот не надо было так делать.
Дело в том, что мы так и делали, сначала десяток незначительных машин крутились в новом кластере пару недель, до Нового года. Все было нормально, потом переместили все остальные. Все веселье началось уже к концу января.
а по поводу «Не буду покупать самое свежее железо! Лучше годик подождать.» — так проблема могла быть и с новыми драйверами на старом железе (SPP накатили ведь).
Подскажите, а почему выбрали...
В целом по ряду причин, основные: а) этот апгрейд на следующие 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ГГц и сравнить.
Ну, например, потому что увеличение количества хостов влияет на время их обслуживания,
Если говорим об обслуживании, то рекомендуется хотя бы 4 хоста. Потому что тогда можно потерять один хост или перевести его в режим обслуживания. Объекты смогут переехать на оставшийся хост и данные будут опять в безопасности (если на дисках место позволяет конечно). А с 3 хостами вывод хоста даже на обслуживание это уже опасно, не говоря о выходе из строя. Плюс FT можно повысить.
Странное конечно такое видение, которое идет вразрез рекомендуемым практикам построения распределенных систем (коей vsan является) и повышения надежности кластера. Ладно бы еще денег было мало.
У данного решения свой «RAID
Не так выразился. Имел ввиду Erasure Coding политики самого vsan.
которое идет вразрез рекомендуемым практикам построения распределенных систем
Почему вразрез?
Сейчас я могу высвободить один хост из кластера для обслуживания. Постепенно, по мере роста числа вм, добавляю RAM, чтобы сохранить эту возможность. Единственное, на что влияет — на производительность. Доступность не страдает.
Да, представители VMware говорили, что нужно три узла, а лучше четыре, но можно и два :). Надолго запомнил эту фразу. Не знаю почему.
Именно для этого вмваре и вообще все, кто занимает распределенными системами, дают одну простую рекомендацию — чем больше хостов, тем лучше. С 4 хостами у вас куда больше свободы. С FT=1 политикой вы можете вывести хост на обслуживание, предварительно эвакуировав с него все объекты. После вы можете пережить выход из строя еще одно хоста. С 5 хостами вы уже можете raid1 с FT=2, что даст пережить потерю двух хостов подряд. Правда с большой платой за дисковое пространство. С 6 хостами благодаря ssd получите доступ к raid6, а это и места нормально, и FT=2.
2 хоста+witness это вообще костыль, который vmware явно со временем прикрутила для упрощения миграции существующих кластеров.
Я когда проблемный узел вижу и эти три волшебные буквы на фоне рыдающего бизнеса, вложившего в эти буквы много денег, мне всегда грустно становится. Самосбор лучше — чесслово!
Самосбор лучше — чесслово!
Была бы возможность прикрутить к самосбору что нибудь вроде iLo, а так, мыши плакали, кололись, но продолжали кушать кактус. Есть Intel vPro AMT, но не везде, лично мне не встречалось.
Ну, это первое, что стоить проверить, но не единственное.
В другом — питается по разным фазам, но расколбаса нет, мониторинг питания даёт идеальную картину по 230В на каждой фазе, земля-ноль тоже идеальные, что по утечке, что по сопротивлению. наводкок нет, но после первого случая заменил UTP на FTP, плюс замерил, не течёт ли ток по экрану — ничего не течёт.
А самая засада, что обычно дело происходит так: через 3-4 года планомерно начинает отваливаться один ethernet, перехожу на второй, на нём глюков нет (если перейти на первый — они сразу появляются), проходит пара-тройка месяцев и второй тоже начинает подыхать, к моменту перехода на 4ый(если он есть) срок работы сокращается до недели. Я даже все электролиты перепроверил по ESR и ёмкости — всё впорядке. Пыли нет, которая там что-то может коротить. Питание осциллографом у чипов смотрел — всё нормально. Диких вибраций — нет. ИМХО остаётся несколько вариантов — либо мне попадались материнки с браком чипов(но их слишком много и они разные, либо мне надо лететь в Лас-Вегас и ставить всё на зеро, т.к. неудачу я выработал, осталась только дикая удача), либо пайка чипов фиговая.
Официального ответа не было, неофициальный «бракованная партия».
а как эта супермикра будет работать с ssd
Работать будет, как правило, не хуже, чем у Tier-1 брендов.
а не серверные варианты за ценники в разы дороже?
В "серверных вариантах" главное не ценник, а рабочие характеристики. Если вы абсолютно точно понимаете, что и зачем вам от SSD нужно и обеспечит ли это вон та дешевая модель — нет никакой проблемы поставить в сервер более дешевый диск. Но тут надо либо разбираться в теме, либо следовать рекомендациям вендора решения, под которое вы берете диски. Причем в большинстве случаев всё равно получится так, что по мере углубления в тему понимаешь верность этих рекомендаций. :)
В случае конкретно 970 Pro надо понимать две вещи — у них нет power loss protection и относительно невелика write endurance. Если их write endurance вам достаточна, то в сценарии "просто офисный сервак с дисками" я не предвижу каких-то проблем с ними. А вот под SDS, как у автора, брать крайне рискованно.
Наоборот — c S2D как раз будет больше потенциальных проблем. Консьюмерские диски если и использовать, то в простых как пробка решениях (типа простого зеркала, и то надо понимать, что в случае SSD вероятность отказа обоих дисков одновременно неиилюзорно выше, чем в случае HDD).
А S2D-кластеры крайне капризны к выбору оборудования для дисковой подсистемы (и если просто не заведется, несмотря на то, что все компоненты в списке валидированных — это еще хорошо, куда хуже, если уже в процессе эксплуатации разъедется).
Но с тех пор самосбором и прочими крафтвяеми я дела как-то не имел Что, с тех пор хуже стало?
Образы вмвари у всех крупных вендоров свои — делл, хпе, леново, вроде бы циско тоже.
Неужели G10 не ставится с чистого образа?
HPE DL360p g10 — esx 6.7 штатный образ без вопросов встал и работает.
Ставил с чистого образа, без пробем
Кстати, после заявления производителя о том, что они перестают поддерживать свое оборудование, я также перестаю придерживаться моральных норм для таких железок на покупку дополнительных сервисов и использую народные средства для открытия полного функционала iLO и т.д и считаю это правильной позицией.
Этот вариант казался единственным, поскольку в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA).
Этот вариант не проще?
Обычно в ERP системах через некоторое время начинает твориться ад и погибель с структуре БД, ибо бизнес хочет вчера, а подумать завтра уже поздно.
Очень часто лезть в структуру БД не даёт производитель софта или их представитель. Физически подключиться к базе и посмотреть список таблиц заказчик конечно может, но вот за попытки там что-нибудь «оптимизировать» могут быть и всякие меры политического воздействия.
Очень часто программист от заказчика умеет только в формошлепство, а за глубокое влезание ручками в систему, могут и по рукам бить.
Программисты от производителя обычно заняты внедрением очередных
Ну или производитель софта просто кладёт болт на некоторых заказчиков, ибо у него параллельно горит исполнение госзаказа в соседней области. В итоге заказчику остаётся только надеяться, что конкретно его баг в его БД всплывет ещё у пары клиентов в других местах, и разработчик соблаговолит исправить его в следующей версии, которая выйдет осенью
Sad but true.
[****@****:~] 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 оно точно есть.
извините за вопрос, а какие документы обрабатываются столько времени и почему так долго?
а какие документы обрабатываются столько времени и почему так долго?
Почему так долго, не могу сказать, честно. А документы — Перепроведение Бухгалтерия 2.0, стандартное закрытие месяца.
бухгалтерия на 1С?
Куча дорогого железа, софта, и всё успешно рухнуло из-за кривой версии обновления прошивки рейд-контроллера.
Потому что вах! на всё про всё было 1 хранилище, аппаратная избыточность которого оказалась бесполезна при логическом сбое в прошивке.
А нефиг иметь 1 единственный сторадж на всё.
А как правильно сторадж конфигурировать? Насколько я знал, рабочий сторадж — всегда единственный. Да, внутри у стораджа — RAID или VSAN, но сторадж один.
Отдельный сторадж — для бэкапов.
Или VMWARE умеет high availability с двумя отдельными стораджами?
Поделитесь опытом
Вы просто тупо накупили дисков и засунули в 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 дисковые группы
support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00071158en_us
Проблема охватывает конкретную версию микрокода и драйвера в ESXi для большого набора raid-контроллеров. Смотреть «Hardware Platforms Affected».
Можно спросить: а вы из какого-то интегратора? Если да — то не скажете из какого?
Не буду использовать всё доступное пространство ради «хотелок» бизнеса, буду начинать «ныть» о покупке новых «хранилок» сразу после того, как останется менее 30% свободного пространства на всех доступных «железках».По личному опыту знаю, что после подобных ситуаций решения по таким вопросам примается оперативно и положительно.
По личному опыту знаю, что после подобных ситуаций решения по таким вопросам примается оперативно и положительно.
— Недостаточный опыт.
В контексте — (с) «Денег нет, но вы держитесь»…
иногда дешевле и надежнее (чем vSAN) просто проверенный сервак с толстыми дисками в массиве, которые отдаются по NFS на несколько гипервизоров.
Насколько я понимаю вы осваивали вполне приличный бюджет.
Стесняюсь спросить, почему вы решили применять vSAN, а не купили для VM внешнее хранилище (из той же серии MSA)?
Все же vSAN на мой вкус, это больше об экономии. А внешнее аппаратное хранилище совершенно другой уровень и даже с точки зрения архитектуры красивее.
В нашей компании мы поигрались с vSAN (они тогда только появлялись 2014 год) и в итоге пришли к связке (вычислительные кластеры для отделений и небольших компаний) корзина + схд ( c3000(7000) + msa). С тех пор вообще забыли о проблемах с данными.
ps схд hpe звучит исключительно на фоне того, что исторически мы его используем. На рынке немало игроков и решений в этом сегменте.
Автору не повезло с прошивкой — факт. Но, если вспомнить, и у СХД от 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 были. Тоже классика. И свободу манёвра даёт.
Хоть и не « модно», зато надежно. Принцип « Калаша». Ещё со времён службы использую.
Возможно стоило в первую очередь заняться оптимизацией кода, чем тотальным и дорогущим апгрейдом железа. Сами же написали:
Этот вариант казался единственным, поскольку в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA)
- Хотелось бы увидеть скрин с 1.98 версией, что был рекомендован, прям интересно, куда делся.
- Подскажите как были сгруппированы диски в каждом сервере если были 8 SAS 800GB, и 8 SATA или SAS(?) 1,92TB.
- Не корректно подобрана спецификация всего кластера, раз туда планировалась миграция всех нагрузок из продуктивна. ( Нужно было не экономить на лицензиях VMware, и воспользоваться услугами интеграторов, в том числе консультацией и настройкой).
- Так как поддержка была 8*5, то VMware был куплен в прямом канале, значит кейсы должны были одновременно быть открыты и в НРЕ, и в VMware.
- С практики, мне мало вериться, что НРЕ бездействовала или отфутболивала Вас, укажите какой уровень суппорта был приобретен, или была просто гарантия?
- Наличие нового драйвера или firmware даже если они есть, является внутренней информацией Вендора, и ее никто бы Вам не донес, тем более в форме — у нас есть, но мы не дадим. В первую очередь был бы предложен вариант отката на предыдущие стабильные версии.
- Почему Вы не указываете партномера НРЕ дисков, или вы брали их не в НРЕ канале?
У меня сохранился лишь скрин iLO, с установленными на тот момент компонентами из образа SPP, включая и прошивку контроллера. Вот вырезка:
2. Это не имеет значения с точки зрения возникновения проблемы.
3. Это тоже не имеет значения.
4. Кейсы были открыты и там и там, но ответы от HP меня, как клиента, вообще не удовлетворяли.
5. Это ваше право, если у Вас была такая проблема, и у поддержки был иной подход, что ж, могу вам только позавидовать.
6. Не нужно утверждать категорично, все мы люди и у каждого есть знакомства и разного уровня «инсайд». У нас простая гарантия, но право, какая разница, с точки зрения закона о защите прав потребителя, все эти бумажки, подписанные со второй стороной регламентируются законом, и не стоят и выеденного яйца если идут с ним вразрез, пусть скажут спасибо, что у нас появилась информация о существовании данной прошивки, иначе мы вернули бы оборудование взад и потребовали бы вернуть деньги.
7. А зачем? Проблема была связана не с дисками. Я предоставил данные о них, потому что они были «под рукой» и для общей информации.
Или толковый интегратор под боком, который разбирается и в «железе», и в софте, его оптимальных настройках.
Подумайте, чтобы заключить договор с таким интегратором, во избежание в будущем подобных ситуаций. Жаль что у вас был такой опыт, надеюсь Вы сделаете ещё выводы, кроме тех что указали в публикации.
Да товарищ судя по всему из мира где живут только пони, которые питаются радугой какают бабочками.
Спасибо что поделились опытом и болью, сам проходил через такое, 12 филиалов 24/7/365 и всё лежит, такое не забываешь и самоё главное это опыт который при правильном использовании делает из "обезьяны" хорошего профессионала, а факапы бывают у всех, даже Яндексы с Гуглами и Амазонами лежат не смотря на все контракты и кучу специалистов ) Тем более когда идёт связка железо — драйвер — гипервизор, тут никто не застрахован, и кластеры тут не помогут кмк, вы будете скорее всего их делать на идентичном железе
С квалификации как повезёт. Вернее 100% SLA никто не даёт, а сколько реально окажется девяток можно узнать только постфактум
Клауды идут глубоко лесом.
Во-первых, они раздуют бюджет автора раз в 5-10.
А во-вторых, там вообще нет персонала, чтобы разрулить то, с чем столкнулся автор.
А если и есть, то ещё раз см. пункт первый.
Но в данной ситуации у автора было перед собой железо к которому можно было подключить специалистов и с кровью, потом и полученным опытом спасти ситуацию.
В облаке вы бы получили отписку от робота что сожалеем, и постараемся больше такого не допускать. Вот вам купон 100р на следующую поездку. Все что выходит за рамки несложного скрипта навряд ли будет рассматриваться.
Как правильно заметили выше, практика показывает, что она другого мнения.
Спасибо, поржал.
Единичные громкие случаи?
Ну так описанный автором случай тоже подходит под описание единичного.
Причем фейл случился не из-за криворукости ТС, а полноценный факап «огромной отлаженной ВМвари» в том что в список рекомендуемых ими прошивок попала нерабочая версия (если автор не врет). Но и респект им за то что бросили своих специалистов на решение этой проблемы.
в которой тысячи клиентов болтаются одновременно
При наборе определенной критической массы это начинает работать в обратную сторону. Не так давно же была тут же новость как робот ютуба снес кучу пользовательского контента. Из реакций — ну сорян, ошиблись ¯\_(ツ)_/¯. Вы готовы поставить свой продакшн бизнес в подобное облако?
Конечно если вы клиент уровня условного Газпрома с сотнями тысяч арендованных мощностей и многомиллионными контрактами на саппорт в течении 5 минут — да, облако сможет подключить к вам специалистов самого высокого класса и поставить на уши полдолины, о которых при самосборном решении вы не можете даже мечтать. Но если вы обычный вася с тремя серверами — максимальным уровнем саппорта будет являться почтовый робот-автоответчик. И в ситуации как у автора это будет проблемой
несмотря на наши увещевания об отказе от ответственности и всё такое, мол нам главное решить проблему с хранилищем и всё.
Когда в качестве последней меры на своей инфрастурктуре можно пойти в пан или пропал и побайтово вытаскивать данные и собирать из них потом машины/стучать молотком по винчестеру надеясь что заклинивший бмг встанет на место — и успешно это восстановить. В случае облака такой возможности у вас не будет даже в теории
словил баги молодой платформы
Ну вообще-то покупая брендовое железо за много миллионов нефти хотелось бы ожидать отсутствия в нем багов. В противном случае проще на Горбушке тредрипперов купить — будет еще дешевле и производительней.
Да мне тоже весело, что народ минусы в карму ставит, а сказать толкового ничего не может.
Ну, не я, без публикаций карма закрыта. Но видать кто-то считает вашу тз сильно ошибочной. Вполне возможно что сталкивался уже с надежностью облаков на личном опыте и сильно после этого пригоревший. Или может просто безапелляционность формулировки «в облаках такого не бывает» не понравилась
Только выдумывать сказки, что своя инфраструктура надежнее облака.
Сказки, не сказки, cloud vs standalone это холивар почище intel vs amd и у каждого своя правда и свое решение по какому пути пойти. У облаков миллионы плюсов по гибкости и масштабируемости, но фейлы бывают у всех и FAANG не исключение.
Все таки давайте более релевантные примеры.
А чем пример с ютубом неревелантнен? Пользовали доверили свой контент облаку. Причем не какому-то там Айхору, где по желанию левой пятки директора могут обесточить цод, а вполне себе гуглу. Гугл их контент по ошибке снес. Чем отличается видеоконтент который точно так же монетизировался и приносил доход владельцам от какого-нить магазина на вордпрессе в амазоне мне не очень понятно.
Ну или Яндекс который полгода назад зафакапил 0.77% клиентских машин.
В AWS были потери данных по вине провайдера?
Да. Со смешным SLA в виде мы вернем вам деньги за объем потерянных данных по 3 цента за килограмм
Пользовали доверили свой контент облаку.
Вы и в правду не понимаете разницы между сервисами, предоставляемыми ютубом и амазоном? Не понимаете какого масштаба бизнесы крутятся в амазоне, не говоря уже о том что можно пользовать их сервисы, не доверяя им данные :)
Ну или Яндекс который полгода назад зафакапил 0.77% клиентских машин.
Еще один нерелевантный пример, и то менее 1(!!!)% пользователей поимели проблемы.
Да. Со смешным SLA в виде мы вернем вам деньги за объем потерянных данных по 3 цента за килограмм
Но вот почему то
а) треть интернета у них хостится и доверяет SLA
б) случаи факапов — очень редкие и многомиллиардные бизнесы, соглашаются на такие SLA.
в) Uptime гарантированный SLA в разы выше теоретически возможного аптайма своего датацентра
г) судя по приведенным примерам вы совершенно не в теме.
и то менее 1(!!!)% пользователей поимели проблемы.
Простите, после такого заявления, дискутировать с Вами, смысла не имеет.
А если попробуете — то это будет стоить столько денег, что никакой бизнес не потянет.
и то менее 1(!!!)% пользователей поимели проблемы
и
гарантий надёжности хранения данных с вероятностью в 99,999999999 %
?
Кстати, где Вы последнюю цифру взяли?
Разница, как бы в миллиард раз… Это как Луну с Черной Дырой перепутать. Первая цифра с трудом подойдет для фотографий котиков. Вторая вряд ли вообще достижима и, как минимум неизмерима.
Повторюсь, пожалуйста не спутайте ее с яндексом, это совсем разные компании и сервисы!
И поверьте, доступность в четыре девятки вполне достижима в частном датацентре.
Это не мой пример. Это Вы к фразе «менее 1%» три восклицательных знака поставили.
Не ваш, пример яндекса привел выше по треду 3й человек. Отмотайте выше для контекста.
И одиннадцати девяток я по приведенной вами ссылке не нашёл.
Держите картпнкой, если у вас с Ctrl-F все плохо.
monosnap.com/file/RijPoespb9i3bY8v8McKL8NRzSsvgZ
И поверьте, доступность в четыре девятки вполне достижима в частном датацентре.
Меньше часа даунтайма в год, по честному? Сколько это будет стоить?
Меньше часа даунтайма в год, по честному? Сколько это будет стоить?
На уровне хранения данных, легко. У нас хранилки EMC. За 13 лет поменяли CX3 -> CX4 -> VNX5200.
CX4 была когда то сертифицирована на пять девяток. По вине хранилок даунтайма не было ни разу. Миграции, обновления — всё на лету. Один раз электричество отключалось, один раз VMWare сглючило — датасторы переименовала. Но суммарная недоступность за 13 лет — часа 4. А они ещё и реплицируются на другой ЦОД…
Петабайт для крупной корпорации — немного, а тут уже на статистике начнутся приключения…
Безусловно, есть сферы, в которых есть реальные ограничения на только все свое, но сколько их на рынке?
где то вообще канал в Интернет слишком узкий (попробуйте петабайт в облако залить)
Ну конечно же никто об этом не подумал, там же одни идиоты сидят :)
aws.amazon.com/snowball
habr.com/en/post/250097
Selectel падал в 2012 году, баг в ядре linux
habr.com/en/post/139368
habr.com/en/post/139368/#comment_4656851
У тогоже Майкрософта офис365 хостится… правильно в ажуре, а уж на него сколько разного бизнеса завязано.
Нетфликс полностью в амазоне.
Вы просто не представляете масштабов.
Назвать крупнейшую медиа фирму мира, c чистой прибылью в почти 2 ярда баксов, снимающей огромное кол-во фильмов и сериалов «всего лишь доставщиком контента»… ну я не знаю.
Закончим на этом, у Вас понимание Бизнеса на уровне менеджера, которому надо «подешевле», а там хоть трава не расти.
потом найдите тут www.contino.io/insights/whos-using-aws список самых крупных пользователей амазона.
В общим, повторюсь, уровень надёжности и отказоустойчивость Амазона недостижим в вашем колхозе принципиально. Может так дойдет.
Это увеличивает объемы оплаты в 2-3 раза, дополнительно головняки тому, кто это всё дружит между собой и заставляет работать. Зато надёжность — да, довольно неплоха.
Пример, почему нельзя доверять только одному датацентру:
Удар молнии, попавший в один из центров обработки данных Google в Бельгии, уничтожил часть содержавшейся там информации. В результате некоторые пользователи безвозвратно потеряли доступ к своим файлам.
www.bbc.com/russian/international/2015/08/150819_google_lightning_data
В 500-1000, что уж стесняться!
Думаю, они готовы к сверхурочным только под угрозой уголовного дела :)
Не знаю как вообще, но за клиента (или работодателя) держишься ибо он денюшку платит, и будешь если нужно и неделю сидеть без сна и отдыха.
Какая такая фишка? Есть клиент (работодатель) который платит за то, чтобы у него все работало как часы и судя по всему не самый скупой в плане покупки железа для бизнеса. Есть исполнитель работник(аутсорсер) которому тоже нормально платят каждый месяц за работу(прямо скажем не всегда пыльную), случился форс-мажор, всё встало наглухо, ваши предложения?
После 7 часов разбирательство, позвонить собственнику бизнеса и сказать, что мол извините, но я так работать не буду, решайте свои проблемы сами? У меня например для бизнеса который работает 24/7 коэффициент на стоимость +80%, и да бывает решаем проблемы и в 5 утра и в 20:00 31.12, но это бизнес, не будешь решать эти проблемы ты, будут решать их другие, ничего личного просто бизнес ))
Да они получают больше, чем разработчики зачастую, но их и в выходной могут дёрнуть и они могут несколько дней на рабочем месте провести… Не каждый месяц конечно — ну так и автор статьи этим развлекается реже раза в год…
PS А HPE (которая раньше была известна как просто HP) мне всегда не нравилась своими шибко хитрыми подходами: использованием несовместимой со стандарной комплектухой начинкой серверов, постоянной увязко обновления прошивок с обновлениями драйверов и т.п. привычками поставщиков двора Его величества AKA «enterprise level».
Потому я всегда был сторонником закупки вместо пары серверов HP 3-4 серверов локальных сборщиков за те же деньги, одному из коих было предназначено быть в теплом резерве (с использованием его в качестве «песочницы» для поиграться и т.п.).
Ну или ~30-40 32-ух ядерных threadripper'ов 3970x))
Жаль что на момент покупки ваших серверов наверное они еще не вышли :(
Тредриперы — это не серверные процы, а для рабочих станций.
А что вы вкладываете в это понятие? Чисто технически:
- один тредриппер 3990X заменяет по количеству ядер 2 Xeon 8164 + ещё 8 ядер;
- частота гораздо выше;
- L3-кеш втрое больше;
- поддерживает ECC DDR4 как и Интел (правда памяти втрое меньше).
В рамках поста мне кажется действительно неплохой вариант. Вендор всё равно оказался не преимуществом. Сложно было бы платформу подобрать в стойку, но по цене всё равно значительная разница.
P.S: Я не фанат ни красных, ни синих.
Чисто технически же — максимум один процессор.
А зачем два если один мощнее двух?) По сути мало что топовую десктопную линейку отличает от серверной, кроме поддержки связи между камнями. Но ведь межпроцессорная связь медленнее чем внутрипроцессорная. Поэтому я вижу одни только преимущества.
Но если кто подкинет мне вариант шаси под него с двумя бп (с HOT SWAP, естественно), то было бы интересно)
Сходу гуглится корпус один и второй. Но если поискать, то можно найти что-то более экономное или просто лучше. Большая башня позволит нормальный теплоотвод поставить.
Стройте отдельные отказоустойчивые решения — у MS SQL и Exchange (да и другого серьезного ПО) есть отличные средства для этого. Это конечно сложнее, но более надежно.
Отдельное, несвязанное друг с другом (т.е. не имеющее единой точки отказа) железо, хранилки, минимум 2 провайдера, а в идеале — отдельное электропитание и ИБП, отдельный ЦОД.
Из описания мне показалось, что:
- SSD с целью экономии закупались не у HPE
- От HPE была только стандартная гарантия на сервера, какие-то доп. контракты на поддержку не заключались?
Так ли это?
В итоге, проблему удалось окончательно решить лишь через три месяца, когда вышла версия прошивки 1.99 для контроллера дисков!
А почему даунгрейд прошивки не сделали-то? Зачем 1.99 ждали?
А почему даунгрейд прошивки не сделали-то? Зачем 1.99 ждали?
Потому, что инженеры VMware в рамках кейса не давали такой команды. Но пробовали устанавливать разные сборки драйверов.
Возможно, что на тот момент никто не знал, какая из предыдущих прошивок не страдала таким багом. Железо то новое. Но если верить, что прошивка уже была создана в виде беты, то значит баг уже был ранее обнаружен, или кто-то с похожими симптомами сталкивался и открывал кейс (надеюсь, не критическая инфраструктура страдала), и все ждали, поскольку дальше все зависело от бюрократии.
:). И так понятно, что покупали не напрямую у HPE, а через партнеров. Ок, переформулирую. Вот квикспек вашей модели сервера — https://h20195.www2.hpe.com/v2/GetDocument.aspx?docname=a00008181enw. Там в разделе Core Options — HPE Drives перечислены модели совместимых дисков. Те, которые вы купили — из этого списка? Или просто куплены на стороне, потому что дешевле?
Мыши плакали, кололись, но продолжали кушать хардварный рейд.
Мы решим программные проблемы «железными» методами:
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, в чем проблема»?
Итого – имя вендора/интегратора вообще ничего не значит в реальной жизни, если ты сам не понимаешь, что и как будут внедрять. Криворукий установщик может «убить» грамотно проработанное решение. Безграмотный архитектор может «напроектировать» такое, что самый замечательный инженер не сможет заставить работать.
Качество поддержки зависит от конкретного человека «с той стороны» или возможности на него выйти через заслоны 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 (он был только на одном хосте в кластере!) и все заработало.
Готовые решения, подобные VxRail, удобны, обычно имеют упрощенный единый интерфейс развертывания и управления, но стоят как самолет и (опять-таки) не гарантируют 100% защиты от проблем с прошивками и обновлениями. Да, все тестируется и накатывается в комплексе, но всегда найдется уникальный случай у заказчика, факапер-тестировщик у производителя или админ «шаловливые ручки».
2. Vmware? Прошу сильно не бить, но почему не KVM в кач-ве системы вирт-ции + Ceph? Мало будет Proxmox VE — пользуем Opennebula.
Осталось только решить вопросы с горячей миграцией машин как по хостам, так и по стораджам.
Ну и придумать как делать бэкап. Горячий. Инкрементный по измененным блокам на дисках виртуалок.
А, да, еще это должно поддерживаться не уникальным специалистом, который внезапно едет в отпуск, а быть типовым решением.
Для этого также необходим специалист, несмотря на то, что vSan — типовое решение.
И специалист не самый «простой».
И нет того неловкого момента, что цена специалиста по вышеприведенной сборке будет не ниже, чем по решению с vSAN, но понять как это решение построено и почему вообще работает этот специалист не сможет.
Мне приходилось, скажем так, общаться с людьми, от которых ушел очередной (пятый по счету) гениальный админ. И каждый из этих гениев строил инфраструктуру под себя. При этом были в цепочке и и любители Windows, и любители Linux, и любители FreeBSD. И даже знатоки Netware.
С тех пор я очень осторожно отношусь к нестандартным решениям и стараюсь максимально документировать свою работу. Хотя бы ради того, чтобы спокойно проводить отпуск.
2. А почему компании используют брэндовые серверы HPE/DELL/Lenovo и т.п., а не собирают из «open source» железа свои собственные? Можно же купить вполне приличные компоненты и даже сборку заказать, да еще и дешевле выйдет…
2. Да хоть из-за того же ILO\iDrac etc — удобно же. Плюс (якобы ?) более надежные комплектующие, из к-ых собрано брендовое. И да, я пока не видел готовое рабочее решение для удаленного управления «самосбором» (
Но есть и минусы. Напр., в последних поколениях серверов от HP нельзя вот так просто взять и заменить HDD на «небрендовый», т.к. в салазки теперь встроен специальный чип. Что является простым впариванием с огромной накруткой обычных HDD с наклейкой от HP.
Коммерческая система, поддержкой и обновлениями и тестированием.
А… так это за деньги…
Хотите надежность получайте из за деньги.
Хотите поставьте бесплатный ceph как ростреест, не проблема. Потеряете данные и уголовное дело в подарок.
Не бывает бесплатно и надежно.
Бизнесу требуется гарантии:
что система будет обновлятся
решение вопросов по эксплуатации
надежность
и самое главное… компенсация убытков по простоям.
Готовы подписаться с Opennebula в SLA 99,99% и штрафами 10% от контракта за каждый час простоя? Если готовы… добро пожаловать в большой бизнес.
Зы. Тот же Proxmox имеет и платную поддержку, к слову.
Просто прекрасно для бизнеса :)
Просто прекрасно для бизнеса :)
Ага. Куда проще ведь просто выплачивать себе дивиденты, а всю работу переложить на широкие плечи аутсорса. :) Странно, что не все так делают.
VMware vSAN 6.7 — И грянул гром