Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции 13-16 / 2 / OC_14.doc
Скачиваний:
82
Добавлен:
04.04.2013
Размер:
614.4 Кб
Скачать

Программное обеспечение

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

Специальное ПО – вот что объединяет серверы в кластеры. Многие современные корпоративные приложения и ОС имеют встроенную поддержку кластеризации, но бесперебойное функционирование и прозрачность кластера может гарантировать специальное ПО промежуточного уровня. Оно отвечает в первую очередь за слаженную работу всех серверов и разрешение возникающих в системе конфликтов, обеспечивая формирование и реконфигурацию кластера после сбоев. Кроме того, ПО промежуточного уровня обеспечивает распределение нагрузки по узлам кластера, восстановление работы приложений сбойных серверов на доступных узлах (failover - процедура миграции), а также мониторинг состояния аппаратной и программной сред. Существует и еще одно важное достоинство этого ПО: оно позволяет запускать на кластере любое приложение без предварительной адаптации к новой аппаратной архитектуре.

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

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

Распределенные БД и БД с репликациями.

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

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

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

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.

Соседние файлы в папке 2