Что такое распределенная среда

Что такое распределенные системы? Краткое введение

В свете последних технологических изменений и достижений распределенные системы становятся все более популярными. Многие ведущие компании создали сложные распределенные системы для обработки миллиардов запросов и обновления без простоев.

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

Когда дело доходит до распределенных систем, есть много чего. Итак, сегодня мы просто познакомим вас с распределенными системами. Мы объясним различные категории, проблемы дизайна и соображения, которые необходимо учесть.

Что такое распределенная система?

На базовом уровне распределенная система — это совокупность компьютеров, которые работают вместе, образуя единый компьютер для конечного пользователя. Все эти распределенные машины имеют одно общее состояние и работают одновременно.

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

Примечание. Распределенные системы должны иметь общую сеть для подключения своих компонентов, которые могут быть подключены с помощью IP-адреса или даже физических кабелей.

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

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

Как правило, существует три типа распределенных вычислительных систем со следующими целями:

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

Децентрализованные и распределенные

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

Управлять децентрализованной системой сложнее, поскольку вы не можете управлять всеми участниками, в отличие от распределенного единого курса, где все узлы принадлежат одной команде / компании.

Преимущества распределенной системы

Распределенные системы могут быть сложными в развертывании и обслуживании, но такая конструкция дает много преимуществ. Давайте рассмотрим некоторые из этих льгот.

Масштабируемость — самое большое преимущество распределенных систем. Горизонтальное масштабирование означает добавление дополнительных серверов в пул ресурсов. Вертикальное масштабирование означает масштабирование за счет увеличения мощности (ЦП, ОЗУ, хранилища и т. Д.) На ваших существующих серверах.

Горизонтальное масштабирование легче динамически масштабировать, а вертикальное масштабирование ограничено мощностью одного сервера.

Хорошими примерами горизонтального масштабирования являются Cassandra и MongoDB. Они упрощают горизонтальное масштабирование за счет добавления дополнительных машин. Примером вертикального масштабирования является MySQL, когда вы масштабируете, переключаясь с меньших компьютеров на большие.

Проблемы проектирования с распределенными системами

Несмотря на то, что распределенные системы имеют много преимуществ, важно также отметить проблемы проектирования, которые могут возникнуть. Ниже мы кратко изложили основные соображения по поводу дизайна.

Распределенные системы нелегко установить и запустить, и часто эта мощная технология оказывается слишком «избыточной» для многих систем. Распространение данных, обеспечивающих выполнение различных требований в непредвиденных обстоятельствах, сопряжено с множеством проблем.

Точно так же ошибки труднее обнаружить в системах, которые разбросаны по разным местам.

Облако против распределенных систем

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

Распределенные вычисления направлены на создание совместного использования ресурсов и обеспечение размера и географической масштабируемости. Облачные вычисления — это предоставление среды по запросу с использованием прозрачности, мониторинга и безопасности.

По сравнению с распределенными системами облачные вычисления имеют следующие преимущества:

Однако облачные вычисления, возможно, менее гибки, чем распределенные вычисления, поскольку для построения системы вы полагаетесь на другие сервисы и технологии. Это дает вам меньше контроля.

Такие приоритеты, как балансировка нагрузки, репликация, автоматическое масштабирование и автоматическое резервное копирование. Могут быть упрощены с помощью облачных вычислений. Инструменты создания облака, такие как Docker, Amazon Web Services (AWS), Google Cloud Services или Azure, позволяют быстро создавать такие системы, и многие команды предпочитают создавать распределенные системы вместе с этими технологиями.

Примеры распределенных систем

Распределенные системы используются во всех сферах, от электронных банковских систем до сенсорных сетей и многопользовательских онлайн-игр. Многие организации используют распределенные системы для поддержки сетевых служб доставки контента.

В сфере здравоохранения распределенные системы используются для хранения и доступа, а также для телемедицины. В сфере финансов и торговли многие сайты онлайн-покупок используют распределенные системы для онлайн-платежей или системы распространения информации в финансовой торговле.

