Построение гибридных приложений в облаке на платформе Windows Azure patterns & practices



Pdf просмотр
страница16/33
Дата28.11.2016
Размер8.44 Mb.
Просмотров6436
Скачиваний0
1   ...   12   13   14   15   16   17   18   19   ...   33
Мнение Джаны
Полная синхронизация по всем направлениям, в которой задействованы все участвующие в репликации реляционные базы данных, может представлять собой весьма ресурсоемкую операцию. Неизбежные задержки, связанные с передачей и выполнением большого числа изменений на целом ряде узлов, могут привести к тому, что некоторые данные, содержащиеся в одной или нескольких базах данных, будут несогласованны между собой до тех пор, пока полная синхронизация не завершится. Чтобы свести к минимуму задержки и ресурсы, необходимые для синхронизации баз данных, вам следует тщательно проанализировать ситуацию и определить, какие данные ваши приложения и службы должны реплицировать, могут ли ваши приложения и службы работать с потенциально устаревшими данными, и какие данные должны быть доступны только для чтения на каждом узле.

Каковы ожидаемые объемы данных, подлежащих синхронизации? В случае наличия большого количества изменчивых данных, репликация каждой операции вставки, обновления и удаления может привести к слишком интенсивной нагрузке на сеть и вычислительные мощности. Это негативно отразится на производительности каждого источника данных, и, возможно, сведет на нет преимущества, ради которых репликация данных, в первую очередь, и была организована. В топологии В, например, если каждая облачная служба выполняет большое количество обновлений, поддерживать копию массива данных в облаке будет слишком сложно с точки зрения производительности.

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

222
Взаимосвязанные проблемы
Эффективность репликации данных в большой степени зависит от параметров сети с точки зрения безопасности, надежности и производительности. Системные требования и особенности реализации приложений также могут оказывать существенное влияние на эффективность выбранного вами подхода к репликации. В следующих разделах возможные проблемы рассматриваются подробнее.
Безопасность доступа к данным
Каждый источник данных, будь то БД SQL Azure или другие хранилища, должен обеспечивать защиту информации, которая в нем содержится, и предотвращать несанкционированный доступ. Это требование применяется к процессу синхронизации, а также стандартному циклу доступа к данным.
Сетевые пакеты с подлежащими репликации данными также должны быть защищены, поскольку нарушение политики безопасности на этом уровне может привести к распространению поврежденной информации в несколько экземпляров важных элементов данных.
Согласованность данных и время отклика приложений
Согласованность данных и время отклика приложений — противоречивые требования, которые необходимо сбалансировать, чтобы удовлетворить потребности пользователей.
Если необходимо обеспечить высокий уровень согласованности всех задействованных в процессе репликации баз данных, следует принять меры, не позволяющие конкурирующим приложениям получать доступ к данным, которые находятся в состоянии изменения на одном из узлов системы. Такой подход зависит от логики приложения для блокировки элементов данных и их копий перед внесением в них изменений. После завершения обновления блокировка снимается. Когда данные заблокированы, никакие другие приложения не могут получить к ним доступ, что отрицательно сказывается на скорости отклика системы с точки зрения пользователей. Как уже отмечалось ранее в данном приложении, в рамках многих распределенных систем немедленная и абсолютная согласованность данных может быть не так важна, как поддержание высокой скорости отклика приложений. Пользователи системы хотят быстро выполнять необходимые операции, а поскольку информация не теряется и в конечном итоге согласовывается, такой подход они сочтут удовлетворительным.
Целостность и надежность
Даже если это решение, для которого немедленное обеспечение целостности данных не является критическим требованием, в системе в любом случае должна быть предусмотрена надежная процедура обновления данных с целью поддержания целостности информации. Например, в приложении Orders, о котором мы говорили ранее, заказ должен быть выполнен, если система приняла его от клиента.
Данные, указанные при размещении заказа, не должны быть утеряны, и процесс обработки и выполнения заказа должен быть завершен. Именно поэтому в любом решении, которое осуществляет репликацию данных между различными БД, должен быть реализован надежный механизм транспортировки и обработки этих данных. Если возник сбой какого-либо компонента системы синхронизации, необходимо предусмотреть возможность перезапуска этого компонента без потери или дублирования данных.
Мнение По
Необходимо помнить, что сеть является важнейшим компонентом с точки зрения влияния на надежность. Под надежностью решения в данном случае понимается его устойчивость к сбоям в сети.

