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

Скачать файл
Заказать решение

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 08.11.2023

Просмотров: 95

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Содержание

Введение.

Обзорная часть В обзорно-аналитической главе будет проведен обзор предметной области, рассмотрены аналоги системы, их преимущества и недостатки. 1.1 История. Изначально кластерные технологии использовались при развертывании компьютерных сетей. Немалую роль в появлении высокоскоростной передачи между компьютерами имела возможность объединения вычислительных ресурсов. Лаборатория Xerox PARC вместе с группой разработчиков протокола TCP/IP разработали и закрепили стандарты сетевого взаимодействия уже в начале 1970-ых годов. Была разработана операционная система Hydra («Гидра»), которая работала на компьютерах PDP-11, которые выпускала компания DEC. На базе это ОС был разработан кластер, который был назван C.mpp в 1971 году в Америке в городе Питтсбург, который находится штате Пенсильвания. Однако, только в 1983 году научились распределять задачи и распространять файлы с помощью компьютерных сетей, огромный вклад в разработку этого внесла компания Sun Microsystems, которая предоставила операционную систему на основе BSD, которая имела название SunOS.Первым коммерческим проектом кластера стал ARCNet, созданный компанией Datapoint в 1977 году, однако этот продукт не принес прибыль компании, поэтому разработка кластеров была заморожена до 1984 года. В этом году компанией DEC был создан кластер VAXcluster, который был построен для ОС VAX/VMS. Каждый из этих кластеров мог не только производить совместные вычисления, но и предоставлял возможность совместного использования файловой системы и других составляющих, при этом не теряя целостность файлов и неизменность данных. На данный момент VAXCluster (называемый теперь VMSCluster) входит в сотав операционной системы HP OpenVMS, которая использует процессоры Alpha и Itanium.Также есть еще несколько первых разработок кластера, которые преобрели популярность. Такими продуктами являются класера Himalaya, который разработан компанией Tandem в 1994 году, а также Parallel Sysplex, который был разаботан компанией IBM также в 1994 году.Большей часть разработкой кластеров, которые состояли из персональных компьютеров, занимался проект Parallel Virtual Machine. Первый релиз данной программы произошёл в 1989 году. Это программное обеспечение предоставляло возможность из нескольких обычных компьютеров собрать один виртуальный суперкомпьютер. Появилась возможность очень быстро и просто создавать кластера. Данные дешевые кластера были даже лучше по производительности, чем производительность мощностей коммерческих систем.Разработку кластеров, состоящих из ПК в данной области продолжило Американское аэрокосмическое агентство NASA в 1993г. И уже в 1995 году появился кластер Beowulf. Это также поспособствовало развитию grip-сетей, который были созданы вместе с системами UNIX. 1.2 О кластере. Термин «кластер» имеет множество определений. Для некоторых главной составляющей является отказоустойчивость, для других — масштабируемость, для третьих — управляемость. Классическое определение кластера звучит примерно так: «кластер — параллельная или распределенная система, состоящая из нескольких связанных между собой компьютеров и при этом используемая как единый, унифицированный компьютерный ресурс». Следовательно, кластер – это некоторое количество серверов или компьютеров, которые объединены в одну сеть, которой можно управлять, и работают как неразделимый механизм. Для работы кластера необходимо, чтобы на любой узле (ноде, компьютере, сервере) была запущена своя копия ОС.Грегори Пристер как-то дал определение кластерным технологиям: «Кластер представляет собой одну из разновидностей распределенной или параллельной системы». Этот человек сыграл немалую роль на начальном этапе создания кластеров. Именно он был одним из ранних архитекторов кластерных решений.Однако эксперты Aberdeen Group дали более глобальное определение кластеру. По их мнению, кластер - это система, которая может работать как единый целый механизм, обеспечивает высокую отказоустойчивость, имеет централизованное управление всеми ресурсами и общую файловую систему и, кроме того, обеспечивает гибкость конфигурации и легкость в наращивании ресурсов.Все узлы кластера объединены в единую сеть, с помощью коммутационных каналов, через которые сервера могут обмениваться информацией. Каждый узел следит за состоянием других узлов, а также отправляет необходимую информацию, которая может включать в себя конфигурационные данные, данные об общих системах хранения и их работоспособности. Процедура обмена данной информацией называется heartbeat («сердцебиение», или «пульс»), и если кластер получил этот сигнал, следовательно сервер-адресант работает исправно. Если в какой-то момент один из узлов перестает посылать heartbeat-сигналы, то остальные узлы начинают считать его неисправным и кластер начинает перенастраиваться. Сигналы «сердцебиения» могут передаваться по одному каналу с какими-либо данным, но при создании крупных систем, лучше выделить для этого другой канал, чтобы не происходила потеря сигнала. С помощью таких сигналов также можно определить узел, который будет контролировать работу остальных узлов.Бывает ситуация, когда приложение перестает быть доступным для пользователя, этот период называется время простоя (или отключения). Есть классификация простоев, которая состоит из двух категорий: запланированные: замена оборудования; обслуживание; обновление программного обеспечения; резервное копирование (автономное резервное копирование); тестирование (периодическое тестирование необходимо для проверки кластеров); разработка; незапланированные: ошибки администратора; отказы приложений; отказы оборудования; ошибки операционной системы; стихийные бедствия. Таким образом, кластерные технологии должны обеспечивать доступность сервиса при любых простоях, как запланированных, так и незапланированных.. Наиболее популярными приложениями, которые лучше запускать в кластерах, являются: базы данных; системы управления ресурсами предприятия (ERP); средства обработки сообщений и почтовые системы; средства обработки транзакций через Web и Web-серверы; системы взаимодействия с клиентами (CRM); системы разделения файлов и печати. Также есть у кластеров есть своя классификация. Обычно различают следующие основные виды кластеров: отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности) кластеры непрерывной доступности (Fault tolerant) вычислительные кластеры 1.2.1 Высокая доступность. Высокодоступные кластера обозначаются аббревиатурой HA (англ. High Availability — высокая доступность). Данные кластеры позволяют предоставить высокую доступность сервиса. Количество узлов в HA кластере всегда избыточное, чтобы при отказе одного или нескольких, можно было бы запустить сервис на других. Минимальное количество узлов в данном кластере составляет два. В противном случае повысить доступность не получиться. Существует большое количество программ, которое предоставляют решение для HA-кластера.Существует три варианта построение высокодоступного кластера: с холодным резервом или активный/пассивный. В этом случае активный узел обрабатывает все запросы, а пассивный включается в работу только лишь при отказе активного. Пример — резервные сетевые соединения, в частности, Алгоритм связующего дерева. Например связка DRBD и HeartBeat. с горячим резервом или активный/активный. Все ноды принимают и обрабатывают запросы, и при отказе одного из них, нагрузка распределяется по оставшимся нодам. Следовательно, при отказе одного узла кластер переконфигурируется. Примеры — практически все кластерные технологии, например, Microsoft Cluster Server. OpenSource проект OpenMosix. с модульной избыточностью. Данный вариант самый трудозатратый. Его используют только в случаях, когда простой системы невозможен. В это конфигурации один и тот же запрос может выполняться несколькими узлами и выдается результат любого узла. Следовательно, очень важно, чтобы результаты всех узлов были идентичными (либо различия незначительны). Примеры — RAID и Triple modular redundancy. Некоторые решения кластеров могут сочетать несколько вариантов построения кластеров. Так, например, Linux-HA может обслуживать очень рискованные запросы всеми узлами, это называется режим обоюдной поглощающей конфигурации, а другие запросы могут равномерно распределяться между узлами.Высокая доступность кластеризация является метод, используемый для минимизации времени простоя и обеспечить непрерывное обслуживание, когда некоторые компоненты системы терпят неудачу. Kластеры HA состоит из множества узлов, которые взаимодействуют и обмениваются информацией через общие сетках памяти данных и являются отличным способом, чтобы обеспечить высокую доступность системы, надежность и масштабируемость.Учитывая эти разнообразные элементы высоко-доступность требует: Тщательное и полное планирование физических и логических процедур доступа и эксплуатации ресурсов, от которых зависит приложение. Эти процедуры помогают избежать сбоев в первую очередь. Пакет мониторинга и восстановления, что позволяет автоматизировать обнаружение и восстановление после ошибок. Хорошо контролируемый процесс для поддержания аппаратных и программных аспектов конфигурации кластера, сохраняя при этом доступны приложения. Отказоустойчивый кластеры предоставляют решение задач, таких как: 24 часа в сутки 7 дней недели любые приложения готовы к запуску, независимо от отказов в работе операционной системы, устройств хранения, приложения или инфраструктуры; держать очень высокий показатель SLA (перевыполнение обязательств); при предоставляемом оборудовании (базе, инфраструктуре) гарантировать максимальную высокую доступность; обеспечение целостности и доступности приложения в кластере, а также ПО; быстрое восстановление данных при поломках; уменьшение количество сбоев, чтобы не происходило простоев ОС, а также увеличение скорости развертывания нового оборудования; тщательный контроль за доступностью очень важных приложениями, таких как базы данных; гарантирование высокой доступности в виртуальных, реальных и смешанных средах. Преимущества высокой доступности: все компоненты стандартизированы и могут быть запущенные на существующих серверах и машинах; могут кластеризовать большую часть существующих приложений могут работать с очень большим вариантом работают практически со всеми приложениями (зависит только от умения того, кто осуществляет внедрение); работают с большинством существующих типов дисков и сетей; стоимость таких приложений относительно невысока. Непрерывная доступность (Fault tolerant) Для того, чтобы можно было предоставить полностью отказоустойчивый сервис, нужно, чтобы постоянно была точная копия узла, на котором запущен необходимый сервис. При создании копии после поломки оборудования придется потратить некоторое время на копирования или может случиться ситуация, при которой невозможно будет достать необходимую информацию из проблемного узла и это приведет к утере информации.Именно для таких ситуаций существует способ создания непрерывно доступного кластера. Существует два способа реализации такого решения: аппаратный и программный.Аппаратный способПри этом способе создаются два сервера, один из которых выполняет запросы, а другой полностью его копирует. При этом они оба независимо производят вычисления. Также есть узел, который проверяет и сверяет получившиеся результаты и выполняет поиск ошибок. Если невозможно исправить получившуюся ошибку, то сервер, который считается неисправным, отключается.В этом случае оборудование будет простаивать не более 32 секунд в год. Чтобы получить такие результаты необходимо пожертвовать большими деньгами на приобретение данного оборудования. По подсчетам одной российской компании на данный кластер придется потратить порядка $1 600 000Программный способ.Самым известным программным продуктом для реализации непрерывно доступного кластера в настоящее время является vSphere от VMware.Но данный способ реализации имеет свои ограничения, такие как: Определенный процессор на физической машине Intel архитектуры Sandy Bridge (или новее). Avoton не поддерживается. AMD Bulldozer (или новее). Сетка, с пропускной способностью в 10-гигабит, через которую общаются виртуальные машины Количество виртуальных машин на физической не должно превышать 8 Количество виртуальных процессов виртуальной машины не более 4 Количество виртуальных процессов на хосте не более 8 Не поддерживаются снэпшоты ISO-образы должны быть находиться в общем хранилище, чтобы все машины имели к ним доступ. Было проведено несколько экспериментов, результатами которых стал вывод, что при использовании FT от VMware виртуальные машины начинали работать значительно медленнее, производительность упала на

