ЧАСТНАЯ ОФШОРНАЯ ИНФРАСТРУКТУРА
Веб и onionПрикладное · 4 мин чтения

Выберите операционную модель хостинга до выбора облака

Сравните общий хостинг, VPS, выделенное оборудование и крупные облачные платформы по ответственности, восстановлению, зависимостям и полному операционному бюджету.

От редакции SwissOctet
ПРЯМОЙ ОТВЕТ

Сравнивайте модели хостинга по операционным обязанностям, которые они назначают, и по архитектуре, которую они позволяют построить. Облачный масштаб, виртуальная машина и выделенное оборудование описывают разные аспекты системы; ни один из них сам по себе не доказывает приватность, стоимость или поведение при восстановлении.

01

Начните с работы, которую должен кто-то взять на себя

Решение о хостинге назначает операционную работу, а также вычислительные ресурсы. Одному проекту нужна учётная запись, на которой работает обычный веб-сайт; другому нужен контроль над пакетами операционной системы и фоновыми процессами. Третьему нужна платформа базы данных, обслуживание которой выполняется по определённому сервисному контракту. Сначала перечислите эти обязанности вместе с людьми, доступными для их поддержки.

Общий хостинг обычно предоставляет среду уровня учётной записи. VPS предоставляет гостевую операционную систему, а выделенное оборудование переносит границу машины на физический сервер. Управляемый — это отдельный вопрос: ярлык продукта не говорит вам, кто применяет патчи, восстанавливает данные или расследует инцидент. Спрашивайте об области управления и процедуре восстановления, а не считайте это универсальной функцией.

02

Поймите, что облако добавляет к сравнению

NIST описывает облачные вычисления через такие характеристики, как доступ по требованию, объединение ресурсов, эластичность и измеряемое обслуживание. Виртуальная машина может быть одним из компонентов облачной платформы, поэтому VPS и облако — не взаимоисключающие технологии. Полезное сравнение — между конкретными предлагаемыми сервисами: фиксированной виртуальной машиной, эластичным парком или приложением, построенным вокруг управляемых сервисов.

Гиперскейлер — это отраслевой термин для провайдера, эксплуатирующего инфраструктуру и сервисные платформы в очень большом масштабе. Такой масштаб может предлагать широкий набор инструментов развёртывания и географических вариантов; он не говорит вам, соответствует ли конкретная архитектура вашим потребностям. Оценивайте регион, зависимости сервисов, модель идентификации и контракт каждого компонента. И меньший провайдер, и крупная платформа требуют ясного отчёта о том, куда попадают данные.

Операционная модельКонтроль, доступный проектуВопрос перед выбором
Учётная запись общего хостингаНастройки сайта в рамках учётной записиПодходит ли среда выполнения приложению?
Виртуальная машинаГостевая ОС и установленные сервисыКто поддерживает и восстанавливает гостя?
Выделенная машинаГраница физического сервераОправдывает ли рабочая нагрузка эту границу?
Управляемый облачный сервисСервис API и поддерживаемые настройкиЧто остаётся ответственностью клиента?
03

Выберите архитектуру, способную восстанавливаться

Одна машина может быть разумной отправной точкой для небольшого приложения, когда требования к восстановлению допускают восстановление или плановое окно обслуживания. Добавление второго узла приложения меняет дизайн только если маршрутизация трафика, сессии и постоянные данные корректно работают на обоих. Два сервера, работающие по одному и тому же неполному плану восстановления, всё ещё остаются неполным планом восстановления.

Распределённое хранилище иллюстрирует это различие. Такое программное обеспечение, как Ceph, распределяет работу по хранению между кластером и предлагает объектный, блочный и файловый интерфейсы. Репликация или кодирование с исправлением ошибок могут помочь переносить определённые отказы оборудования, но кластеру также нужна ёмкость для восстановления и ребалансировки. Распределённая живая копия не заменяет независимую резервную копию. Решите, как ведут себя записи во время сетевого разделения, и протестируйте сценарии отказа, relevant для выбранной вами реализации.

04

Сравните полный операционный бюджет

Записывайте бюджет как рабочую нагрузку: обычный трафик, пиковый интервал, хранимые данные, хранение резервных копий и передачу, необходимую для восстановления. Включите платное программное обеспечение, внешние API, время администрирования и стоимость повторного перемещения данных. Стартовая месячная цифра и оценка на основе использования отвечают на разные вопросы. Сравнивайте их за один и тот же период и сохраняйте допущения рядом с результатом.