Распределенные системы также используются для транспорта в таких технологиях, как GPS, системы поиска маршрутов и системы управления дорожным движением. Сотовые сети также являются примерами распределенных сетевых систем из-за их базовой станции.

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

Источник

Обработка распределенных транзакций в микросервисной архитектуре

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

Приятного чтения!

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

Что такое распределенная транзакция?

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

Вот монолитная система интернет-магазина, в которой используются транзакции:

Рис. 1: Транзакция в монолите

Если в вышеприведенной системе пользователь отправляет к платформе запрос на заказ (Checkout), то платформа создает локальную транзакцию в базе данных, и эта транзакция охватывает множество таблиц базы данных, чтобы обработать (Process) заказ и зарезервировать (Reserve) товары со склада. Если любой из этих шагов совершить не удастся, то транзакция может откатиться, что означает отказ как от самого заказа, так и от зарезервированных товаров. Этот набор принципов называется ACID (атомарность, согласованность, изоляция, долговечность) и гарантируется на уровне системы базы данных.

Вот декомпозиция системы интернет-магазина, построенной из микросервисов:

Рисунок 2: Транзакции в микросервисе

В чем проблема при совершении распределенных транзакций в микросервисах?

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

Как поддерживать атомарность транзакции?

Как обрабатывать конкурентные запросы?

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

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

Возможные решения

Две вышеупомянутые проблемы весьма критичны в контексте проектирования и создания приложений на основе микросервисов. Для их решения применяется два следующих подхода:

1. Двухфазная фиксация

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

Как это работает

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

Вновь рассмотрим для примера систему интернет-магазина:

Рисунок 3: успешная двухфазная фиксация в микросервисной системе

Рисунок 4: Неудавшаяся двухфазная фиксация при работе с микросервисами

Преимущества

Недостатки

2. Согласованность в конечном счете и компенсация / SAGA

Одно из лучших определений согласованности в конечном счете дается на сайте microservices.io: каждый сервис публикует событие всякий раз, когда обновляет свои данные. Другие сервисы подписываются на события. При получении события сервис обновляет свои данные.

При таком подходе распределенная транзакция выполняется как совокупность асинхронных локальных транзакций на соответствующих микросервисах. Микросервисы обмениваются информацией через шину событий.

Как это работает

Опять же, давайте рассмотрим в качестве примера систему, работающую в интернет-магазине:

Рисунок 5: Согласованность в конечном счете / SAGA, успешный исход

В примере выше (рисунок 5), клиент требует, чтобы система обработала заказ. При этом запросе Choreographer порождает событие Create Order (создать заказ), чем начинает транзакцию. Микросервис OrderMicroservice слушает это событие и создает заказ – если эта операция прошла успешно, то он порождает событие Order Created (Заказ создан). Координатор Choreographer слушает это событие и переходит к заказу товаров, порождая событие Reserve Items (зарезервировать товары). Микросервис InventoryMicroservice слушает это событие и заказывает товары; если это событие прошло успешно, то он порождает событие Items Reserved (товары зарезервированы). В данном примере это означает, что транзакция закончена.

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

Рисунок 6: Согласованность в конечном счете / SAGA, неудачный исход

Если по какой-то причине InventoryMicroservice не удалось зарезервировать товары (рисунок 6), он порождает событие Failed to Reserve Items (Не удалось зарезервировать товары). Координатор Choreographer слушает это событие и запускает компенсирующую транзакцию, порождая событие Delete Order (удалить заказ). Микросервис OrderMicroservice слушает это событие и удаляет ранее созданный заказ.

Преимущества

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

Недостатки

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

Заключение

Более распространен подход, когда система создается в виде монолита, после чего по краям от нее постепенно начинают отсекаться микросервисы. При таком подходе в сердце микросервисной архитектуры остается крупное монолитное ядро, но большинство новых разработок приходится на микросервисы, а монолит остается относительно нетронутым. — Мартин Фаулер