1.3 Рынок

Реализация

2.1 Демон

2.2 Сервисное приложение

2.3 Клиентское приложение.

Вывод.

Список литературы.

Приложение


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

  • Настройки сети и IP-адреса. При использовании для сети идентичных сетевых адаптеров используйте на этих адаптерах одинаковые настройки связи (такие как скорость, дуплексный режим, управление потоком и тип среды передачи). А также, сравните настройки сетевого адаптера и коммутатора, к которому подключен адаптер, и убедитесь, что никакие настройки не противоречат друг другу.

    При использовании частных сетей, для которых отсутствует маршрутизация в оставшуюся часть сетевой инфраструктуры, убедитесь, что в каждой из этих частных сетей используется уникальная подсеть. Это необходимо, даже если каждому сетевому адаптеру назначен уникальный IP-адрес. Например, если два узла кластера размещаются в центральном офисе, использующем одну физическую сеть, а еще два узла - в филиале, использующем другую физическую сеть, не задавайте для обеих сетей 10.0.0.0/24, даже если каждому сетевому адаптеру назначен уникальный IP-адрес.
    DNS. Серверы кластера должны использовать для разрешения имен службу DNS. Может использоваться протокол динамического обновления DNS.

  • Роль домена. Все серверы кластера должны находиться в одном домене Active Directory. Рекомендуется, чтобы для всех серверов кластера была задана одна и та же роль домена (либо рядовой сервер, либо контроллер домена). Рекомендуемой является роль рядового сервера.

  • Контроллеры домена. Рекомендуется, чтобы серверы кластера были рядовыми серверами. В этом случае в домене, содержащем отказоустойчивый кластер, контроллерами домена будут другие серверы.

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

  • Учетная запись для администрирования кластера. При создании кластера или при добавлении в него серверов необходимо войти в домен от имени учетной записи с правами администратора и разрешениями на доступ ко всем серверам этого кластера. Эта учетная запись не обязана быть учетной записью из группы Администраторы домена - она может быть учетной записью пользователя домена, входящей в группу Администраторына каждом кластеризованном сервере. Кроме того, если учетная запись не входит в группу Администраторы домена, учетной записи (или группе, членом которой является учетная запись) должно быть делегировано разрешение Создание объектов-компьютеров в домене. 

