Что происходит при сбоях серверов в облачных сервисах

Основная цель облачной архитектуры заключается в создании и поддержании такой среды, в которой "падение" любого из серверов приложений, в принципе, большого значения не имеет. Если у вас есть только один сервер, то его сбой, очевидно, будет иметь определенное значение, но это событие все равно будет менее значимым, нежели утрата физического сервера.

Чтобы обойти проблемы, описанные в предыдущем разделе, иногда применяют такой прием, как сегментация данных (data segmentation), известный также как разделение данных на уровне ресурсов или шардинг (sharding)1. На рис. 4.3 показан пример сегментации данных с целью распределения обработки по множеству серверов приложений.

Иными словами, каждый сервер приложений будет управлять подмножеством данных. В результате этого вы устраняете риск того, что какой-нибудь другой сервер выполнит перезапись данных. Хотя сегментация и нашла применение в масштабируемых приложениях, но она не должна применяться на серверах приложений в облачном кластере. Дело в том, что сегментированный сервер приложений получит очень низкий рейтинг доступности, потому что сбой любого отдельного сервера приложений имеет значение.

Наконец, заключительный вывод ко всему сказанному о статусе приложения и о сбоях серверов будет звучать так: серверы приложений в облачной среде не могут хранить никаких данных о статусе кроме кэшированных данных. Иными словами, если вы должны выполнять резервное копирование сервера приложений, это значит, что вам не удалось разработать надежную архитектуру приложения для работы в облачной инфраструктуре.

1 Шардинг (sharding) — это разделение данных на уровне ресурсов. Концепция шардинга заключается в логическом разделении данных по различным ресурсам исходя из требований к нагрузке.

Подробнее см. http://www.codefutures.com/database-sharding/, http://tinyurl.com/yanw837, http://tinyurl.com/2vbkhhv. — Прим. перев.

Вся информация о статусе, включая двоичные данные, принадлежит базе данных, которая должна находиться в постоянном хранилище1.

Рис. 4.3. Поддержание различных отелей на различных серверах позволяет избежать проблемы двойного бронирования

1 Если вы читали мою статью "Ten MySQL Best Practices" (http://www.onlamp.com/pub/a/onlamp/ 2002/07/11/MySQLtips.html), то вы наверняка заметите противоречие между тем, что я не советовал хранить двоичные данные в MySQL, и тем, что я рекомендую здесь. Вы действительно должны кэшировать двоичные данные на сервере приложений, чтобы вам не требовалось извлекать (pull) их с сервера базы данных в режиме реального времени. Поступая так, вы обходите мои возражения против хранения двоичных данных в MySQL.

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100