Верно.
Берете под конец биллинг-периода нужных размеров железку, поднимаете там платформу+бридж-виртуалку.
Если CPU options совпали - не отключая нагрузку и пользователей переносите машину между нодами (никакого HA); в конце миграции получите лаг на секунд 10. Всё. (не рвётся rdp, ssh и тп.)
Если не совпали - то вечером, как все ушли домой, гасите виртуалку и мигрируете её выключенную. Или подгоняете options старой и новой платформы.
Даунтайм = времени перелива в худшем случае.
Понятно, что если у вас нагрузка скачет в течение короткого периода времени и вы не умеете это прогнозировать, то вариант не подходит.
Но на длинных циклах всё работает четко и предсказуемо.
При большом желании можно даже кластер сделать с HA :) Правда это чуть подороже.
Для одного из клиентов ставили следующую инсталляцию:
сервер с VM-платформой (xenserver) в hetzner (там на аукционе полно неплохих вариантов), внутри - виртуалка с win без доступа в интернет + виртуалка с VPN-бриджом
ещё одна виртуалка в OVH в GRA (для России сейчас лучше взять Польшу)
Из плюсов:
- стало нужно больше/меньше ресурсов - переехали без остановок на сервер потолще/потоньше там где-нибудь; (только виртуалку надо ребутать);
- бэкапы: NAS от хетцнера стоит копеек для бэкапов, берем его и льём туда; по выходным льём бэкап в офис; +теневое копирование, куда без него;
- промежуточный сервер можно исключить, можно строить цепочку. Вопрос паранойи;
- вопросы лицензий решаются национально-приемлемым способом.
chipcore.com - тот же селектел, дешевле в России не найти, наверное
кстати по цене за гигабайт хранения их L7 выигрывает даже у хетцнера
Последние три регистрации у знакомых были такие же.
Напишите письмо в саппорт с ящика регистрации что вы живой и хотите чтобы аккаунт включили - включают (но могут попросить подтверждение валидности паспорта или адреса).
Можно. Именно это и нужно сделать.
Само собой)
Но как держать (именно по хитам) нагрузку в интернет-магазины - понятно тоже.
С интернет-магазином для игольчатого траффика и злой нагрузкой нужна очень продуманная архитектура и очень тщательный подбор железа.
Агрессивное кеширование уровня страниц не работает с ИМ. И не работает с новостниками тоже, на самом деле.
Там динамики и ротаторов ойвэй сколько бывает наверчено, не говоря про всякое АБ ;)
Так, чтобы держать пиковые (!) 12к rps на жалких 8 ядрах пришлось заметно переписывать всё, что попадает в первый и второй уровень переходов. Конкретно я решал на express + redis + sphinx с кешированием всего что можно в памяти процесса (и инвалидацией таймерами или внешними хитами); особенность была в том, что точка входа была _очень_ детерминированной. Буквально - 1-2 страницы ньюситемов и от неё в глубину 3-4 перехода листы и итемы.
В ИМ:
Поиски можно кешировать многомерными кешами поверх кластера фасетов (на эластике например). Рекомендации - через кеширование деревьев и весов... Сравнения вообще халява - бери товары в один мультигет и всё.
Остаётся только иметь много процессоров для постпроцессинга (aka) и сборки (aka) на любом языке и помнить про алгоритмическую сложность.
Чтобы подешевле - сделать гибридным облаком и скейлить под пиковые нагрузки, делить ресурсы на горячие и холодные зоны.
Но всё это - далеко не какой-нибудь опенкарт/битрикс из коробки, а много вдумчивых часов кодинга весьма недешевыми мозгами.
--
Куда как хуже что чтобы выдержать пиковую нагрузку ИМу нужен не менее железобетнный бэкофис и процессы. И вот это уже - может быть настоящей проблемой.
И скорее тема о том как сделать хорошо и дешево хайлоад и автоскейл, да ещё и чтобы понятно было человеку, далёкому от системного администрирования/программирования.
Правильный ответ скорее всего - никак, увы :(
С облаками обычно вся проблема в даунскейле. Распухнуть-то легко, а вот собрать потом назад... Да ещё и перезагрузка нужна)
Хороший совет: чтобы не конкурировать за ресурсы.
Только брать надо рядом, а не в 50мс (как тут недавно на форуме товарищ сделал)
всё зависит от высоты и продолжительности иголки трафика
для новостных сайтов это нормальная такая проблема - попал в тему и лёг по порту)
на нашем опыте (12к req per sec по новостному сайту в пике) это решается балансером и агрессивным кешированием входных страниц на нём
не знаю кто из хостингов такие вещи предлагает правда (но настраивается это относительно несложно)
50ms на КАЖДЫЙ запрос в БД! Это не +50мс к рендеру, а обычно побольше)
У amhost посмотрите SEO-пакеты. Наши ребята одно время пользовались.
SSL-сертификат для .ru поправьте, а то выглядит прям не очень
