Comments 12
Понимаю, что это общая для всех облачных провайдеров тема. Но кто конкретно вас так разочаровал? Azure или кто то другой?
Мне кажется, речь идет о проблеме «курицы и яйца»:
Чтобы обеспечить «горячее» переключение при отказе узла на другой (избыточный), необходим узел «верхнего уровня», который прозводит мониторинг и непосредственно переключение (load balancer или кто-то подобный).
Указаная «отказонеустойчивость» описана именно среди узлов таких «load balance»-ов. Т.е, нужен «load balancer» для «load balancer»-ов. А соответственно, он ведь тоже может отказать, и тогда…
Вот и не хотят делать «бесконечную рекурсию».
Чтобы обеспечить «горячее» переключение при отказе узла на другой (избыточный), необходим узел «верхнего уровня», который прозводит мониторинг и непосредственно переключение (load balancer или кто-то подобный).
Указаная «отказонеустойчивость» описана именно среди узлов таких «load balance»-ов. Т.е, нужен «load balancer» для «load balancer»-ов. А соответственно, он ведь тоже может отказать, и тогда…
Вот и не хотят делать «бесконечную рекурсию».
Для этого есть ансамбли конфиг серверов, которые знают друг о друге и сообщают о том же клиенту. Например, у вас может быть 3 конфиг сервера, которые знают друг про друга и, при соединении от клиента, отдают ему весь список. Если один из конфиг серверов падает, клиент тут же перенаправляет запросы на другой. Ну а конфиг сервера уже могут держать любую необходимую клиенту для бесперебойной работы информацию (например, список лоад балансеров).
Из опен сорса для этого есть, например, ZooKeeper, который предоставляет древовидную структуру для сохранения конфигов.
Из опен сорса для этого есть, например, ZooKeeper, который предоставляет древовидную структуру для сохранения конфигов.
В описанной вами системе присутствует зависимость «клиент знает о лоад балансере(ах), которые его обслуживают», а это не всегда возможно. Например, в AWS у клиента может не быть ни малейшего понятия где он и почему запрос пришел именно к нему.
Что вы подразумеваете под клиентом? Я говорю о клиенте, который обращается к сервису, например, мобильный клиент твиттера или сайт, обращающийся к базе MongoDB.
Под клиентом я имел ввиду «клиента» лоад балансера, т.е web server или processing unit сети типа MapReduce.
А, вы про бек-енд. В общем-то, на бек-енде архитектура может быть вообще другой (те же processing units в MapReduce как правило пассивные, и управляются они центральным мастером), но даже если таким «клиентам» нужен центральный лоад-балансер, то не вижу причин реализовать его по той же схеме, что я описал выше. Т.е. если клиент хоть раз контачит с центральным сервером, то нет никаких приград отдать клиенту список резервных центральных серверов. Или я вас опять неправильно понял?
Я про пассивное управление и говорю. При этом часто управляющий элемент знает своих «подчиненных», а они его — нет, так что выбирать кого-либо они не могут (отношения «caller -> callee»).
К примеру, живет себе web сервер (только что созданный из темплейта — так называемый «instance on demand») и в ус не дует — он и знать не знает что запросы к нему приходят не из внешнего интернета, а через прокси/лоад балансер
К примеру, живет себе web сервер (только что созданный из темплейта — так называемый «instance on demand») и в ус не дует — он и знать не знает что запросы к нему приходят не из внешнего интернета, а через прокси/лоад балансер
Да, вот сегодня у Windows Azure проблемы, уже часа 3, с WebSites расположенными в West Europe.
www.windowsazure.com/en-us/support/service-dashboard/
www.windowsazure.com/en-us/support/service-dashboard/
> Почему же нет SLA к сервису управления? Можно только предполагать.
Потому что, как любят говорить разработчики таких сервисов, они делают только некий пульт управления с кнопками, а реакция на нажатие кнопки — это уже SLA исполнительного органа, т.е. самого «облака». И, мол, они не видят смысла «зуб давать» за работу своей системы управления, т.к. между нею и облаком разные еще прослойки, задержки, и предсказать им, как разработчикам, ничего решительно невозможно.
Правда, это все по-детски выглядит, конечно.
Потому что, как любят говорить разработчики таких сервисов, они делают только некий пульт управления с кнопками, а реакция на нажатие кнопки — это уже SLA исполнительного органа, т.е. самого «облака». И, мол, они не видят смысла «зуб давать» за работу своей системы управления, т.к. между нею и облаком разные еще прослойки, задержки, и предсказать им, как разработчикам, ничего решительно невозможно.
Правда, это все по-детски выглядит, конечно.
Sign up to leave a comment.
Итак, вы пытаетесь оценить надежность своего облачного сервиса