Источник

Распределённые вычислительные среды (fabric computing)

Аналитическая компания Gartner прогнозирует: с распространением технологий будущего, таких как распределённые вычислительные среды (fabric computing), ИТ-директоры начнут увольнять подчинённых. Автоматизация вычислительных задач, характерная для нового типа инфраструктуры, снизит потребность в специалистах по обслуживанию информационных систем.

Распространение некоторых перспективных технологий способно привести к тому, что корпорации избавятся от необходимости держать обширный штат обслуживающего и управляющего персонала для поддержки своих компьютерных сетей, заявил вице-президент и аналитик Gartner Карл Клонч (Carl Claunch) на конференции Gartner IT Infrastructure & Operations Summit во Флориде, США. Среди технологий, создающих угрозу для рабочих мест, на первом месте стоит инновационный тип ИТ-инфраструктуры — распределенные вычислительные среды (computing fabric).

Распределенная вычислительная среда — это технология построения серверов, хранилищ данных и сетей, при которой память, процессоры и подсистемы ввода-вывода рассматриваются не как фиксированная архитектура, а как пул обобщенных ресурсов с возможностью динамической реконфигурации. Такая организация ресурсов способна обеспечить максимальную вычислительную мощность для решения наиболее сложных и ресурсоёмких задач.

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

По словам аналитика, работодатели могут начать направленно развёртывать новую технологию, чтобы снизить расходы на зарплату работникам ИТ-отделов. Автоматизация в распределённых вычислительных средах даёт корпорациям возможность «избавиться от низкооплачиваемого труда» в сфере обслуживания своих сетей и систем, сократив обслуживающий персонал.

Впрочем, отметил Клонч, многие компании, содержащие большой ИТ-отдел, на такой шаг не пойдут. Однако их сотрудникам следует приготовиться к тому, что с обслуживания инфраструктуры их перебросят на выполнение других задач.

Кому не следует беспокоиться за свое рабочее место в мире распределённых вычислительных систем, так это аналитикам по безопасности, пообещал Клонч. По мнению Gartner, распространение инновационного типа инфраструктуры потребует радикально новых подходов к организации защиты информации.

Gartner включила распределенные вычислительные среды в десятку стратегических инноваций, которые окажут наибольшее влияние на облик мира ИТ, ещё в 2008 году. К 2012 году технология получила распространение в крупных вычислительных системах. Программное обеспечение, позволяющее настроить системы для работы в режиме распределённой вычислительной среды, уже поставляют такие крупные вендоры, как Oracle, Cisco, HP, Microsoft, IBM, Dell и VMware.

Источник

Распределенная среда обработки данных DCE

Среда DCE, разработанная в 1990 г., представляет собой набор сетевых служб, предназначенный для выполнения прикладных процессов, рассредоточенных по группе абонентских систем гетерогенной сети. Наряду с файловой службой, реализованной в виде распределенной файловой системы (DFS), DCE специфицирует следующий базовый набор распределенных служб и технологий:

Достоинства DCE

Таким образом, среда DCE предлагает множество стандартизованных и очень полезных услуг, однако это почему-то не принимается во внимание теми, кто предвещает ее скорый закат. А пользователям крупных гетерогенных сетей так необходимы единая процедура входа в систему, единая система справочников и информационной безопасности для управления доступом к данным, распределенным по всему предприятию.

Интегрированные службы безопасности, справочников и единого времени означают, что соответствующим спецификации DCE прикладным программам не надо самим создавать эти службы или средства работы с несколькими нестандартными (фирменными) системами различных производителей (скажем, службой справочника NetWare (NDS) или службой Banyan StreetTalk).

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

Недостатки DCE

Механизм RPC является единственным механизмом межпроцессного взаимодействия. И это плохо. Такой механизм требует установления соединения между клиентом и сервером.

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