223
Платформа Windows Azure и связанные с ней технологии
Когда вы осуществляете развертывание баз данных в облаке с помощью SQL Azure, служба SQL Azure
Data Sync поможет вам настроить репликацию и синхронизацию между этими базами данных и базами данных SQL Server, работающими локально. Это облачная служба синхронизации на основе Microsoft
Sync Framework. При помощи портала управления Windows Azure вы сможете быстро настроить самые распространенные сценарии синхронизации между локальными базами данных SQL Server и базами данных SQL Azure, которые работают в облаке. Кроме того, служба SQL Azure Data Sync совместима с платформой Microsoft Sync Framework 2.1, поэтому вы можете использовать пакет Sync Framework SDK для реализации собственной стратегии синхронизации и включения дополнительной логики для проверки, если это необходимо.
Примечание
Решение SQL Azure Data Sync совместимо с SQL Server 2005 Service Pack 2 и более поздними версиями.
Пакет Sync Framework SDK будет полезен в рамках сценариев, подразумевающих внедрение собственного подхода к синхронизации, который невозможно или трудно реализовать с помощью портала управления. Например, вы можете создать свои собственные службы синхронизации для локальных баз данных и мобильных устройств пользователей.
Альтернативный подход заключается в реализации собственного механизма рассылки обновлений в базы данных с использованием системы обмена сообщениями. Приложение-отправитель и приложение-прослушиватель используют специализированную логику для публикации обновлений и синхронизации их с данными на выходе. Топики и подписки шины интеграции предоставляют идеальную инфраструктуру для реализации этого сценария.
В следующих разделах приводятся дополнительные сведения об использовании SQL Azure Data Sync,
Sync Framework SDK, а также топиков и подписок шины интеграции для осуществления репликации в рамках некоторых типичных сценариев.
Репликация и синхронизация при помощи SQL Azure Data Sync
Использование SQL Azure Data Sync для реализации синхронизации в SQL Server обеспечивает многочисленные преимущества, в том числе:

Эластичная масштабируемость. Служба SQL Azure Data Sync работает в облаке и масштабируется автоматически по мере увеличения объема данных и количества узлов, участвующих в процессе синхронизации.

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

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

224

Предварительно настроенные политики обработки конфликтов. Служба SQL Azure Data
Sync позволяет выбрать методы разрешения любых конфликтов, которые были обнаружены во время синхронизации, выбрав одну из множества встроенных политик.

Комплексные функции ведения журналов. SQL Azure Data Sync заносит в журнал записи обо всех событиях и операциях. Портал управления позволяет изучить эту информацию и применить к ней различные фильтры, помогая быстро определить причину возникновения проблем и предпринять необходимые корректирующие действия.
В следующих разделах содержится информация о принципах работы службы SQL Azure Data Sync, а также рекомендации по ее использованию в рамках ряда наиболее распространенных сценариев.
Рекомендации по настройке SQL Azure Data Sync
В процессе настройки SQL Azure Data Sync вы должны принять ряд решений относительно данных, подлежащих репликации, и местоположения соответствующих баз данных. В данном разделе содержатся рекомендации по определению ключевых элементов архитектуры синхронизации.
Создание элементов Sync Group и Sync Dataset
SQL Azure Data Sync организует процесс синхронизации, определяя группу синхронизации (sync group).
Группа синхронизации — это совокупность рядовых баз данных, которые должны быть синхронизированы, включая центральную базу данных, которая выступает в качестве главной точки синхронизации. Все рядовые базы данных, участвующие в топологии, синхронизируются через центральный узел, посылая собственные обновления и получая информацию об изменениях, внесенных другими базами данных.
Параллельно с определением группы синхронизации вы также определяете набор данных
синхронизации (sync dataset) — таблицы, строки и столбцы, подлежащие синхронизации.
Не обязательно выбирать все таблицы в базе данных, также можно определить фильтры для ограничения диапазона строк, которые будут синхронизированы. Тем не менее в каждой таблице, которая участвует в наборе данных синхронизации, должен присутствовать первичный ключ, в противном случае синхронизация невозможна. Кроме того, хотя вы не должны включать каждый столбец из каждой задействованной таблицы, необходимо включить все столбцы, которые не поддерживают пустые значения, иначе синхронизация также не будет выполнена.
Примечание
SQL Azure Data Sync создает триггеры для каждой таблицы в группе синхронизации. Эти триггеры отслеживают изменения, вносимые в данные в каждой таблице в группе синхронизации. Дополнительные сведения о триггерах, создаваемых службой SQL Azure Data
Sync, представлены в разделе «Вопросы использования Azure Data Sync»: http://sqlcat.com/sqlcat/b/technicalnotes/archive/2011/12/21/considerations-when-using-data- sync.aspx
.
Важно понимать, что служба SQL Azure Data Sync накладывает некоторые ограничения на типы столбцов в таблицах, которые участвуют в процессе синхронизации. Эти ограничения связаны с платформой Sync
Framework, на которой основана служба SQL Azure Data Sync. Платформа Sync Framework предназначена для работы с различными системами управления базами данных, а не только SQL Server, и поэтому поддерживаемые типы ограничиваются общими типами для всех основных систем управления базами данных. Например, вы не можете синхронизировать столбцы на основе пользовательских и пространственных типов данных или типов CLR. Полный перечень поддерживаемых