1.3.3 HP Serviceguard


HP Serviceguard (так жеMC/ServiceGuard) выпускается компанией HP для операционный систем Linux и HP-AUX c 1990 года. Представляет собой отказоустойчивый кластер вида active/passive.

В настоящее время максимальное число узлов, поддерживаемых в Serviceguard кластере 16.

Возможности:

  • Повышение эффективности использования ресурсов благодаря улучшенной балансировке рабочих нагрузок в кластере.

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

  • Комплексная защита от сбоев программного и аппаратного обеспечения, виртуализации, сети и хранилищ.

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

  • Дополнительные функции разрешения конфликтов помогут предотвратить потери и повреждения данных кластера.

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

  • Полная поддержка физических и виртуальных сред серверов.

  • Полная интеграция по доступной цене для синхронизации переноса аппаратных ресурсов и лицензий ПО с сервером при аварийном переключении.

  • Совместимость с Serviceguard Extensions, инструментами и решениями аварийного восстановления.

  • HP Serviceguard объединяет удобство текущих инструментов/расширений и управление Serviceguard Extension для Oracle Real Application Cluster (SGeRAC), Serviceguard Extension для SAP (SGeSAP), Enterprise Cluster Master Toolkit (ECMT) и Network File Server (NFS) Toolkit.

  • Благодаря совместимости с решениями Serviceguard Metrocluster и Continentalclusters Disaster Recovery процесс аварийного переключения значительно упрощается.