Все это приводит к тому, что вызовы RPC, как только они сталкиваются со столь обычными для сетей «странностями» или с небольшой пропускной способностью каналов между клиентами, работают неудовлетворительно.

По мере того как программы становятся в большей степени событийно-ориентированными, для обеспечения одновременного выполнения многочисленных вызовов, реализации асинхронных и неблокирующих RPC в DCE предусмотрен механизм многопоточности.

Но проблема в том, что для многих разработчиков создание многопоточных программ оказалось значительно более сложным делом, чем они рассчитывали.

Механизм RPC не стал универсальным средством для создания распределенных прикладных систем.

Корпорация IBM сейчас ведет себя крайне агрессивно и на рынке серверов, и на рынке настольных систем, и на рынке сетевых операционных систем. Вскоре она собирается добавить поддержку DCE во все свои основные платформы, включая LAN Server.

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

Network OLE, новая технология Microsoft, разработанная в соответствии со стратегией Common Object Model для распределенных приложений, также поддерживает согласуемый с DCE механизм RPC, но совершенно неясно, будут ли здесь реализованы базовые службы безопасности DCE.

Так же как интерфейс ODBC позволил стандартизировать доступ к базам данных SQL разных производителей, разработка Microsoft могла бы сильно облегчить труд создателей приложений, позволив им использовать готовые службы, а не создавать свои собственные.

Основы DCE

Системы, имеющие программы распределенной среды, соответственно, являются серверами и клиентами. Серверы связаны друг с другом логическими каналами, по которым передают друг другу файлы. Каждый сервер имеет свою группу клиентов.

Логическая структура среды CDE представлена на рисунке:

Среда имеет трехступенчатую архитектуру:

Функции, выполняемые средой, записаны на языке C и включают прикладные службы:

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

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

Функционирование распределенной среды требует выполнения ряда административных задач. К ним, в первую очередь, относятся средства:

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

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

Размеры ячейки территориально не ограниченны: от нескольких машин, объединенных в локальную сеть, и до систем, находящихся на разных континентах.

В ячейках выполняются службы:

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

Как создать среду DCE

Планирование

Прежде чем определять размещение DCE, следует проанализировать сетевую среду и прикладные программы, чтобы ответить на вопросы: сколько приложений предполагается выполнить? Как они будут общаться между собой? Сколько пользователей окажется в каждом узле? Намерены ли пользователи одновременно работать с несколькими приложениями? Как часто пользователям придется обращаться к службе защиты? Когда они будут регистрироваться в ячейке? Как часто пользователям нужно будет вызывать приложения?

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

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

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

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

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

Рекомендуется по карте проанализировать размещение приложений и составить несколько вариантов конфигурации ячеек.

Отдельные группы пользователей, например отделы продаж, маркетинга и кадров, можно объединить в одну ячейку. Но если отдел кадров потребует ограничить доступ к своим данным сотрудников других подразделений, то для него надо будет выделить отдельную ячейку с собственной службой защиты. Тогда у сотрудника, занимающегося маркетингом, появятся все права доступа к данным своего отдела и ограниченный доступ к данным о коллегах, хранящимся в ячейке отдела кадров.

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

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

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

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

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

Если в вашей организации за управление конфигурацией отвечает не определенное подразделение, а разработчики приложений, то лучше разместить приложения в разных ячейках. Тогда каждая группа разработчиков сможет сама решать, в какое время и как переходить на новую версию. В случае когда приложения в этих ячейках обмениваются данными, необходимо синхронизовать переход на новые версии, потому что в различных версиях CDE (например, 1.0 и 1.1) реализуются разные модели обмена между ячейками.

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

Оптимизация ячейки

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

Размещение указанных служб поблизости от станций пользователей поможет уменьшить падение производительности в ячейке во время запуска. Для устранения конкуренции в доступе к службам и приложениям DCE рекомендуется создать достаточное количество их копий.