225 и неподдерживаемых типов представлен на странице «SQL Azure Data Sync. Поддерживаемые типы данных SQL Azure Data Types»: http://msdn.microsoft.com/en-us/library/hh667319.aspx
Мнение Маркуса
Если вы попытаетесь включить в создаваемый набор данных синхронизации столбцы с неподдерживаемыми типами данных, эти столбцы будут игнорироваться при копировании.
Мнение Бхарата
Один и тот же набор данных синхронизации применяется глобально для всех рядовых баз данных в группе синхронизации. Вы определяете набор данных синхронизации при добавлении первой рядовой базы данных в группу синхронизации и, если необходимо, таблицы, поддерживающие набор данных синхронизации, будут автоматически добавлены в рядовые базы данных, которые включаются в группу синхронизации в дальнейшем.
Однако, после того как вы определили набор данных синхронизации для группы синхронизации, вы не можете изменить определение этого набора данных. Вы должны будете удалить эту группу синхронизации и создать новую с новым набором данных синхронизации.
Реализация схемы базы данных для рядовых баз данных
В общем случае схема данных, подлежащих репликации, возможно, уже существует в локальной базе данных или базе данных SQL Azure. В ходе развертывания группы синхронизации, если необходимые таблицы отсутствуют в других рядовых базах данных или в центральной БД, служба SQL Azure Data Sync автоматически создаст их на основе определения набора данных синхронизации. В этом случае в процессе развертывания будут создаваться только столбцы, указанные в наборе данных синхронизации, при этом будет добавлен индекс для первичного ключа каждой таблицы. Процесс развертывания значительно упрощает репликацию схемы набора данных синхронизации, однако копия не всегда будет идентична оригиналу из-за различий между SQL Azure и SQL Server.
Кроме того, никакие индексы, помимо индекса, который ссылается на первичный ключ, созданы не будут, и это может оказать влияние на скорость выполнения запросов к полученной после репликации базе данных. Поэтому, чтобы обеспечить абсолютную точность и избежать неожиданных результатов, рекомендуется подготовить SQL-сценарий, содержащий команды, необходимые для создания каждой подлежащей репликации таблицы вместе с соответствующими индексами. Вы можете также определить любые представления и хранимые процедуры, которые могут потребоваться каждой рядовой базе данных, поскольку они не реплицируются автоматически. Вы можете выполнить этот сценарий поочередно для каждой базы данных перед выполнением репликации.
Мнение Маркуса
При помощи таких инструментов, как Microsoft SQL Server Management Studio, вы можете разрабатывать и редактировать SQL-сценарии для создания таблиц, представлений и хранимых процедур для каждой рядовой базы данных. При наличии соответствующих полномочий, вы также можете подключаться к каждой рядовой базе данных с помощью SQL
Server Management Studio и выполнять эти сценарии.

226
Обработка конфликтов синхронизации
В процессе синхронизации служба SQL Azure Data Sync поочередно подключается к каждой рядовой базе данных с целью получения информации об обновленных элементах и затем вносит соответствующие изменения в центральной базе данных. Любые обновления, ранее переданные центральному узлу из другой рядовой базы данных, передаются в эту базу данных и применяются.
Определять и разрешать конфликты следует в центральной базе данных. SQL Azure Data Sync позволяет выбрать одну из двух политик обработки конфликтов:

Приоритет отдается центральному узлу. Если данные в центральной БД уже были изменены, то эти изменения вносятся в соответствующую рядовую базу данных. Фактически, это означает, что доминирует первая рядовая база данных, которая провела синхронизацию с центральной БД.

