Там свои прибамбасы, но в целом стабильно. Инстансы пошустрее чем у Амазона, быстрее I/O дисков, меньше шума от соседей, больше перков. У Амазона намного лучше API.
Единственное, что меня раздражает, так это политика компании. Могут позвонить и сказать: «Мы вас выключаем потому, что вы генерируете большую нагрузку. Как починим – вернем.» А все почему? Да потому, что основная масса там – обычные сайты, и дабы не гневить народ, вырубают выборочно. А причина обычно в железе, которое установили или еще что-то они там делают. С этой точки зрения Амазон намного круче для бизнеса, вот и при первом же таком заявлении, мы сказали Рэкспейсу «Bye-bye.»
Тут-то, к слову, при переезде поняли, что не стоит опираться на фичи клауда.
не поймите меня неправильно, мы живем в Амазоне, но используем его более как computational power. Это позволяет в любой момент сказать «Давай, до свидания!» или же иметь дополнительную зону в другом клауде, например RackSpace.
Еще одним моментом отказоустойчивости, не указанный в данном переводе по понятным причинам, является использование простых и общедоступных технологий. В этот список входят все перки Amazon: ELB, Route53, EBS, SQS и прочая, прочая, прочая. Имея собственные методы скейлинга и распределения нагрузки, деплой во множественных регионах с GeoDNS и системами leader election (например Zookeeper) можно использовать только процессорные мощности клауда, причем не только Amazon.
Помните прошлогоднее падение EBS? Ну и что вы будете делать если инстанс грузится с EBS?
А что делать если ELB неожиданно перестал добавлять сервера в пул и убирать мертвые? Сам видел не раз.
Видели как ЧУЖОЙ ELB заруливает 4K req/sec трафика к вам на сервера? А я видел.
ELB вообще не гарантирует работу с вебсерверами кроме Apache2, nginx, IIS. Так что только reverse proxy, а это еще задержки и еще одно звено к поломке.
А бесконечные «connectivity issues in region»?
Все эти замечательные технологии замечательны при 2-х условиях: пока они работают без сбоев, и пока вам не надо переезжать куда-то еще. Ничто так не опасно как видимость безопасности.
На своем более чем 3-х летнем опыте построения мультирегиональных высоконагруженных и высокодоступных систем в клаудах, я бы посоветовал строить простые системы с наименьшим количеством звеньев и как можно меньшим числом проприетарных технологий.
Тут я еще одну вещь подумал. Решение на своем сервере снижает стабильность и I/O. Все таки большое количество отдельных серверов и redundancy n+1(2) выгоднее.
Как бы получается, что реальное использование Тарантула больше подходит в качестве поддержки RDBMS и работе напрямую с клиентом. Строить на нем большой кластер данных в облаке(!!!) будет сложно в силу проблем балансировки и распределения данных между серверами внутри аппликейшена. Но если есть свои сервера, то проблема отпадает.
1) Она происходит автоматически или вручную надо запускать процесс?
2) Доступен ли при балансировке кластер?
3) Видят ли кластеры друг друга, чтобы балансировать между инстансами(физическими серверами) в кластере?
и еще один вопрос по другой теме, если можно.
Почему выбор остановился в пользу корутинных таскеров вместо трединга?
Как бы, единственным приемуществом я вижу ликвидацию головомороки с thread-safe writing. Может я упускаю еще какую-то выгоду…
> оффлайн
Вот я и говорю, что можно использовать как кэш какой-то runtime data (если RAM не хватает). Не вижу связи с кэшированием запросов к серверу. Сервер всегда выдает актуальные данные и конфигурируется запросом (это ожидается). Какой смысл кешировать данные с ключом запроса? Что это за мини-memcache? Фишка в том что кеширует по строке запроса, а это впринципе неправильно, если ваша аппликуха зовет один и тот же урл много раз в своем процессе. Это какие-то костыли из-за недостатка навыка в разработке high avalability.
> А что, если я сегодня посчитал числа фибоначи до миллиона, то завтра мне это уже точно не потребуется? :)
А что если юзер оборвет сессию не дав сохранить? Зависнет броузер, blue death screen?
Просчитайте один раз на backend до 64-битного значения, загрузите на сервер в таблицу, сделайте индексацию, пагинатор с продолжением просчетов. Если же процесс не детерминистичен, то есть другие способы.
Прошу прощения, но я вижу в этом неумение строить вещи нормальным путем. А ограничения localStorage и security issues сводят метод на нет. Грубо говоря, вы пытаетесь использовать расширеные куки под кэш. Было бы нормально, если это кэш какой-то runtime data или сделать данные доступными между вкладок, но не запросов…
> Полученный кэширующий слой легко применить, например, к ресурсоемким повторяющимся операциям
а бутылочное горлышко не в доступе к данным, а в самих операциях. Ресурсоемкие операции не выполняются на стороне юзверя. Докиньте виджеты, плагины jQuery, Flash, canvas, 50 вкладок,- и больше нет места на ресурсоемкие операции. Надо рассматривать вопрос как получилось так, что операциям нужны одни и те же данные N раз.
Единственное, что меня раздражает, так это политика компании. Могут позвонить и сказать: «Мы вас выключаем потому, что вы генерируете большую нагрузку. Как починим – вернем.» А все почему? Да потому, что основная масса там – обычные сайты, и дабы не гневить народ, вырубают выборочно. А причина обычно в железе, которое установили или еще что-то они там делают. С этой точки зрения Амазон намного круче для бизнеса, вот и при первом же таком заявлении, мы сказали Рэкспейсу «Bye-bye.»
Тут-то, к слову, при переезде поняли, что не стоит опираться на фичи клауда.
Помните прошлогоднее падение EBS? Ну и что вы будете делать если инстанс грузится с EBS?
А что делать если ELB неожиданно перестал добавлять сервера в пул и убирать мертвые? Сам видел не раз.
Видели как ЧУЖОЙ ELB заруливает 4K req/sec трафика к вам на сервера? А я видел.
ELB вообще не гарантирует работу с вебсерверами кроме Apache2, nginx, IIS. Так что только reverse proxy, а это еще задержки и еще одно звено к поломке.
А бесконечные «connectivity issues in region»?
Все эти замечательные технологии замечательны при 2-х условиях: пока они работают без сбоев, и пока вам не надо переезжать куда-то еще. Ничто так не опасно как видимость безопасности.
На своем более чем 3-х летнем опыте построения мультирегиональных высоконагруженных и высокодоступных систем в клаудах, я бы посоветовал строить простые системы с наименьшим количеством звеньев и как можно меньшим числом проприетарных технологий.
Как бы получается, что реальное использование Тарантула больше подходит в качестве поддержки RDBMS и работе напрямую с клиентом. Строить на нем большой кластер данных в облаке(!!!) будет сложно в силу проблем балансировки и распределения данных между серверами внутри аппликейшена. Но если есть свои сервера, то проблема отпадает.
2) Доступен ли при балансировке кластер?
3) Видят ли кластеры друг друга, чтобы балансировать между инстансами(физическими серверами) в кластере?
и еще один вопрос по другой теме, если можно.
Почему выбор остановился в пользу корутинных таскеров вместо трединга?
Как бы, единственным приемуществом я вижу ликвидацию головомороки с thread-safe writing. Может я упускаю еще какую-то выгоду…
Заранее спасибо
s4nch3z.me
Вот я и говорю, что можно использовать как кэш какой-то runtime data (если RAM не хватает). Не вижу связи с кэшированием запросов к серверу. Сервер всегда выдает актуальные данные и конфигурируется запросом (это ожидается). Какой смысл кешировать данные с ключом запроса? Что это за мини-memcache? Фишка в том что кеширует по строке запроса, а это впринципе неправильно, если ваша аппликуха зовет один и тот же урл много раз в своем процессе. Это какие-то костыли из-за недостатка навыка в разработке high avalability.
> А что, если я сегодня посчитал числа фибоначи до миллиона, то завтра мне это уже точно не потребуется? :)
А что если юзер оборвет сессию не дав сохранить? Зависнет броузер, blue death screen?
Просчитайте один раз на backend до 64-битного значения, загрузите на сервер в таблицу, сделайте индексацию, пагинатор с продолжением просчетов. Если же процесс не детерминистичен, то есть другие способы.
Короче, хватит мракобесить :)
> Полученный кэширующий слой легко применить, например, к ресурсоемким повторяющимся операциям
а бутылочное горлышко не в доступе к данным, а в самих операциях. Ресурсоемкие операции не выполняются на стороне юзверя. Докиньте виджеты, плагины jQuery, Flash, canvas, 50 вкладок,- и больше нет места на ресурсоемкие операции. Надо рассматривать вопрос как получилось так, что операциям нужны одни и те же данные N раз.
МАСТЕРСКИ
хотя это все зависит от вашей архитектуры
пилим нормальный деплой через SVN и байбай EBS