Корпоративный хостинг: это не отдельный тариф, а требования компании к размещению сайта, почты и внутренних сервисов: предсказуемая доступность, резервирование, контроль доступа, бэкапы вне основного сервера и договор, из которого можно выйти. Архитектуру выбирайте по цене простоя: если час недоступности стоит меньше второй копии инфраструктуры, хватит одного сервера или виртуального хостинга с бэкапами; если больше, нужны два сервера за балансировщиком или несколько зон облака. Ниже сравнение архитектур, SLA двух крупных облаков в минутах и наш тест балансировщика nginx, где зависший сервер оказался опаснее выключенного.
Как мы проверяли
11.11.2026 мы прочитали SLA Amazon EC2 и Google Compute Engine на их официальных страницах и перевели проценты доступности в минуты простоя для 30-дневного месяца. Балансировщик проверили на тестовом стенде: контейнер Ubuntu 24.04, nginx 1.24.0, фронтальный nginx и два бэкенда на одной машине, нагрузка утилитой hey (10 одновременных соединений). Это стенд, а не серверы RichHost: цифры показывают поведение настроек, а не скорость провайдера.
Чем корпоративный хостинг отличается от обычного
Технологии те же: серверы, диски, сеть. Отличаются вопросы. Владельца небольшого сайта интересуют цена и скорость, а компанию еще и то, что случится после отказа любой отдельной части, у кого есть доступ к данным и как перейти к другому провайдеру. На практике это четыре требования:
- Доступность: сколько минут простоя в месяц вы готовы принять и что за их превышение обещает договор.
- Резервирование: переживет ли сервис отказ одного диска, сервера или целого дата-центра.
- Доступы и журналы: отдельные учетные записи для людей, вход по ключам вместо паролей, журнал действий администраторов.
- Бэкапы и выход: копия вне основного сервера, проверенное восстановление и план переезда.
Многим компаниям для корпоративного сайта, лендингов и почты на своем домене кластер не нужен. Кластер окупается только там, где недоступность сервиса останавливает продажи или работу людей; в остальных случаях надежный виртуальный хостинг, бэкапы и мониторинг закрывают те же риски намного проще.
Архитектуры: что ломается и кто это чинит
У каждой схемы своя точка отказа. Таблица показывает, что именно кладет сервис в каждом варианте и кто отвечает за администрирование.
| Архитектура | Что кладет сервис | Кто администрирует | Когда подходит |
|---|---|---|---|
| Виртуальный хостинг | Отказ сервера провайдера; соседи по серверу влияют на скорость | Провайдер (сервер), вы (сайт) | Корпоративный сайт, лендинги, почта, CMS |
| Один VPS или выделенный сервер | Отказ этого сервера или его дата-центра | Ваша команда или подрядчик | Приложения с особым ПО, когда простой на время ремонта допустим |
| Два и больше серверов за балансировщиком | Отказ балансировщика, общей базы данных или дата-центра | Ваша команда | Сервисы, где минуты простоя стоят дорого |
| Несколько зон облака | Региональная авария, ошибка конфигурации, выкаченная везде | Команда с опытом облака | Большие нагрузки, требование 99,99% |
| Гибрид (свои серверы и облако) | Сложность: два набора инструментов, сетей и доступов | Ваша команда | Данные, которые должны оставаться на собственном оборудовании, плюс гибкие ресурсы |
Колонку «Кто администрирует» меняет слово managed: разницу между managed, unmanaged и semi-managed выясните до подписания договора. Цены и ресурсы каждого варианта мы сравнили в статье о типах хостинга.
SLA в минутах и в деньгах
Процент доступности легко перевести в минуты: в 30-дневном месяце 43 200 минут. 99,5% допускает 216 минут простоя (3 часа 36 минут), 99,9% допускает 43,2 минуты, 99,99% всего 4,3 минуты. Вот что обещают два крупных облака на своих страницах SLA (Amazon EC2, Google Compute Engine, проверено 11.11.2026):
| Сервис | Обещанная доступность за месяц | Допустимый простой за 30 дней | Компенсация (доля месячного счета за сервис) |
|---|---|---|---|
| Amazon EC2, отдельный инстанс | 99,5% | 216 мин | 10% ниже 99,5%; 30% ниже 99,0%; 100% ниже 95,0% |
| Amazon EC2, инстансы в 2+ зонах региона | 99,99% | 4,3 мин | 10% ниже 99,99%; 30% ниже 99,0%; 100% ниже 95,0% |
| Google Compute Engine, отдельный инстанс (большинство типов) | 99,9% | 43,2 мин | 10% ниже 99,9%; 25% ниже 95,0%; 100% ниже 90,0% |
| Google Compute Engine, инстансы в нескольких зонах (Premium) | 99,99% | 4,3 мин | 10% ниже 99,99%; 25% ниже 99,0%; 100% ниже 95,0% |
Первый вывод: 99,99% эти провайдеры обещают только для копий в разных зонах, для отдельного сервера цифра ниже. Второй: компенсация ограничена счетом за сам сервис и не покрывает ваши потери, а в Google ее еще нужно запросить в течение 60 дней с журналами простоя. Поэтому SLA не страховка, а сигнал того, насколько провайдер уверен в своей инфраструктуре.
Балансировщик на стенде: выключенный сервер против зависшего
Балансировщик распределяет запросы между несколькими серверами и исключает из ротации тот, что не отвечает; принцип описан в статье о балансировке нагрузки. Мы собрали минимальную схему: фронтальный nginx и два бэкенда, 10 одновременных соединений в течение 15 секунд, а на пятой секунде ломаем второй бэкенд двумя способами. Конфигурация фронтального сервера:
upstream app {
server 127.0.0.1:8671 max_fails=1 fail_timeout=10s;
server 127.0.0.1:8672 max_fails=1 fail_timeout=10s;
keepalive 16;
}
location / {
proxy_pass http://app;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_next_upstream error timeout;
}
| Сценарий | Запросов | Ошибок | Самый долгий ответ |
|---|---|---|---|
| Бэкенд 2 остановлен (nginx -s stop) | 454 964 | 0 | 16 мс |
| Бэкенд 2 заморожен (SIGSTOP), proxy_read_timeout 3 с | 370 852 | 0 | 3,0 с (10 запросов) |
| Бэкенд 2 заморожен, тайм-аут по умолчанию (60 с), тест 10 с | 81 046 | 0 | 60,04 с (10 запросов) |
Остановленный сервер сразу отказывает в соединении, и nginx незаметно для посетителя повторяет запрос на другой бэкенд. Зависший сервер соединение принимает, но не отвечает, и балансировщик ждет тайм-аут. С настройками по умолчанию каждое из 10 активных соединений ждало 60 секунд, прежде чем запрос ушел на живой сервер. Еще одна деталь из документации nginx: POST-запросы, уже отправленные на бэкенд, по умолчанию повторно не отправляются (параметр non_idempotent), поэтому отправка формы на зависший сервер закончится ошибкой. Поэтому в корпоративной схеме важны не только два сервера, но и короткие тайм-ауты, активные проверки состояния и мониторинг сервера и сайта, который замечает зависание раньше клиентов.
Умножать серверы просто для части системы без состояния: копии приложения одинаковы, и автомасштабирование в облаке добавляет их по метрикам нагрузки. Основная база данных остается одна, поэтому ее репликацию, бэкапы и время восстановления планируйте отдельно.
Как выбрать провайдера: вопросы до подписания договора
Ответы просите письменно: их легко сравнить между кандидатами и потом сверить с договором.
- Где физически стоят серверы и бэкапы? Страна и дата-центр влияют на задержку и на требования к персональным данным.
- Что именно покрывает SLA? Процент, способ измерения, исключения, размер и порядок компенсации.
- Кто и когда отвечает? Часы работы поддержки, каналы связи, время реакции.
- Как выйти? В каких форматах можно забрать данные, сколько стоит исходящий трафик, привязаны ли вы к собственным инструментам провайдера. Стандартные технологии (Docker, MySQL или PostgreSQL, Terraform) упрощают переезд на другой хостинг.
- Где лежат копии? Бэкап на том же сервере не защищает от его потери; правило 3-2-1 и проверка восстановления описаны в статье о бэкапе сайта на хостинге.
Если X, делайте Y
| Ситуация | Что делать |
|---|---|
| Корпоративный сайт, лендинги и почта; несколько часов простоя неприятны, но не останавливают бизнес | Виртуальный хостинг у надежного провайдера, бэкапы вне сервера, мониторинг доступности |
| Внутреннее приложение с особым ПО, администратор есть | VPS или выделенный сервер, бэкапы в другом дата-центре, проверенный план восстановления |
| Несколько минут простоя останавливают продажи | Два и больше серверов за балансировщиком, короткие тайм-ауты, проверки состояния, репликация базы |
| Нужно 99,99% и есть команда с опытом облака | Несколько зон облака, автомасштабирование, регулярные учения по восстановлению |
| Данные должны оставаться на собственном оборудовании | Гибрид: свои серверы для данных, облако для пиковых нагрузок |
| Провайдер не отвечает письменно про SLA, бэкапы и выход | Ищите другого |
Где здесь RichHost
RichHost, который ведет этот блог, является международным хостинг-провайдером с 2003 года с серверами в Европе и США: 4 дата-центра TIER III в Хельсинки, Варшаве, Париже и США. Мы продаем виртуальный хостинг и домены; VPS и выделенных серверов у нас нет, поэтому для кластера с балансировщиком нужен облачный провайдер. Для корпоративного сайта и почты виртуального хостинга часто достаточно: в тарифах виртуального хостинга RichHost неограниченное количество почтовых ящиков, NVMe-диски, SSH-доступ на всех тарифах, бесплатный SSL Let’s Encrypt и бесплатный перенос сайтов. Поддержка работает с 10:00 до 20:00 по киевскому времени и отвечает примерно за 30 минут.
Частые вопросы
Может ли обычный виртуальный хостинг быть корпоративным?
Да, если он закрывает ваши требования: доступность, бэкапы вне сервера, доступы и поддержку. Название тарифа значения не имеет, важны условия договора.
Сколько простоя допускает SLA 99,9%?
43,2 минуты за 30-дневный месяц, или около 8,8 часа в год.
Защищает ли балансировщик от всех сбоев?
Нет. В нашем тесте он мгновенно обошел остановленный сервер, но с настройками по умолчанию ждал 60 секунд зависший. Не спасает он и от отказа общей базы данных или ошибки в коде, выкаченной на все серверы одновременно.
Нужен ли отдельный сервер для корпоративной почты?
Обычно нет: почту на своем домене дают виртуальный хостинг и почтовые сервисы. Важнее правильно настроить SPF, DKIM и DMARC, чтобы письма доходили до входящих.