Приоритет отдается клиенту. Если данные были изменены в рядовой базе данных, то соответствующие изменения вносятся в центральную БД вместо любых предыдущих изменений. В отличие от политики приоритета центрального узла, в этом случае доминирует последняя рядовая база данных, которая провела синхронизацию с центральной БД.
Мнение По
Процесс синхронизации последовательно обращается к каждой рядовой базе данных и осуществляет необходимые обновления с целью синхронизации этой и центральной БД.
Предыдущие базы данных не получат изменения, возникшие в результате синхронизации с последующими базами данных. Полная идентичность рядовых баз данных возможна только после выполнения двух процессов синхронизации в рамках группы синхронизации.
В ходе синхронизации каждый пакет обновлений применяется как транзакция, при этом либо успешно применяются изменения, либо выполняется откат. Однако эти пакетные транзакции не обязательно отражают бизнес-операции, которые выполняются в системе. Например, изменения, внесенные в двух таблицах в результате бизнес-операции, могут попасть в различные пакеты в процессе синхронизации.
Кроме того, каждый процесс синхронизации учитывает только те изменения, которые были действительны в тот момент в каждой базе данных. Если в отношении строки было выполнено несколько обновлений между процессами синхронизации, то только окончательное обновление подлежит репликации, поскольку служба SQL Azure Data Sync не ведет журнал всех изменений, внесенных между процессами синхронизации.
Мнение Бхарата
Следует тщательно продумать политику разрешения конфликтов, поскольку она распространяется на все базы данных в группе синхронизации. Кроме того, необходимо выбрать политику при создании группы синхронизации; ее нельзя изменить, не удалив группу и не создав ее заново.
Обратите внимание, хотя вы можете выбрать политику разрешения конфликтов, вы не можете на данный момент определять порядок, в котором задействованные базы данных синхронизируются с центральной. В идеале, вы должны разрабатывать свое решение таким образом, чтобы свести к минимуму вероятность возникновения конфликтов. В рамках типового сценария распределенные приложения, работающие на разных узлах, как правило, управляют своими подмножествами данных организации, поэтому возможность конфликтов снижается. Помните, что основной целью репликации

227 является распространение обновлений, выполняемых на одном узле, на все другие узлы, чтобы в рамках всей системы сформировать одинаковое представление данных.
Если вы хотите обеспечить максимальную эффективность политики урегулирования конфликтов, можно разделить топологию репликации на несколько групп синхронизации с одной рядовой и одной центральной базой данных. Расписание синхронизации для каждой группы определяет порядок, в котором каждая рядовая база данных будет синхронизироваться с центральной. Для группы синхронизации, включающей рядовую базу данных с высоким приоритетом обновлений, которые должны всегда превалировать, можно выбрать вариант «Приоритет отдается клиенту» для политики урегулирования конфликта, таким образом, эти изменения будут всегда реплицироваться.
Для политики других групп синхронизации может быть выбран вариант «Приоритет отдается центральному узлу», таким образом, изменения, внесенные в базу данных с высоким приоритетом, всегда будут распространяться на другие рядовые базы данных. Эту топологию можно реализовать множеством способов. Например, вы можете разместить несколько рядовых баз данных в группу синхронизации с политикой «Приоритет отдается центральному узлу», если, скорее всего, ни одна из этих баз данных не будет содержать изменения, которые могут конфликтовать друг с другом.
Мнение Маркуса
Чтобы избежать проблем, связанных с конфликтующими значениями первичного ключа, не используйте столбцы с автоматически сгенерированным ключом в реплицируемых таблицах. В качестве альтернативы можно использовать значение, которое точно будет уникальным, например идентификатор GUID.
Конфликты чаще всего возникают в результате двунаправленной синхронизации. Чтобы свести к минимуму вероятность конфликтов, можно настроить одностороннюю репликацию и указать направление синхронизации для каждой рядовой базы данных в группе синхронизации по отношению к центральной базе данных. Дополнительная информация представлена в разделе «Выбор направления синхронизации для базы данных» далее в настоящем приложении.
Рекомендуем обратить особое внимание на определение столбцов в реплицируемых таблицах, поскольку это может оказать значительное влияние на вероятность возникновения конфликта. Например, если вы определяете столбец первичного ключа в реплицируемой таблице при помощи атрибута IDENTITY в SQL Server, то SQL Server автоматически создаст значения для этого столбца в рамках монотонно возрастающей последовательности, которая, как правило, начинается с 1, и для каждой новой строки значение увеличивается на 1. Если строки добавляются в нескольких рядовых базах данных в группе синхронизации, некоторые из этих строк могут иметь одинаковые первичные ключи, в результате чего в ходе синхронизации таблиц возникнет конфликт. В итоге останется только одна строка, остальные будут удалены. Результаты могут быть просто катастрофическими. Если, например, это были заказы разных клиентов, то данные всех этих заказов будут потеряны, поскольку после применения политики разрешения конфликтов в базе данных останется только одна запись!
Чтобы избежать подобных ситуаций, не используйте столбцы с автоматически сгенерированными ключами в реплицируемых таблицах, вместо этого рекомендуется использовать значение, которое точно будет уникальным, например идентификатор GUID.
Определение местоположения и размера центральной базы данных
Центральной должна быть база данных SQL Azure. После синхронизации со всеми рядовыми базами данных, она будет содержать окончательную и самую актуальную версию данных. Местоположение

