Комментарии 33
О, крутота :) А куда бэкапите многотерабайтные пулы Cloud Storage? Какая конфигурация у «Storage nodes. Отдельный вид серверов, используемый для бекапов вне Cloud Storage»?
«Перезагрузка занимающая от нескольких секунд (в случае использования контейнерной виртуализации)» — самое быстрое, что может выдать vzreboot (кривоватый аналог reboot less reboot) — это около 15 минут на ровно такой же конфигурации, от запуска команды ребута до подъема последнего контейнера.
Как у вас работает бэкап силами PCS/PVA?
И еще вопрос — PCS/S научился работать с контроллерами Adaptec? Зачем вообще нужны контроллеры для Cloud Storage? Они используются как HBA?
Используется ли рекомендованное вендором SSD кэширование?
Используется ли рекомендованное вендором SSD кэширование?
PCS/S научился работать с контроллерами Adaptec?
Да, научился.
Зачем вообще нужны контроллеры для Cloud Storage? Они используются как HBA?
Да
Используется ли рекомендованное вендором SSD кэширование?
Нет
Cloud Storage кластер очень надежен и не имеет точки отказа, поэтому в дополнительном бекапе всех данных нет необходимости. Однако пользователь может включить резервное копирование своего облачного сервера и оно будет выполняться на хосты вне Cloud Storage.
А первая строка из гайда по интеграции PCS:S говорит «БЭКАПЬТЕСЬ НА ОТДЕЛЬНЫЙ НЕЗАВИМИСИМЫЙ МАССИВ» =)
Есть конечный пользователь, есть админ. Для конечных пользователей есть конкретный функционал бекапа. Админ же в свою очередь сам решает, что бэкапить или не бекапить в зависимости от требований, предъявляемых к его инфраструктуре. Гайд к PCS, это гайд для админов. Эта строчка, для несознательных админов, Которые не делают бекапов компонентов администрирования. Мы делаем.
>>однако использование 2х локаций InfoboxCloud позволяет создавать решения, при которых даже перезагрузка, занимающая от нескольких секунд (в случае использования контейнерной виртуализации) до нескольких минут (в случае использования виртуальных машин) прошла незамеченной для критичных к доступности проектов.
А как у вас связаны обе локации и чем осуществляется репликация или бесшовная миграция клиентского инстанса между локациями?
А как у вас связаны обе локации и чем осуществляется репликация или бесшовная миграция клиентского инстанса между локациями?
Обе локации независимы. Непрерывная репликация всех клиентов облака сделала бы цену на услугу фантастически большой из-за стоимости каналов между локациями. Однако если программная система клиента готова к работе на распределенных виртуальных серверах — она может работать надежно и между несколькими локациями. В критически важных системах необходимо предусматривать такой вариант в самой архитектуре используемого ПО. В самом простом примере клиенты легко могут выполнять репликацию своих баз данных в другую локацию и переключаться на нее при необходимости.
А как же смена IP-адресов и вся работа с DNS?
Фактически при доступности одного ДЦ решения типа Virtual IP не нужны из-за Cloud Storage. Дата-центр имеет много аплинков, электропитание резервируется + используйте DNS с низким TTL.
>> В самом простом примере клиенты легко могут выполнять репликацию своих баз данных в другую локацию и переключаться на нее при необходимости.
При такой конфигурации и независимых локациях у инстансов будут разные IP и при переключении с одного на другой будет даунтайм на время обновления DNS-кэша. Разве нет?
При такой конфигурации и независимых локациях у инстансов будут разные IP и при переключении с одного на другой будет даунтайм на время обновления DNS-кэша. Разве нет?
будет, если один дата-центр уйдет в офлайн, где установлен балансировщик в cloud storage. Мы используем надежные дата-центры.
Бррр, трижды перечитал Ваш пост. Virtual IP работает в пределах ДЦ и если ДЦ, куда он привязан кувыркнется — кувыркнется и услуга. Как Вы предлагаете защищать доступность сервиса на случай вылета либо первого либо второго ДЦ? Фраза про надежные ДЦ — звучит по меньшей мере странно, ДЦ, которые не падали целиком — на планете можно пересчитать по пальцам.
А Ариста классная… хотеть такую вместо домашнего свича :) Как она в боевых условиях?
>>Для централизованного управления и мониторинга используется Parallels Virtual Automation (PVA), интегрированная с Cloud Server. В сферу ответственности PVA входит управление и мониторинг физических серверов: добавление, группировка, вывод из эксплуатации, управление пулами IP–адресов, бекапы управляющих хостов, мониторинг в реальном времени ресурсов каждого физического сервера.
Насколько я знаю, PVA не умеет бэкапить управляющую хост-ноду… Да и ведь у PSC:S нет точки отказа? И «функция» мониторинга тоже весьма сомнительна, так как нет никакой системы оповещения…
Насколько я знаю, PVA не умеет бэкапить управляющую хост-ноду… Да и ведь у PSC:S нет точки отказа? И «функция» мониторинга тоже весьма сомнительна, так как нет никакой системы оповещения…
У Parallels Cloud Storage нет единой точки отказа. Отказать может управляющий хост, который бекапируется. Он не является частью Cloud Storage и не влияет на сохранность данных пользователей. Мы используем не просто Cloud Server + Storage, а PACI + дополнительные собственные инструменты.
Есть, это софт. Одинаковая копия софта с одинаковыми багами, работающая на всех узлах. Возникает условие (високосная секунда, 30 февраля, просто «так байты сложились») — и вся конструкция складывается. Синхронно.
1. Софт проходит тщательное тестирование и в Parallels и у нас
2. ПО обновляется не синхронно на всех хостах. Есть возможность раннего обнаружения проблем до их влияния на пользователей.
3. Есть возможность бекапа вне Cloud Storage для пользователей.
4. Мы не обновляем одновременно обе локации.
5. Точка отказа все-таки есть — планета Земля. В данном случае речь идет про возможность выхода из строя оборудования и надежной работы при этом.
Люди не идеальны и не научились создавать идеальные вещи и технологии в принципе, но научились делать вычислительные системы гораздо более надежными, чем раньше.
2. ПО обновляется не синхронно на всех хостах. Есть возможность раннего обнаружения проблем до их влияния на пользователей.
3. Есть возможность бекапа вне Cloud Storage для пользователей.
4. Мы не обновляем одновременно обе локации.
5. Точка отказа все-таки есть — планета Земля. В данном случае речь идет про возможность выхода из строя оборудования и надежной работы при этом.
Люди не идеальны и не научились создавать идеальные вещи и технологии в принципе, но научились делать вычислительные системы гораздо более надежными, чем раньше.
Софт проходит бла-бла-бла. Извините, но мы все помним, как vmware выключила нафиг все виртуалки у всех клиентов из-за бага в сервере лицензий.
При обновлении обновляется микроскопическая часть кода. Большая часть кода не меняется годами — и баги там могут жить тоже годами и десятилетями. Например, недавно был устранён баг в BSD (в той самой, первой), который существовал 20+ лет.
Я же говорил про другое: у любой кластерной системы есть фатальная проблема — это синхронные ошибки в синхронном коде.
Так что говорить про отсутствие единой точки отказа не стоит. «Нет единой точки отказа в оборудовании» — больше поверю.
При обновлении обновляется микроскопическая часть кода. Большая часть кода не меняется годами — и баги там могут жить тоже годами и десятилетями. Например, недавно был устранён баг в BSD (в той самой, первой), который существовал 20+ лет.
Я же говорил про другое: у любой кластерной системы есть фатальная проблема — это синхронные ошибки в синхронном коде.
Так что говорить про отсутствие единой точки отказа не стоит. «Нет единой точки отказа в оборудовании» — больше поверю.
Stray bug crashes one node after the other:
А как балансировка нагрузки выполнена? (https)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Облачная инфраструктура InfoboxCloud запущена в Амстердаме. Технические детали инсталляции