Для крупной облачной платформы определите каждый сервис, необходимый для работы приложения. Для VPS включите работу, которую иначе взяли бы на себя управляемые сервисы. Ни один подход не является автоматически дешевле. Начните с небольшого репрезентативного развёртывания или документированного предложения, затем сравните фактический счёт с моделью. Оставьте запас на трафик восстановления и временную ёмкость миграции, а не бюджетируйте только установившееся состояние.

05

Относитесь к приватности как к карте зависимостей

Регион машины — лишь одна запись на более широкой карте. Аутентификация, мониторинг, инструменты поддержки, резервные копии и API моделей могут работать через отдельные сервисы. Зафиксируйте, что получает каждый из них, кто может получить к нему доступ и как долго он хранится. Модель общей ответственности AWS — один из примеров провайдера, явно разделяющего свои инфраструктурные обязанности и обязанности клиента; область действия меняется в зависимости от сервиса.

Используйте это различие при сравнении провайдеров, не перенося обязанности одного провайдера в контракт другого. Конфигурация SwissOctet описывает место хостинга и перечисленные ресурсы. Она не устанавливает местоположение интеграций, которые вы добавите позже. Минимизируйте данные, получаемые каждой зависимостью, защитите администрирование и проверьте места резервного копирования, прежде чем делать заявление о пути данных вашего собственного приложения.

06

Используйте путь миграции как часть решения

Проверьте, как вы можете экспортировать данные приложения, конфигурацию и идентичности. Обычное приложение на виртуальной машине может быть несложно переместить, тогда как база данных или система событий, специфичная для сервиса, может потребовать адаптации. Переносимость также зависит от операционных знаний: резервная копия, которую никто не знает, как восстановить, — слабый план выхода, даже если её формат открыт.

Для первого шортлиста SwissOctet сравните Canvas, когда подходит веб-среда уровня учётной записи, Vector для контроля гостевой ОС и диапазоны Metal, когда важна физическая граница. Варианты, ориентированные на хранение, поддерживают другой вопрос о ёмкости и не должны описываться как управляемый распределённый кластер. Держите архитектуру достаточно простой для эксплуатации и добавляйте сложность платформы, когда она отвечает проверенному требованию, а не воображаемому будущему масштабу.

ПРЕВРАТИТЕ ЭТО В ДЕЙСТВИЕ

Ваш практический чек-лист.

  • Назначьте ответственных за администрирование и восстановление.
  • Отличайте виртуальную машину от более широкой облачной платформы.
  • Бюджетируйте зависимости, передачу и обслуживание.
  • Проверьте границу отказа перед добавлением узлов.
  • Зафиксируйте работоспособный путь экспорта и миграции данных.
ЧАСТЫЕ ВОПРОСЫ

Детали, которые важны.

Может ли VPS быть частью облачной платформы?+

Да. Виртуальная машина может быть облачным сервисом. Сравнивайте фактическую модель ресурсов, масштабирования и управления, а не предполагайте, что названия описывают взаимоисключающие технологии.

Заменяет ли распределённое хранилище резервные копии?+

Нет. Живая избыточность устраняет отдельные отказы компонентов. Независимая резервная копия и тест восстановления устраняют другие отказы, такие как удаление и повреждение данных приложения.

Всегда ли крупное облако — плохой выбор для приватности?+

Нет. Оценивайте конкретные сервисы, потоки данных и договорные меры контроля. Размер провайдера сам по себе не устанавливает пригодность архитектуры.

ОСНОВНЫЕ ИСТОЧНИКИ

Перейдите к источнику.

Эти источники поддерживают технические концепции в этом руководстве. Следуйте актуальной документации, прежде чем менять производственную систему.

  1. NIST SP 800-145: Определение облачных вычислений nvlpubs.nist.gov
  2. AWS: Модель общей ответственности aws.amazon.com
  3. Ceph: Архитектура хранения docs.ceph.com
  4. Ceph: Кодирование с исправлением ошибок docs.ceph.com

Редакционное руководство от SwissOctet. Примеры иллюстративны. Спецификации услуг, доступные опции и договорные условия необходимо проверять отдельно.

СВЯЖИТЕ ЗНАНИЯ

Связанная инфраструктура.

СОХРАНЯЙТЕ НИТЬ

Ваши следующие заметки.

Изучите все руководства
ЗАМЕТКА / 03
Хранение и восстановлениеОснова

Объектное, файловое или блочное хранилище: выберите интерфейс, необходимый вашему приложению

Различайте интерфейсы хранения, семантику доступа и операционные обязанности, прежде чем превращать требование к ёмкости в архитектуру приложения.