Если перевести коротко:
— heartbeat надо использовать, когда у вас требование «сервис доступен максимум на одном узле»
— keepalived надо использовать, когда «сервис доступен минимум на одном из узлов»
Мультикаст используется для автоматического обнаружения узлов в сети. Например JBoss использует его для автоматического обнаружения других узлов кластера. В амазоне мультикаст выключен и приходится выделять сервер, который выступает в роли связующего.
Другой вариант — на этапе запуска определять какие уже узлы запущены и связываться с ними, но потом эту информацию надо обновлять периодически в приложении.
Вы ниже писали, что проблемы при обновлении не покрываются SLA. Так что это не обязательно преимущество.
Особо смысла нет в споре IaaS vs PaaS. Везде свои преимущества, главное выбирать наиболее подходящий вариант для конкретного проекта. Но в каждом из подходов надо правильно «готовить» образ, пакет и т.д.
Это проблема, если держать сервис вшитым в образ. Если использовать модель деплоя сервиса при старте, то, мне кажется, это решит проблему. Именно так делали мы:
1. Собирали образ со всеми библиотеками, настройками, app-сервером
2. При старте сервиса загружали архив с кодом и уже его разворачивали.
Возможен другой вариант, когда деплой делается тем актором, который запускает инстанс.
Хм, поясню свою мысль.
Возьмём, например, конференцию 2010 года: zfconf.org.ua/conf-2010/category/topics/ первый доклад «Встречайте Zend Framework 2.0».
Примерно с тех пор я перестал встречать ZF1, но зато о ZF2 писали везде.
При REPEATABLE READ чтение «заносится в буфер» и все последующие обращение возвращают одинаковый результат
При READ COMMITED и READ UNCOMMITTED каждый запрос возвращает свежий результат
Выглядит круто. Но пугает одно Но: допустим у меня есть нагрузка в 2кк клиентов и она распределена между 2мя серверами. Что будет если один из них внезапно умрёт? Ведь 1кк клиентов придут на 2й сервер, причём сразу — 1кк одновременных попыток соединений. На установку соединения ведь необходимо время, а значит второй сервер будет не доступен до тех пор, пока все соединения не будут установлены/отброшены. Что будет в продакшене? 1кк соединений конечно хорошо, но может лучше 10 по 100к и равномерное размазывание нагрузки с упавшего сервера?
Пол года пользуюсь такими — доволен аки слон! Если нужен высотомер, то нужно калибровать каждый день или даже чаще, но от этого деться поможет только gps.
Очень не хватает одной функции автоматической блокировки барометра/альтиметра в зависимости от движения.
Пару месяцев назад гулял в этих местах. Дал себе слово, что если не я, то мои дети будут учиться в таком университете. Когда приехал в «родной» политех, стало совсем грустно.
Даже если бы не было кеша первого уровня, то результат зависит ещё и от уровня изоляции в БД.
Если уровень изоляции Repeatable read или Serializable, то даже с отключенным кешем первого уровня вы получите одни и те же данные в одной транзакции, но разные в разных транзакциях.
Спасибо за хорошую информацию на русском.
Эх… есть одна хорошая статья на эту же тему, но в новом дизайне блога её как-то сильно «поплющило» :( acupof.blogspot.com/2008/01/background-hibernate-comes-with-three.html
Много полезной информации в самом MindMap'е, но текст с картинок сейчас абсолютно не читаем.
Возможно у кого-то осталась старая версия?
Если перевести коротко:
— heartbeat надо использовать, когда у вас требование «сервис доступен максимум на одном узле»
— keepalived надо использовать, когда «сервис доступен минимум на одном из узлов»
Другой вариант — на этапе запуска определять какие уже узлы запущены и связываться с ними, но потом эту информацию надо обновлять периодически в приложении.
Используете ли вы что-то подобное?
Насколько удобно использовать его для переключения сервиса между AZ, регионами?
Что используете для замены multicast?
Особо смысла нет в споре IaaS vs PaaS. Везде свои преимущества, главное выбирать наиболее подходящий вариант для конкретного проекта. Но в каждом из подходов надо правильно «готовить» образ, пакет и т.д.
1. Собирали образ со всеми библиотеками, настройками, app-сервером
2. При старте сервиса загружали архив с кодом и уже его разворачивали.
Возможен другой вариант, когда деплой делается тем актором, который запускает инстанс.
Возьмём, например, конференцию 2010 года: zfconf.org.ua/conf-2010/category/topics/ первый доклад «Встречайте Zend Framework 2.0».
Примерно с тех пор я перестал встречать ZF1, но зато о ZF2 писали везде.
Ведь написано, что режим SERIALIZABLE.
Пол года пользуюсь такими — доволен аки слон! Если нужен высотомер, то нужно калибровать каждый день или даже чаще, но от этого деться поможет только gps.
Очень не хватает одной функции автоматической блокировки барометра/альтиметра в зависимости от движения.
Если уровень изоляции Repeatable read или Serializable, то даже с отключенным кешем первого уровня вы получите одни и те же данные в одной транзакции, но разные в разных транзакциях.
Эх… есть одна хорошая статья на эту же тему, но в новом дизайне блога её как-то сильно «поплющило» :(
acupof.blogspot.com/2008/01/background-hibernate-comes-with-three.html
Много полезной информации в самом MindMap'е, но текст с картинок сейчас абсолютно не читаем.
Возможно у кого-то осталась старая версия?