228 центральной базы данных оказывает существенное влияние на скорость осуществления процесса синхронизации. Вы должны разместить ее в центре обработки данных, который географически расположен ближе всего к наиболее активным рядовым базам данных, независимо от того, облачные это базы или локальные. Это поможет свести к минимуму сетевые задержки, связанные с передачей потенциально больших объемов данных через Интернет. Если ваши базы данных практически равномерно распределены по всему миру, а объем обновлений и трафик запросов примерно одинаков для каждой из них, то рекомендуется разместить центральную БД в центре обработки данных, расположенном как можно ближе к вашим наиболее приоритетным узлам.
Служба SQL Azure Data Sync осуществляет репликацию и синхронизацию данных между вашими БД через центральный узел. Вы можете развернуть один экземпляр сервера SQL Azure Data Sync Server для каждой своей подписки Windows Azure, а также определить регион, где этот сервер будет работать.
В идеале, вы должны разместить этот сервер в том же регионе, в котором планируете развернуть центральную базу данных.
Вы создаете центральную базу данных вручную, и она должна быть, по крайней мере, такого же объема, как самая большая рядовая база данных. SQL Azure в настоящее время не поддерживает автоматическое увеличение баз данных, поэтому если размер созданной вами центральной базы данных окажется недостаточным, служба синхронизации может дать сбой. Также необходимо помнить, что когда вы настраиваете синхронизацию, служба SQL Azure Data Sync создает дополнительные таблицы метаданных в ваших базах данных с целью отслеживания изменений, и вы должны учитывать эти таблицы в процессе определения размера центральной базы данных.
Центральная база данных лежит в основе процесса синхронизации, кроме того, она содержит в точности те же данные, что и любая рядовая база данных SQL Azure в группе синхронизации. Вы можете вставлять, обновлять и удалять данные в этой базе, и эти изменения будут распространены в рамках всей группы синхронизации. В некоторых ситуациях вы можете использовать одну из баз данных SQL Azure, изначально задействованных в группе синхронизации, в качестве центрального узла.
Например, в качестве центральной вы можете выбрать базу данных SQL Azure самого активного узла.
Такая стратегия поможет свести к минимуму задержки, связанные с передачей данных по сети, и тем самым ускорить процесс синхронизации.
Однако все другие рядовые базы данных в группе синхронизации будут периодически синхронизироваться с этой базой данных, и связанная с этими операциями нагрузка может негативно повлиять на производительность этой базы, особенно если таблицы в наборе данных синхронизации содержат сложную совокупность индексов. Вы должны сбалансировать издержки, связанные с тем, что база данных будет выступать в качестве центрального узла для группы синхронизации, с возможной потерей времени на синхронизацию этой базы данных, если центральный узел будет размещен где-то в другом месте.

Каталог: download
download -> Составление простейшей программы в среде lego education. Запуск модели «Обезьянка барабанщица», «Рычащий лев», «Автомобиль»
download -> Функциональные части компьютера, история развития, базовая конфигурация
download -> Компьютер: друг или враг?
download -> Лекция №2 «Теоретические основы игры дошкольника» Зарубежные и отечественные теории игры
download -> Доклад муниципальное образовательное
download -> Литература для воспитанников стр. Приложения стр
download -> Министерство здравоохранения Республики Беларусь
download -> Игра как средство активизации познавательной активности учащихся в ходе изучения темы Алгоритмизация и программирование


Поделитесь с Вашими друзьями:
1   ...   12   13   14   15   16   17   18   19   ...   33


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал