(TL; DR: последний абзац) Я использую онлайн-сервис и до сих пор выполняю автономное резервное копирование и простой мониторинг для обеспечения устойчивости и доступности.
Устойчивость скорее ручная, но я вполне уверен, что данные сохранятся. Меня немного беспокоит, что данные менее безопасны, потому что мне приходится активно делать их резервные копии. Сайт несколько раз отключался на полдня, потому что мне нужно было время, чтобы ответить, и один раз в несколько дней из-за сбоя ИБП и сети.
Мне это не нравится.
Я искал решения для кластеризации серверов на основе XEN, а также решения PaaS. Я считаю, что ни один PaaS никогда не сможет обеспечить требуемый мне уровень безопасности. Я рассматриваю возможность разделения на операции low-sec и high-sec, но это только решит мою проблему с хостингом.
Мне не нужна экстремальная масштабируемость (но я надеюсь) или идеальное время безотказной работы, но они мне, естественно, нравятся. Допускается остановка на несколько минут. Потеря активной памяти - отстой. Потеря данных на диске недопустима. Нарушение безопасности (опубликованные данные) недопустимо. Я забочусь о выживании только одного приложения, а не о заданиях cron или ОС, на которой оно работает (если оно параноидально безопасно, предпочитаю OpenBSD).
Вопрос: как мне запустить приложение (совместимое с Linux и BSD) так, чтобы оно никогда не умерло на кластере серверов?
изменить: В ответ на ваши запросы о ясности: это веб-сервис для безопасного хранения закрытых ключей, то есть API, доступный через Интернет и выполняющий операции с закрытыми ключами после очистки. Закрытые ключи ценны, и их нельзя терять. Эти ключи синхронизируются с диском, поэтому поддерживаемая память не требуется. Под бессмертным я имею в виду, что он может быть приостановлен, но он должен иметь возможность продолжать после этого приостановления. Обновление ядра не будет серьезной проблемой, потому что может произойти запланированный простой. Это начинает выглядеть как проблема с реплицированным диском и автоматическим переключением при отказе.
Вы задаете много вопросов, все в один большой шар. Я подозреваю, что вы даже не знаете, что спрашиваете некоторых из них.
Я попытался выделить важные моменты и предложить вам несколько советов.
Меня немного беспокоит, что данные менее безопасны, потому что мне приходится активно делать их резервные копии.
Зашифруйте свои резервные копии. Любое программное обеспечение для резервного копирования, которое стоит использовать (например, Bacula) поддержит это.
Сайт несколько раз отключался на полдня, потому что мне нужно было время, чтобы ответить, и один раз в несколько дней из-за сбоя ИБП и сети.
Мне это не нравится.
Никто не делает, но бывает. Если вы хотите избежать этого, вам нужны распределенные дублирующие копии вашего сайта, желательно параллельно избыточность (когда запросы поступают ко всем копиям постоянно, и данные между ними волшебным образом синхронизируются.
Подумайте о Google, потому что мы говорим о таком бюджете. В игре безотказной работы Девятка стоит долларов.
Я искал решения для кластеризации серверов на основе XEN, а также решения PaaS. Я считаю, что ни один PaaS никогда не сможет обеспечить требуемый мне уровень безопасности. Я рассматриваю возможность разделения на операции low-sec и high-sec, но это только решит мою проблему с хостингом.
Похоже, вы ищете неправильные решения, потому что если I do not require extreme scalability (yet, I hope :) or perfect uptime, but I'd naturally like them. правда, наиболее экономичным решением было бы найти другой центр обработки данных (с лучшей инфраструктурой и более строгим SLA).
Вы гонитесь за вещами, предназначенными для быстро чтобы достичь надежный - эти двое не исключают друг друга (на самом деле они в некотором роде симбиотичны), но они также не сиамские близнецы.
Допускается остановка на несколько минут. Потеря активной памяти - отстой. Потеря данных на диске недопустима. Нарушение безопасности (опубликованные данные) недопустимо. Я забочусь о выживании только одного приложения, а не о заданиях cron или ОС, на которой оно работает (если оно параноидально безопасно, предпочитаю OpenBSD).
в порядке, Halting for minutes is acceptable означает, что вы разумны. Это хорошо. Нам здесь нравятся разумные люди.
Losing active memory sucks - Я согласен с тобой в этом Скиппи, я просто не думаю, что у тебя есть повод для иска.
Сбой серверов. Это происходит даже в наиболее обслуживаемых средах, и когда сервер перезагружается или теряет мощность, активная память (RAM) исчезает. С этим ничего не поделаешь - вот что должно случиться.
Losing disk data is unacceptable - Ой, чувак, теперь ты ООН разумно.
В реальном мире диски выходят из строя. Когда это происходит, они забирают с собой все свои данные, и вы теряете все, что было сделано с момента последнего резервного копирования. Вот почему мы делаем резервные копии (достаточно часто, чтобы не потерять перебор важные данные).
Поскольку вы уже делаете резервные копии, вы делаете все возможное, чтобы смягчить это, поэтому, когда произойдет неизбежный сбой диска (или сбой и повреждение ОС), мой совет - ударить котенка по лицу и начать процесс восстановления.
(Вы делать у вас есть процесс восстановления, и вы регулярно его тестируете, верно? :-)
Breach of security (publicized data) is unacceptable - Я просто скажу на это "Ну да ладно" и продолжу. Я не могу придумать ни одной службы, где извлечение данных считалось бы "приемлемым".
[I don't care] about . . . the OS . . . (as long as it's paranoidly secure, prefer OpenBSD) - Безопасность НЕ является функцией операционной системы, это функция конфигурации, которую вы применяете поверх нее. Я могу создать незащищенную машину OpenBSD примерно за 5 секунд.
Забудьте о всей маркетинговой шумихе и забудьте о (по общему признанию впечатляющей) послужном списке OpenBSD: выберите ОС, которая соответствует вашим потребностям, а затем потратьте время на ее защиту. Да, вам все равно нужно сделать это для окна OpenBSD.
Вопрос: как мне запустить приложение (совместимое с Linux и BSD) так, чтобы оно никогда не умерло на кластере серверов?
Вы этого не сделаете. Лучшее, что вы можете сделать на большинстве кластеров (или отдельных систем, если на то пошло), - это отслеживать сбои приложений и перезапускать их достаточно быстро, чтобы ваши пользователи не заметили.
Самое близкое, что вы собираетесь подойти к тому, что вы описываете, - это настройка чего-то вроде VMWare HA (на географически распределенных сайтах, если проблемы с сетью / центром обработки данных (питание) являются реальной проблемой) и отказ всей (виртуальной) среды. закончится, если один сайт выйдет из строя.
edit: В ответ на ваши запросы о ясности: это веб-служба для безопасного хранения закрытых ключей, то есть API, доступный через Интернет и выполняющий операции с закрытыми ключами после очистки.
Надеюсь, вы не ошиблись, но вы можете получить мои личные ключи, когда вырвете их из моих холодных, мертвых, безжизненных рук. Любой, кто не разделяет эту философию, недостаточно параноик в отношении безопасности данных. :-)
Для доступности нужен где-то второй сервер. Если ваше местоположение недостаточно хорошее, вторая хорошая вещь - это купить сервер и разместить его в каком-нибудь центре обработки данных colocation, менее безопасный - арендовать выделенный сервер (например, в стойке), менее безопасный - подписаться на VPS. Полагаю, вам не нужно покупать меньше, поскольку VPS дешевы (Amazon EC2 предоставляется бесплатно в течение 1 года).
Судя по тому, как вы описываете свои требования к доступности, кажется, что простого добавления одного VPS к существующему серверу будет достаточно.
Если для высокоскоростных операций достаточно вашего единственного сервера - вы можете иметь low-sec на VPS. Если одного вашего сервера для хайсек не хватит - вам нечего делить.
Нетрудно иметь приложение, которое «никогда не умрет» на двух серверах - просто синхронизируйте все свои данные в реальном времени между серверами, используйте некоторую кластерную базу данных (я слышал о cassandra, но есть МНОГО кластерных баз данных, которые подойдут). Если это ДОЛЖНЫ быть файлы файловой системы, есть DRDB, но я бы посоветовал попробовать все равно использовать базу данных и избежать осложнений. Как насчет таблицы с двумя столбцами: 1. имя файла и путь и 2. содержимое. Затем вы заменяете все свои файлы сохранения на store-to-DB, а ваши read-файлы на get-from-DB.
Вот и все. В том, чего вы пытаетесь достичь, нет ничего сложного или дорогого.
Отказ от ответственности: вы решаете, какой уровень безопасности вам нужен, я не советовал хранить ваши конфиденциальные данные на размещенных серверах и не советовал иначе.