К. Закер - Компьютерные сети. Модернизация и поиск неисправностей (953092), страница 165
Текст из файла (страница 165)
Помимо этого, создание на каждом из четырех серверов реплик только для чтения для остальных трех разделов также хорошая идея (если серверы способны поддержиыть их), так как пользоытели в каждом из офисов ськпуг имать локальный доступ ко всей базе данных ЪПЖ Единственным трафихом службы каталогов, передаваемым по каналам связи глобальной сети, будет трафик синхронизации базы данных. Перемещение по дереву Не имеет значения, сколько разделов и реплик содержит дерево ХЬЯ, а также то, где онн расположены, лля приложений, использующих дерево ХПЗ, оно всегда выпгялит как единая функцнональнал сутдность Каждый сервер, поддерживающий какую-нибудь реплику раздела ХЕгз, работает как сервер инея н может определить местоположение ресурса, представленного любым именем объекта ХЖ.
Запросы имен объектов всегда указывают полное отличаемое имя требуемого ресурса. Когда сервер имен получает запрос, в поисках объекта он сначала проверяет свои собственные разцелы. Если запрашенного обьекта нет в собственных разделах сервера, то его по- иск должен быть произведен на других серверах имен. Процесс осуществле- ниЯ сервером этата поиска называется лераиеГЛевивм иб 6ьуелу::~влвлмй гле лве~ и включЖт в себя методический просмотр разделов на других серверах имен в поисках запрощенного имени. Корневой абигиав"Йждого раздела содержит епиаокиругих разделов, которые яюппотся главными и подчиненными по отношению к нему. Если сервер Распознает любой из контейнеров в запрошеннам:ямани как часть подчиненного раздела, он мажет передать запрос вниз па дереву к соответствующему серверу имен Если сервер имен не способен осуществить такое распознавание„то он должен передать запрос вверх по дереву в направлении к объекту 1КооГ1.
Расположение любого обьекта в дереве может быть определено поиском от объекта ~Ко«4, но это неэффективный метод, так клк он будет перегружать сервер, содержащий раалел 1Коо«1, и, возможно, вызавет множественные задержки, если соединение с этим сервером осущестщщется по медленному каналу связи тпабальной сети. Вместо этого сервер имев обрабатывает запрос, передавая его серверу имен, который является главным лля него в иерархии дерева. Вагам сервер просматривает свай собственные разделы и удовлетворяет эщграс или передает ега либо вниз по дереву своему подчиненному серверу имен, либо вверх следующему главному серверу Фактически сервер имен может распознать один из контейнеров в запрошенном имени и имеет' вгиможность перелать запрос серверу, содержащему правильный Ращел Таким образом, запрос только переаэется по дереву настолько уровней, насколько это необходима, чтобы найти имя.
Для примера,возьмем иерархию серверов имен, показанную на рис 21.7. Прсдполссаим, что приложение посылает серверу О запрос на абьект польЗааатспя басе.СЬГСзяо. Загез. Рааася На Ссрасрс ТЗ С«ящржнт абЪЕКГЫ КОН- тейиера нт.ээз.ез, но не имеет информации о «ысеао.загсе.
Так как раздел, подчиненный серверу В (тлзьае лт заьез на «врвере Р), должен иметь в своем контексте нт. эрез, сервер О, зная аб этом, должен перслщь запрос главному рищелу. Сервер В содержит Раздел загез и раси«инает, чпз зтст контейнер является частью имени ззпрошенного объекта, но он не содержит раздела си.сача затее Тем не менее, сервер В определяет, что сьгсзда.эа1ез должен быть подчиненным по отношению к разделу эрез, поэтому он пере- лает запРос серверу Е, который содержит раздел сьхсечс. затее.
Следовательно, этот сервер мажет обнаружить объект басе. сысадо. эзгез и предоставить требуеьбло щирормацию. В данном конкретном случае разница между испальэомнием процесса перемещения по,дереву и простой отправкой запроса,разделу Дава) загапачается талька в айнам уровне дар~~~, на в разветвленных селях с большим количеством уралней разделов перемещение по дереву может рабатщь намного быстрее, чем запросы к разделу [Коог]. Этот сценарий также предпо- Глава 2ь Служба явтвлсгсв Исвев' латает, что каждый сервер имен падаерживжт только один раздел.
Создание на сервере имен реплик нескольких разделов сокращает количество других серверов, вовлеченных в процесс перемешепия по дереву. ЬвкйГ~ Звьл рис. ЯЗ т разделы Нпаезвльлщ~ т уотммвду обоЙ длл тото, чтобы тдсвлетилллть запросы приложений Сиккронизация ИЮЗ Сообщения, которыми обмениваются серверы имен во время процесса перемещения по дереву, являются только одним из способов взаимодействия различных реплик МЭЗ мсжлу собой. Подобна тому, как приложение может использовзть любом из серверов имен лля лоступа ко всей базе, данных Х0$, администратор, изменяющий базу данных, делает изменения в любой реплике, позволяющей осуществлять зались (то есть в мастер-реплике или любой изменяемой реплике). После внесения изменений они должны быль распространены на все другие реплики этого раздела, чтобы приложения, осушествляклцне доступ к базе данных ХПБ получали одинаковые длиные вне зависимасги от того, какую реплику они используют Зтат процесс называется сивхролизадиея" и отвечает за балылую часть графика, передаваемага межзу серверами имен КОЗ.
О службе каталогов, которая функционируег подобным' образом, говзрят, что'она исйольэует рвявяищвю с лятсзквствь~ж маслирса ~ллгйуй лвзявг гвряслахи4. Это означает, что если реплик несколько, то достаточно сделать иэ- менения в любай:йдной из них. В системе реллвлаяив с сдлим литслщем (атвуда выпал щйзтйсл~, такой как используется доменамй 'ттпийиез'рП'-, все изменения в базе линннх должны бнть произведены в йаной определенной реплике (главном контроллере домена, в %~лбова ХТ), а затем эта система распространяет зти изменения по всем'остальным репликам.
Модель графика репликации в этих лвух системах показана на рис. 21.8. Рис. 21.6. Трафик репликации с одним мастером деижетсе в однюм направлении. в то время лак при репльмации со множеством мастеров взаимодействие между серверами двунаправленное Преимушество репликации со множеспюм мастеров заикючается в том,. *по администраторы могут предпринимать действия по-обслуживанию базы данных в локальной реплике, что предпочтительнее, чем доступ к серверу имен, который мажет быль расположен на значительном рвссгоянни или на другой стороне канала связи глобальной сати.
Недостатком явлвется более сложный процесс репликации. В системе репликацни с одним мастером трафик синхронйавцни распространяется тсльип ъ одном направлении, и нет возможности для появления конфликтующей информации. В системе, использующей 'репликвцию со множеством мастервв, войиожно возникновение ситуации, когда два администратора внесут иаменения в разные реплики едкого разлапа приблизительно в одно и то же время.
Каждая иэ реплик лолжна передать свои изменения всем осгалыпск репликам. Если изменения обоих администраторов относятся К олнамУ и тому же элементу данных, то продясс синхронизации вызовет конфликт' и должен существо" вать механизм для Определения того, какая из версий имеет приоритет. Например предположим, что два администратора приблизительно одновременно модифицировали один и тот же обьект пользователя в двух различных репликах. Один алминистратор изменил телефониый-номер пользователя, а другой — пароль'учетной записи пользователя.
Система синхронизации должна работать таким образом, чтобы к концу процесса синхрониза- Глава 2Г. Служба «аталогаа Мзгау ции обьекг в обеих репликах имел новый телефонный номер и новый пароль. Поэтому в данном случае процесс реплнкации не может просто записать объект из одной реплики поверх объекта из другой. Данные в обеих копиях объекта должны быть объединены. Ситуация может быль еще более запуганной, если конфликтуют сами изменения, Например предположим, что пользователь позвонил администратору сети, чтобы сообщить ему свои новый телефонный номер сразу после того, как перед этим лал администратору неправильный номер. Пользователь хочет исправить опщбку, но в этот раз разговаривает с другим администратором.
Первый администратор изменил обьект полъзователя в одной реплике, введя новый (неправильный) номер, а несколькими секундами позже, до тото как был осуществлен процесс синхронизации, второй администратор изменил тот же объект, но только в другой реплике, на этот рзз введя правильный номер. Когда начнется процесс синхронизации, система должна иметь возможность определить, какая из версий данных имеет больший приоритет. Процесс синхронизации БОБ может преодолеть обе зти проблемы. Но, несмотря на то, что он достаточно эффективен, процесс несовершенен,-так как не может обновлять все реплики в режиме реального времени. Все еще возможно, что приложение, обратившееся к базе ланных во время короткого промежутка перед тем, как процесс синхронизации будет завершен, получит из нее устаревшую информацию.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
