Comments 12
Молодцы. В деле не проверял, но на словах все красиво. Не совсем понятно только как будет весьти себя приложение (веб-сайт например) при отказе основной реплики — очень туманно написано о переподключении в течении 30 секунд.
Реконфигурация происходит не только в случае ошибки, но и в случае обновления SQL Server'а (физического) и т.п. поэтому все происходит в течение 30-60 секунд. Кстати, есть статья с более подробным техническим описанием о том, как все это работает в хранилище Windows Azure (не в SQL Database) — Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency (en, pdf).
Документации это хорошо, но читать лень :)
Тем более там будет так же загадочно написано как и тут — без конкретики.
Интересует конкретный пример что будет на фронтенде приложения в моменты реконфигурации или сбоя основной реплики.
Тем более там будет так же загадочно написано как и тут — без конкретики.
Интересует конкретный пример что будет на фронтенде приложения в моменты реконфигурации или сбоя основной реплики.
Статья приведенная все-таки не просто документация, а изложение научных и практических изысканий, которые применены в Windows Azure.
Что касается того, что произойдет, то SQL Server вернет исключение (если запрос поступит в этот «30 секундный» интервал), что так и так, но выполнить операцию не могу (+ код ошибки и описание).
И для облачных DaaS баз это нормально, т.к. для них при проектировании применяется принцип логики повторов (об это во второй части статьи как раз буду говорить).
Или вот здесь (Фрагмент книги: «To the Cloud: Cloud Powering an Enterprise») описаны принципы для облачной разработки: "<...>разработчики в своем приложении обязательно должны предусматривать логику повторных попыток соединения и выполнения запросов (retry logic). Например, компонент, который запрашивает данные из другого источника, может включать логику, которая повторяет попытки получения данных указанное число раз в течение фиксированного периода времени <...>"
Что касается того, что произойдет, то SQL Server вернет исключение (если запрос поступит в этот «30 секундный» интервал), что так и так, но выполнить операцию не могу (+ код ошибки и описание).
И для облачных DaaS баз это нормально, т.к. для них при проектировании применяется принцип логики повторов (об это во второй части статьи как раз буду говорить).
Или вот здесь (Фрагмент книги: «To the Cloud: Cloud Powering an Enterprise») описаны принципы для облачной разработки: "<...>разработчики в своем приложении обязательно должны предусматривать логику повторных попыток соединения и выполнения запросов (retry logic). Например, компонент, который запрашивает данные из другого источника, может включать логику, которая повторяет попытки получения данных указанное число раз в течение фиксированного периода времени <...>"
Спасибо.
Думаю эту логику повторов логично реализовать в драйвере (библиотеке .net) работы с базой, а программисту дать возможность конфигурирования через web/app.config.
Думаю эту логику повторов логично реализовать в драйвере (библиотеке .net) работы с базой, а программисту дать возможность конфигурирования через web/app.config.
Есть примеры реализаций как настраиваемого компонента (Best Practices for Handling Transient Conditions in SQL Azure Client Applications), что, правда, не есть уровень драйвера, но может упростить жизнь.
Довольно интересно. А где находятся все эти вкусности, и какой будет пинг до базы от сервера в Москве?
вы можете выбрать одно из 8 местоположений (регионов) в разных точках мира:
SQL Database [East Asia]
SQL Database [East US]
SQL Database [North Central US]
SQL Database [North Europe]
SQL Database [South Central US]
SQL Database [Southeast Asia]
SQL Database [West Europe]
SQL Database [West US]
по поводу ping: все зависит от вашего местоположения и многих других факторов, необходимо смотреть индивидуально
еще полезная ссылка — мониторинг состояния служб Windows Azure, можно отслеживать как работает конкретный регион www.windowsazure.com/ru-ru/support/service-dashboard/
SQL Database [East Asia]
SQL Database [East US]
SQL Database [North Central US]
SQL Database [North Europe]
SQL Database [South Central US]
SQL Database [Southeast Asia]
SQL Database [West Europe]
SQL Database [West US]
по поводу ping: все зависит от вашего местоположения и многих других факторов, необходимо смотреть индивидуально
еще полезная ссылка — мониторинг состояния служб Windows Azure, можно отслеживать как работает конкретный регион www.windowsazure.com/ru-ru/support/service-dashboard/
Зарегистрировался, создал пробную БД, замучился уже с этим интерфейсом — не знаю из-за чего, но ввод с клавиватуры в интерфейсе управления базами не работает. Имена баз, столбцев и прочую информацию приходится копипастить из текстовго редактора (набирая ее там).
MacBook (OSX 10.6), Chrome
MacBook (OSX 10.6), Chrome
Интересно замечание, надо будет провести эксперимент.
Как альтернатива порталу управления есть SQL Server Management Studio (но это для Windows ОС). На данный момент портал управления SQL Database — это Silverlight, тогда как основной портал Windows Azure был — это HTML5. Возможно, что плагин Silverlight можно обновить.
Как альтернатива порталу управления есть SQL Server Management Studio (но это для Windows ОС). На данный момент портал управления SQL Database — это Silverlight, тогда как основной портал Windows Azure был — это HTML5. Возможно, что плагин Silverlight можно обновить.
Про пинг ситуация следующая:
1. Большинство решений\приложений напрямую не опрашивают SQL Database, чаще это делает облачная служба, размещенная в Windows Azure. Тогда это получается (если не выбрать разные дата-центы) один дата-центр. И все быстро.
2. Если все-таки опрос идет с клиента, то само время выполнения запроса может варьироваться (т.к. пока нет возможности «гарантировать\зарезервировать» под себя ресурсы SQL Database), следовательно, в общем времени получения ответа на клиент будет, как минимум, два фактора: время выполнения запрос + время передачи по сети (сетевая задержка). Вот пример измерения времени выполнения запроса для SQL Database. Есть различные статьи, где измеряется задержка (Exploring Windows Azure Network Latency). И даже пример решения (поисковые подсказки) (в таблице представлены цифры для ответа всего решения, а не просто ping пакетами) — Windows Azure-Hosted Services: What to expect of latency and response times from services deployed to the Windows Azure platform).
1. Большинство решений\приложений напрямую не опрашивают SQL Database, чаще это делает облачная служба, размещенная в Windows Azure. Тогда это получается (если не выбрать разные дата-центы) один дата-центр. И все быстро.
2. Если все-таки опрос идет с клиента, то само время выполнения запроса может варьироваться (т.к. пока нет возможности «гарантировать\зарезервировать» под себя ресурсы SQL Database), следовательно, в общем времени получения ответа на клиент будет, как минимум, два фактора: время выполнения запрос + время передачи по сети (сетевая задержка). Вот пример измерения времени выполнения запроса для SQL Database. Есть различные статьи, где измеряется задержка (Exploring Windows Azure Network Latency). И даже пример решения (поисковые подсказки) (в таблице представлены цифры для ответа всего решения, а не просто ping пакетами) — Windows Azure-Hosted Services: What to expect of latency and response times from services deployed to the Windows Azure platform).
Sign up to leave a comment.
Обзор архитектуры и обеспечения высокой доступности в SQL Database (SQL Azure)