Конфигурация кластера:

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

1.3.4. Red Hat Enterprise Linux Cluster


Максимальное количество узлов кластера поддерживается высокой доступности Add-On 16

Не поддерживается:

  • Общая архитектура

Oracle RAC на GFS2

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

  • аппаратные средства

Кластер, у которого количество узлов больше 16

  • Место хранения

Использование MD RAID для хранения данных кластера

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

Использование нескольких SAN-устройств для зеркала GFS / GFS2 или кластерных логических томов на разных подмножествах узлов кластера

  • Сеть

Corosync с использованием широковещания вместо многоадресного в RHEL (за исключением демонстрационных и предпродажных обязательств)

    • В RHEL 5.6+ широковещательный режим поддерживается с некоторыми ограничениями в качестве альтернативы для многоадресной рассылки.

    • В RHEL 6.2+ одноадресное UDP будет полностью поддерживается в качестве альтернативы Multicast.

  • Ресурсы HA

Использование NFS в активной / активной конфигурации поверх либо GFS или GFS2

Использование NFS и Samba в большинстве GFS / GFS2 инстансах

RHCS (Red Hat Cluster Suite) состоит из:

  • Cluster infrastructure - Обеспечивает основные функции нод для совместной работы в качестве кластера: управление конфигурационными файлами, управления пользователями, управление безопасностью.

  • High-availability Service Management - обеспечивает аварийное переключение услуг с одной ноды кластера к другой в случае, когда нода становится неработоспособной.

  • Cluster administration tools - Конфигурация и инструменты управления для настройки, конфигурирования и управления кластером Red Hat. Инструменты предназначены для использования с Cluster infrastructure, HA и Service Management, а также Storage.

  • Linux Virtual Server (LVS) – Программа маршрутизации, которая обеспечивает IP-Load-Balancing. LVS работает в паре резервных серверов, которые распределяют запросы клиентов равномерно на реальных серверах, которые находятся за серверами LVS.

