В аукционе у хецнера в FSN есть с хардварным рейдом как раз и интеловской картой.
У нас один такой сервер уже есть, можно взять второго, а можно попробовать сделать бэкапы в разные дц. Вдруг получится)
Траффик на бэкапы приземляем точно из OVH-SBG и Online.net (DC5a кажется сейчас).
США в Европу заводим через OVH-BHS и дальше по vRack до Страсбурга.
Россию - или напрямую (там разные ДЦ Селектела) или если проблемы с Rascom, то через пиринг на OVH и оттуда уже по обкатанной.
Вы просто не умеете их готовить :)
(У нас и там и там сервера есть)
Самый простой способ - сделать корп карту и привязать её в аккаунт Online.net; мы так сделали.
поддержку можно ждать долго
ставьте через ip-kvm и iso
ставится долго, но - ставится (мы так xcp-ng раскатываем)
Им всегда можно позвонить по телефону и они реагируют на звонки очень шустро
Тогда ещё и velia.net можно посмотреть:
https://www.velia.net/shop/region/strasbourg
И другие регионы
Добавьте второй IP ещё - часто первый адрес сервера в online.net забанен в РКН. Если хостинг под Россию, то второй адрес нужен.
1) OVH, последняя неделя, то что цепляло нас по сети:
20.08 - проблемы со связностью DATA-IX, MSK-IX (высокий входящий трафик) - длилось почти 20 часов; перерулили трафик внутрь сети OVH через DE-CIX; проблемы были с регионами WAV, FRA;
20.08 с примерно 22:45 MSK - 21.08 до примерно 01:30 MSK проблемы были в Варшаве (свежеобновленный маршрутизатор начал терять пакеты);
21.08 - в течение дня - всплесковые потери пакетов через DATA-IX, SPB-IX, MSK-IX до GRA и SBG.
22 и 23 ничего военного не было
за Азию и США не скажу - у нас там в OVH ничего нет, но в Европе регулярно что-то происходит; в Канаде всё спокойно (на HOST-H линейке проблемы с питанием, поэтому мы от них отказались; а вот EG работают стабильно и долго)
В OVH у нас порядка десятка дедиков и штук 15 виртуалок.
Есть ещё Soyoustart, но их я не включал в статистику.
2) Неа, тут не надо спорить. Надо понимать что и зачем использовать и какие цели и бюджеты.
Один из проектов мы целенаправленно собирали на малоядерных платформах и с небольшим количеством памяти - скоростные e3 5-6 поколений и по 32гб памяти; ставили быстрые диски (NVMe) и крутили там шарды БД.
Под апп-сервера (php7) отлично туда встали i7-6700k - быстрые ядра и быстрая же обработка.
Среднее ответа вышло в пределах 160ms на выходе из кластера.
Ещё хорошо себя показывают e3-32gb-nvme ноды для шардов Greenplum (только сеть надо к ним ХОРОШУЮ). Тут правда есть вопросы о стоимости поддержки на будущее, но сами ноды стоят недорого и MPP отрабатывают на все 100 - e3 высокочастотных как раз хватает чтобы смолотить поток от пары nvme-дисков.
Сейчас внимательно смотрим на Xeon W, но их пока на тест хрен где достанешь - дорогие заразы. Разве что хецнер.
На другом проекте время ответа было чуть менее критично (400-450 было допустимо) и ещё и шардить базу не получалось - под БД брали двухпроцессорные системы на базе E5-26xx v4 с горой памяти, а на дисках получилось сэкономить - база ложилась в кеш ОС, записей мало - хорошо видно по всплескам иопсов. Cache hit rate у БД - 96-98%. Для мемкеша не считали, но там тоже всё хорошо.
В БД там (несмотря на достаточно агрессивное кеширование) пролетало по 200М селектов в сутки в пиках.
Такие сервера в OVH выходят подороже чем в каком-нибудь online.net (а у них DC3 сертицифирован под Tier3).
Короче - сначала задача и аналитика, потом выбор процессоров.
Ещё бы Scalable пощупать наживую :)
У OVH сейчас шикарная по цене-производительности линейка - DO-32, конкретно в FRA. Там стоят v6 процы и P3520 nvme диски и есть гигабитный vRack.
В Польше же v5 и S3510 без vRack. Пинг тоже не скажу что сильно приятный при таргете на Россию.
Также более-менее интересно выглядят Pro-4-S от Online.net, но там скорее всего будут стоят 850-860 EVO самсунги. Они не для всех задач себя хорошо показывают. И адреса online.net прямые к серверам часто в бане у РКН.
Клуб любителей вредных советов.
1) OVH не самые дешевые (есть дешевле, есть лучше по cost-efficency; OVH неплохи для ассиметричных нагрузок и когда нужна гомогенная инфраструктура с гео-распределением)
2) E5 не всегда лучше E3 (single thread performance у е5 откровенно слабее; иногда дешевле быстро отстреляться процом, чем тащить десятки процессов/ниток)
3) Внезапно иногда десктопные процы и железо подходят лучше чем всякое e5 (см stateless node и пункт 2)
(там ещё были ребята с советами про aws - убейте себя)
Построить решение можно, заложить расширяемость - тоже.
Чтобы ответить на вопрос "что именно делать" надо профилировать приложение, смотреть мониторинг (вы же собираете munin/zabbix/grafana стату? хотя бы за 3-4 месяца есть что посмотреть?) и много думать.
Но это время и деньги.
И ещё надо обязательно понимать какой вы планируете рост в процентах, какой суточный разброс по нагрузке и какой - связанный с сезонностью.
Без глубокого понимания текущей ситуации и планов развития все советы здесь - это тыканье пальцем в небо.
Разные тому могут быть причины.
Мы разводим в дешевые 100мбпс сервера пограничные сервера разных проектов, через которые проксируем в основные бэкэнды в нормальных ДЦ.
Если что-то вдруг упадёт на границе - страдает только маленькая часть продуктов.
А у одного провайдера ставить мощные бордеры и фильтрацию выходит, часто, заметно дороже и экономически менее выгодно, чем жить с аптаймом от 99.7%
Думаю что у ТС похожая история - траффик-то симметричный, значит проксируют/фильтруют вероятнее всего.
В статье https://habr.com/company/fbk/blog/347312/ неплохо разжевано. Если не гоняться за кровавыми энтерпрайзами, то много кому такая архитектура подходит.
Я просто не из игровых историй и интересно: зачем игровым проектам такая гонка по частотам? Игровые сервера не умеют эффективно утилизировать несколько ядер?
Кстати и е3 тоже очень разные - и внутри поколения и между поколениями. А ещё есть xeon w и xeon e.
