не бред, кому-то может и нужно это; но для всех проектов, за которые я отвечаю, я принял решение что это экономически нецелесообразно. И я ещё делаю "внутренний оверселл" - hot standby одного проекта в ДЦ могут быть мастер-нодами другого. По-сути только за диски надо доплатить (а иногда получить их в составе "пакета" с заметной скидкой).
Физика простая. У оперативной памяти есть тайминги (не помню какой за что отвечает), указываемые в "тиках" частоты.
Если у вас операция занимает 17, например, "тиков", то при росте частоты будет аналогичный в процентах рост производительности - будет меньше времени уходить на операцию, так как за одно и то же время "тиков" пройдёт больше.
Это знание очень наглядно показывает как нам дуют в уши про рост производительности памяти (забавно смотрится сравнение DDR3 последней и первой DDR4 например), а также даёт понимание почему "дорогая геймерская память" лучше и насколько она реально быстрее.
потому тогда надо не забывать ещё про очень аккуратный мониторинг износа (он чаще по записи, а тут вы просто её делаете +-одинаково на две одинаковых железки), а также не получаете совершенно никакой выгоды на чтение (в этот момент у многих открытие и желание поспорить, я думаю :) )
Также в таком случае надо не забывать про отказ по питанию по любой причине, про глюк контроллера (а я ловил такое в hw raid5 от LSI и получал кашу из битов размазанную на 4 совершенно здоровых дисках лол) и т.д. и т.п.
Короче при честном резервировании оно строится по принципу N+1+1 - один в ДЦ в соседнем модуле-стойке (с минимальным пересечением по питанию, коммутаторам и т.п.) как hot standby и один warm standby вынесенный в другой ДЦ (желательно другого провайдера) с рядом лежащим опенстек-облаком.
Можно ещё географию разнести до разумных пределов. Чтобы закрыться от блэкаута-погоды и т.п.
Hot standby можно в таком раскладе использовать для распараллеливания read-нагрузки, а из warm легко и приятно бэкапиться.
PS. Это всё верно для stateful-части ваших сайтов-приложений-что-там-ещё. Stateless чаще выгодно делать гибридом - использовать для части нагрузки дедики, а для части арендовать cpu инстансы на почасовке и выдерживать ими пиковые нагрузки.
ох уж эти советы собирать raid1 из ssd (facepalm)
Если же убрать raid1, то звучит разумно.
Обратите внимание - у хецнера есть datacenter ssd и есть обычные. Разница в иопсах между ними заметная (в некоторых сценариях датацентр серии лучше в 15 раз).
А вообще хорошо бы понять что вы там с диском такое делаете, что у вас 12к иопс в полку положены (и по какому показателю? read? write?)
И ещё вопрос - какие иопсы-то?
Например, запись блоками по 4М в 32 потока выше 500 иопс - это очень круто. Выше 600 просто не видел вживую.
Запись в 32 потока блоками по 4к может быть выше 300 000 иопс.
Мы сталкивались. Среднее время выполнения запроса на запись (update/insert) при пике в 200tps стало расти как на дрожжах.
Замена 850 гнусмасов на pm963 проблему решила.
Потом потестировали оптаны - они ещё лучше для этого: при нормальном разделении уровней записи-чтения всё встаёт на свои места и за разумные деньги.
Минусы 850 самсов (не важно evo или pro) известны:
Отвратительная хвостовая латентность. Низкая скорость при долговременной записи.
Ужасающе низкая производительность в режиме жунальной записи (то, что используется под СУБД и где это реально важно).
Из SATA-десктопов самое терпимое что я пока видел - SSDSC2KW512G8. Но в журнале оно проигрывает sm863 по tps в 15(!!) раз.
SM863 серия у самсунгов же - весьма бодрая и хорошо работает.
Кстати, многие десктопные NVME тоже полное говно для серверного применения. Их место в десктопах не просто так :)
Странно что вы занимаетесь железом и не знаете прописных истин.
Бонус-трек.
У вас же двухпроцессорные системы. Здравствуй, NUMA, новый год.
Я так подозреваю, для большинства задач (сложнее хостинга вордпресса на трёх человек в день) какой-нибудь e3-1270v6, 64RAM с парой S3510 будет заметно более полезен ваших флагманских конфигов.
Ваше же, вероятно, неплохо должно подходить под раздачу стримов. Но не с вашим предложением по трафику.
С такими говёнными ssd и за такие деньги предложение совершенно неактуальное (а название топика - вообще маркетинг головного мозга)
Они и сейчас в бане многие.
А ДЦ в Амстердаме за последние полгода провалялся часов 14 в сумме. Без всяких компенсаций.
у ovh openstack cloud есть
активация проекта то ли 10 то ли 15 евро, которые тратятся на аренду машин
Ну если принять за аксиому что падают и все и всегда, то на один сервер в одном ДЦ никто ни в жизни такого не поставит :)
Правильнее говорить о допустимом времени простоя в случае отказа, классификации отказов и т.п.
У нас минимально допустимый SLA 99.7, в норме мы имеем 99.91 в-среднем по году
Нет проблем сделать больше, но стоимость каждой девятки увеличивает стоимость инфраструктуры и её поддержки нелинейно
Если три девятки мы можем в текущей инфраструктуре делать стабильно и просто, то четвертая девятка требует перехода к другим схемам фейловера и балансировки, что увеличивает стоимость минимум на порядок.
Но стоимость построения этой девятки в нашем случае будет выше, чем прибыль от неё.
Что же касается "множественных датацентров" то тут столько подводных камней что прям ууу.
Какое допустимое время потери данных? Какой интервал до фейловера? Какое время прогрева датацентра резерва?
Все эти вопросы продавцы облаков опускают и продают "счастье всем", которое никого ни от чего не спасёт.
Селектел вон облако VMWare запустил. При отказе основного датацентра всё грузится из резервного. ТАЧКИ СТАРТУЮТ ЗАНОВО. Прогретые кеши? Не, это не сюда (хайлоад!!).
А как насчет latency у stretched vsan? У них между ДЦ в Спб не такое большое расстояние, но положить на этот vsan базу данных - надо быть отчаянным человеком. Да даже на обычный SAN БД положить - это отчаянный шаг. Stateful же.
Думать про катастрофоустойчивость необходимо. Но нужно понимать как это работает. И после построения системы регулярно дёргать рубильник для проверки того что всё отработает штатно.
У нас линуксы, но мы это завели.
Самое важное - это MTU.
Без него пинги пойдут, а вот дальше ничего не заработает :)
Очень много вопросов к устройству системы - архитектура, типовые запросы, требования по времени ответа и т.п.
Могу сказать что 2-3M посетителей в месяц (15-30k "глубоких" пользователей) для сайта типа Avito можно держать на 2-6 серверах с общей арендой ~500 евро в месяц. Мы на нашем проекте можем поднять цифры примерно в 3 раза по daily без серьёзного увеличения затрат.
Чтобы цифры были такими - надо и приложение заточить правильно и сервера подобрать не на первой попавшейся площадке.
Но это - реальные цифры из работающего здесь и сейчас проекта.
Для роста на порядок от наших текущих нагрузок нам понадобится достаточно сильно пилить архитектуру в разработке (потому что такие цифры выпадают из business-scope - нет столько трафла даже и поэтому мы к нему и не готовы), но сервера тогда потребуют, при нашей экспертизе, 3-5к евро/месяц. Точнее оценить сложно.
И закладывайте ещё, что сервера тут могут стоить не так дорого, как люди, которые умеют все эти кластера правильно готовить, настраивать и обслуживать.
А вообще для произвольного проекта ответить на этот вопрос крайне сложно - нужно профилировать систему, подбирать железки и всё такое.
И там легко могут выходить миллионы рублей в месяц, без проблем :)