Дополнительного пакета (и не является частью Red Hat Cluster Suite):

  • GFS - GFS (Global File System) или GFS2 (Global File System 2) кластерная файловая система для использования с RHCS. GFS / GFS2 позволяет нескольким узлам предоставить общий доступ к хранилищу на уровне блоков, как если бы хранилище было подключены локально на каждом узле кластера.

  • Cluster Logical Volume Manager (CLVM) - обеспечивает управление томами хранения кластера

  • Global Network Block Device (GNBD) - вспомогательный компонент GFS / GFS2, который экспортирует хранения на уровне блоков для Ethernet.

Также в состав Red Hat кластера входит Pacemaker. Кластер настроенный с Pacemaker состоит из отдельных демонов (контроль узлов кластера), скриптов (управление услугами), а также подсистемы управления ресурсами (контроль разрозненных ресурсов). Следующие компоненты образуют архитектуру Pacemaker:

  • Cluster Information Base (CIB)

Демон информации, который использует XML для распространения и синхронизации текущей конфигурации и информации о состоянии от назначенного координатора (DC) - нода, назначенная Pacemaker для хранения и распределения состояния и действия кластера с помощью CIB - ко всем остальным нодам кластера.

  • Cluster Resource Management Daemon (CRMd)

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

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

  • Shoot the Other Node in the Head (STONITH)

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

1.3.5 Solaris Cluster


Solaris Cluster (так же Sun Cluster) разработана корпорацией Sun Microsystems, но в 2010 году его выкупила компания Oracle. Продукт разработан для операционной системы Solaris.

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

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

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


В июне 2007 года Sun выпустила исходный код Solaris Cluster через сообщество OpenSolaris HA Clusters.

Oracle Solaris Clusters обеспечивает:

  • Снижение незапланированных простев: Интеграция с Oracle Solaris на уровне ядра, Oracle Solaris Cluster предлагает самый быстрый и надежный способ обнаружения сбоев на серверах и хранилищах Oracle. Архитектура управления ошибками и самовосстановление Oracle Solaris помогают ограничить влияние аппаратных сбоев, обеспечивая автоматизированное восстановление на всех уровнях: сервера, системы хранения данных и сети.

  • Малая вероятность запланированных простоев: Планируемое время простоя может быть связано с несколькими причинами: изменения аппаратного обеспечения, обновления программного обеспечения и реконфигурации среды. Oracle Solaris Cluster может помочь уменьшить или даже предотвратить запланированное время простоя. Управляет живой миграции для виртуализированных рабочих нагрузок, развернутых на зоне Oracle Solaris Kernel и Oracle VM для SPARC доменов, чтобы снизить влияние на техническое обслуживание. Поддержка Oracle Solaris Image Packaging System позволяет быстрее и безопаснее делать системные обновления.

  • Ускоренное служба восстановления: Oracle Solaris Cluster может расширить возможности существенные HA, такие услуги как передача данных и приложений восстановления после сбоя, ограничивая перебои в обслуживании из-за локальных проблем, сводя к минимуму ошибки человека.


  1. 1   2   3   4   5   6

Смотрите также файлы