Например, если в среде возникает 11 запросов на 10 серверов, попробуйте установить один, два и даже больше дополнительных серверов, пока в реальных условиях не будет достигнута приемлемая производительность.

Исследование, проведенное Центром информационных технологий Мичиганского университета, показало, что хотя среднее время регистрации составляет всего 2 с даже при работе с 50200 бюджетами, иногда оно достигает трех минут и более.

Учитывая то обстоятельство, что первоначальные реализации DCE поддерживают сотни, а не десятки тысяч пользователей, нетрудно предположить, что большинство компаний не ощутят снижения производительности из-за процедуры регистрации.

В версии DCE 1.2 эта проблема полностью устранена. Повысить доступность ресурсов поможет создание копий приложений и служб в нескольких узлах ячейки. Такая мера позволит в случае сбоя приложения или службы перейти на работу с их копиями, а также улучшит масштабируемость системы.

Для того чтобы в результате отказа сетевого узла часть пользователей не оказалась отрезанной от приложений и служб DCE, попытайтесь для каждого сетевого сегмента организовать отдельную ячейку и скопировать в нее приложения.

Часть процессов DCE работает в каждом узле, например программа-демон dced, которая в версии 1.1 связывает клиента с сервером и обслуживает каталоги. При этом в отдельном узле может выполняться только одна копия процесса. Хорошо что сбой процесса влечет за собой отказ не всей ячейки, а лишь того узла, на котором он работал.

Для восстановления нужно с помощью сетевого или системного ПО определить состояние этого процесса и запустить его снова.

Размещение серверов защиты

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

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

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

Например, если ячейка объединяет сети в Киеве, Днепропетровске и Кривом Роге и все коммуникации проходят через Днепропетровск, то этот город и будет логическим центром сети и именно там следует разместить по крайней мере один сервер защиты.

Прежде чем выбрать такой вариант, необходимо убедиться, что сбой данного сегмента не вызовет отказа всей сети.

Если в большинстве случаев пользователи работают с приложениями только из собственной ЛС и в сети нет обходных маршрутов, имеет смысл поместить сервер защиты в каждой локальной сети.

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

Хотя среда DCE обеспечивает защиту обмена данными между приложениями, она не может гарантировать полную безопасность: физически защитить машины, на которых выполняются приложения DCE, вы должны самостоятельно.

При повышенных требованиях к конфиденциальности серверы защиты DCE рекомендуется размещать в охраняемых помещениях информационного центра.

Размещение серверов каталогов

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

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

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

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

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

Синхронизация часов

О значении службы времени и соответствующих рекомендациях OSF можно прочитать в руководстве «OSF DCE Administration Guide, Core Components», которое входит в комплект поставки DCE. В нем подробно описано, какие службы времени нужны для ячеек при той или иной конфигурации сети. Поскольку небольшая ошибка в системных часах может нарушить совместимость защищенных приложений DCE, лучше всего обратиться в службу точного времени.

Серверы лицензий

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

Лицензии для серверов лицензий выдаются на определенной машине и не могут использоваться серверами с других машин. Поэтому при сбое этого сервера вы теряете доступ ко всем его лицензиям до устранения неисправности.

Постарайтесь, чтобы с вашим поставщиком ПО среды DCE можно было быстро связаться для восстановления сервера лицензий или получения новых лицензий на короткий срок.

Для особо ответственных приложений рекомендуется купить дополнительное число лицензий.

Подготовка персонала

От вас потребуется составить план и выделить средства для найма и обучения обслуживающего персонала. Предлагается следовать рекомендациям, принятым для NetWare и для других распределенных сред: на каждые 100 пользователей и серверов приложений должен приходиться один администратор.

Разработайте основные стратегии и процедуры, такие как стандарты имен интерфейсов, каталогов и их элементов, серверов приложений и других ресурсов, а также рекомендации по работе со службой защиты и копированием данных служб защиты и каталогов.

Источник