No Image

Что такое нода в кластере

СОДЕРЖАНИЕ
0 просмотров
11 марта 2020

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

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

Обычно различают следующие основные виды кластеров:

  1. отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
  2. кластеры с балансировкой нагрузки (Load balancing clusters)
  3. вычислительные кластеры (High performance computing clusters, HPC)
  4. системы распределенных вычислений

Содержание

Классификация кластеров [ править | править код ]

Кластеры высокой доступности [ править | править код ]

Обозначаются аббревиатурой HA (англ. High Availability — высокая доступность). Создаются для обеспечения высокой доступности сервиса, предоставляемого кластером. Избыточное число узлов, входящих в кластер, гарантирует предоставление сервиса в случае отказа одного или нескольких серверов. Типичное число узлов — два, это минимальное количество, приводящее к повышению доступности. Создано множество программных решений для построения такого рода кластеров.

Отказоустойчивые кластеры и системы разделяются на 3 основных типа:

  • с холодным резервом или активный/пассивный. Активный узел выполняет запросы, а пассивный ждет его отказа и включается в работу, когда таковой произойдет. Пример — резервные сетевые соединения, в частности, Алгоритм связующего дерева. Например, связка DRBD и HeartBeat/Corosync.
  • с горячим резервом или активный/активный. Все узлы выполняют запросы, в случае отказа одного нагрузка перераспределяется между оставшимися. То есть кластер распределения нагрузки с поддержкой перераспределения запросов при отказе. Примеры — практически все кластерные технологии, например, Microsoft Cluster Server. OpenSource проект OpenMosix.
  • с модульной избыточностью. Применяется только в случае, когда простой системы совершенно недопустим. Все узлы одновременно выполняют один и тот же запрос (либо части его, но так, что результат достижим и при отказе любого узла), из результатов берется любой. Необходимо гарантировать, что результаты разных узлов всегда будут одинаковы (либо различия гарантированно не повлияют на дальнейшую работу). Примеры — RAID и Triple modular redundancy.

Конкретная технология может сочетать данные принципы в любой комбинации. Например, Linux-HA поддерживает режим обоюдной поглощающей конфигурации (англ. takeover ), в котором критические запросы выполняются всеми узлами вместе, прочие же равномерно распределяются между ними. [1]

Кластеры распределения нагрузки (Network Load Balancing, NLB) [ править | править код ]

Принцип их действия строится на распределении запросов через один или несколько входных узлов, которые перенаправляют их на обработку в остальные, вычислительные узлы. Первоначальная цель такого кластера — производительность, однако, в них часто используются также и методы, повышающие надёжность. Подобные конструкции называются серверными фермами. Программное обеспечение (ПО) может быть как коммерческим (OpenVMS, MOSIX, Platform LSF HPC, Solaris Cluster, Moab Cluster Suite, Maui Cluster Scheduler), так и бесплатным (OpenMosix, Sun Grid Engine, Linux Virtual Server).

Вычислительные кластеры [ править | править код ]

Кластеры используются в вычислительных целях, в частности в научных исследованиях. Для вычислительных кластеров существенными показателями являются высокая производительность процессора в операциях над числами с плавающей точкой (flops) и низкая латентность объединяющей сети, и менее существенными — скорость операций ввода-вывода, которая в большей степени важна для баз данных и web-сервисов. Вычислительные кластеры позволяют уменьшить время расчетов, по сравнению с одиночным компьютером, разбивая задание на параллельно выполняющиеся ветки, которые обмениваются данными по связывающей сети. Одна из типичных конфигураций — набор компьютеров, собранных из общедоступных компонентов, с установленной на них операционной системой Linux, и связанных сетью Ethernet, Myrinet, InfiniBand или другими относительно недорогими сетями. Такую систему принято называть кластером Beowulf. Специально выделяют высокопроизводительные кластеры (Обозначаются англ. аббревиатурой HPC ClusterHigh-performance computing cluster). Список самых мощных высокопроизводительных компьютеров (также может обозначаться англ. аббревиатурой HPC) можно найти в мировом рейтинге TOP500. В России ведется рейтинг самых мощных компьютеров СНГ. [2]

Системы распределенных вычислений (grid) [ править | править код ]

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

Кластер серверов, организуемых программно [ править | править код ]

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

В отличие от аппаратного кластера компьютеров, кластеры организуемые программно, требуют:

  • наличия специального программного модуля (Cluster Manager), основной функцией которого является поддержание взаимодействия между всеми серверами — членами кластера:
  • синхронизации данных между всеми серверами — членами кластера;
  • распределение нагрузки (клиентских запросов) между серверами — членами кластера;
  • от умения клиентского программного обеспечения распознавать сервер, представляющий собой кластер серверов, и соответствующим образом обрабатывать команды от Cluster Manager;
    • если клиентская программа не умеет распознавать кластер, она будет работать только с тем сервером, к которому обратилась изначально, а при попытке Cluster Manager перераспределить запрос на другие серверы, клиентская программа может вообще лишиться доступа к этому серверу (результат зависит от конкретной реализации кластера).
    • Примеры программных кластерных решений

      • IBM Lotus Notes
      • HP MC/ServiceGuard

      Применение [ править | править код ]

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

      Однако, принцип организации кластера серверов (на уровне программного протокола) позволяет исполнять по нескольку программных серверов на одном аппаратном. Такое использование может быть востребовано:

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

      Самые производительные кластеры [ править | править код ]

      Дважды в год организацией TOP500 публикуется список пятисот самых производительных вычислительных систем в мире, среди которых в последнее время часто преобладают кластеры. Самым быстрым кластером является IBM Roadrunner (Лос-Аламосская национальная лаборатория, США, созданный в 2008 году), его максимальная производительность (на июль 2008) составляет 1,026 Петафлопс. Самая быстрая система в Европе (на июль 2008) — суперкомпьютер, BlueGene/P находится в Германии, в исследовательском центре города Юлих, земля Северный Рейн-Вестфалия, максимально достигнутая производительность 167,3 Терафлопс.

      Кластерные системы занимают достойное место в списке самых быстрых, при этом значительно выигрывая у суперкомпьютеров в цене. На июль 2008 года на 7 месте рейтинга TOP500 находится кластер SGI Altix ICE 8200 (Chippewa Falls, Висконсин, США).

      Сравнительно дешёвую альтернативу суперкомпьютерам представляют кластеры, основанные на концепции Beowulf, которые строятся из обыкновенных недорогих компьютеров на основе бесплатного программного обеспечения. Один из практических примеров такой системы — Stone Soupercomputer в Национальной лаборатории Ок-Ридж (Теннесси, США, 1997).

      Крупнейший кластер, принадлежащий частному лицу (из 1000 процессоров), был построен Джоном Козой (John Koza).

      История [ править | править код ]

      История создания кластеров неразрывно связана с ранними разработками в области компьютерных сетей. Одной из причин для появления скоростной связи между компьютерами стали надежды на объединение вычислительных ресурсов. В начале 1970-х годов группой разработчиков протокола TCP/IP и лабораторией Xerox PARC были закреплены стандарты сетевого взаимодействия. Появилась и операционная система Hydra для компьютеров PDP-11 производства DEC, созданный на этой основе кластер был назван C.mpp (Питтсбург, штат Пенсильвания, США, 1971 год). Тем не менее, только около 1983 года были созданы механизмы, позволяющие с лёгкостью пользоваться распределением задач и файлов через сеть, по большей части это были разработки в SunOS (операционной системе на основе BSD от компании Sun Microsystems).

      Первым коммерческим проектом кластера стал ARCNet, созданный компанией Datapoint в 1977 году. Прибыльным он не стал, и поэтому строительство кластеров не развивалось до 1984 года, когда DEC построила свой VAXcluster на основе операционной системы VAX/VMS. ARCNet и VAXcluster были рассчитаны не только на совместные вычисления, но и совместное использование файловой системы и периферии с учётом сохранения целостности и однозначности данных. VAXCluster (называемый теперь VMSCluster) — является неотъемлемой компонентой операционной системы HP OpenVMS, использующих процессоры DEC Alpha и Itanium.

      Два других ранних кластерных продукта, получивших признание, включают Tandem Hymalaya (1994, класс HA) и IBM S/390 Parallel Sysplex (1994).

      История создания кластеров из обыкновенных персональных компьютеров во многом обязана проекту Parallel Virtual Machine. В 1989 году это программное обеспечение для объединения компьютеров в виртуальный суперкомпьютер открыло возможность мгновенного создания кластеров. В результате суммарная производительность всех созданных тогда дешёвых кластеров обогнала по производительности сумму мощностей «серьёзных» коммерческих систем.

      Читайте также:  Понизить пинг в игре world of tanks

      Создание кластеров на основе дешёвых персональных компьютеров, объединённых сетью передачи данных, продолжилось в 1993 году силами Американского аэрокосмического агентства NASA, затем в 1995 году получили развитие кластеры Beowulf, специально разработанные на основе этого принципа. Успехи таких систем подтолкнули развитие grid-сетей, которые существовали ещё с момента создания UNIX.

      Программные средства [ править | править код ]

      Широко распространённым средством для организации межсерверного взаимодействия является библиотека MPI, поддерживающая языки C и Fortran. Она используется, например, в программе моделирования погоды MM5.

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

      Среди пользователей GNU/Linux популярны несколько программ:

      • distcc, MPICH и др. — специализированные средства для распараллеливания работы программ. distcc допускает параллельную компиляцию в GNU Compiler Collection.
      • Linux Virtual Server, Linux-HA — узловое ПО для распределения запросов между вычислительными серверами.
      • MOSIX, openMosix, Kerrighed, OpenSSI — полнофункциональные кластерные среды, встроенные в ядро, автоматически распределяющие задачи между однородными узлами. OpenSSI, openMosix и Kerrighed создают среду единой операционной системы между узлами.

      Кластерные механизмы планируется встроить и в ядро DragonFly BSD, ответвившуюся в 2003 году от FreeBSD 4.8. В дальних планах также превращение её в среду единой операционной системы.

      Компанией Microsoft выпускается HA-кластер для операционной системы Windows. Существует мнение, что он создан на основе технологии Digital Equipment Corporation, поддерживает до 16 (с 2010 года) узлов в кластере, а также работу в сети SAN (Storage Area Network). Набор API-интерфейсов служит для поддержки распределяемых приложений, есть заготовки для работы с программами, не предусматривающими работы в кластере.

      Windows Compute Cluster Server 2003 (CCS), выпущенный в июне 2006 года разработан для высокотехнологичных приложений, которые требуют кластерных вычислений. Издание разработано для развертывания на множестве компьютеров, которые собираются в кластер для достижения мощностей суперкомпьютера. Каждый кластер на Windows Compute Cluster Server состоит из одного или нескольких управляющих машин, распределяющих задания и нескольких подчиненных машин, выполняющих основную работу. В ноябре 2008 года представлен Windows HPC Server 2008, призванный заменить Windows Compute Cluster Server 2003.

      Novell Open Enterprise Server (OES) — сетевая операционная система, « сплав » Novell NetWare и SUSE Linux Enterprise Server; кроме прочего способная создавать смешанные кластеры, в которых ресурсы при сбое могут перемещаться с сервера NetWare на сервер Linux и наоборот.

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

      Однако недавно я наткнулся на статью Romain Serre в которой эта проблема как раз решалась с помощью Windows Server 2016 и новой функции которая присутствует в нем — Storage Spaces Direct (S2D). Картинку я как раз позаимствовал из этой статьи, поскольку она показалась очень уместной.

      Технология Storage Spaces Direct уже неоднократно рассматривалась на Хабре. Но как-то прошла мимо меня, и я не думал, что можно её применять в «народном хозяйстве». Однако это именно та технология, которая позволяет собрать кластер из двух нод, создав при этом единое общее хранилище между серверами. Некий единый рейд из дисков, которые находятся на разных серверах. Причем выход одного из дисков или целого сервера не должны привести к потере данных.

      Звучит заманчиво и мне было интересно узнать, как это работает. Однако двух серверов для тестов у меня нет, поэтому я решил сделать кластер в виртуальной среде. Благо и вложенная виртуализация в hyper-v недавно появилась.

      Для своих экспериментов я создал 3 виртуальные машины. На первой виртуальной машине я установил Server 2016 с GUI, на котором я поднял контроллер AD и установил средства удаленного администрирования сервера RSAT. На виртуальные машины для нод кластера я установил Server 2016 в режиме ядра. В этом месяце загадочный Project Honolulu, превратился в релиз Windows Admin Center и мне также было интересно посмотреть насколько удобно будет администрировать сервера в режиме ядра. Четвертная виртуальная машина должна будет работать внутри кластера hyper-v на втором уровне виртуализации.

      Для работы кластера и службы Storage Spaces Direct необходим Windows Server Datacenter 2016. Отдельно стоит обратить внимание на аппаратные требования для Storage Spaces Direct. Сетевые адаптеры между узлами кластера должны быть >10ГБ с поддержкой удаленного прямого доступа к памяти (RDMA). Количество дисков для объединения в пул – минимум 4 (без учета дисков под операционную систему). Поддерживаются NVMe, SATA, SAS. Работа с дисками через RAID контроллеры не поддерживается. Более подробно о требованиях docs.microsoft.com

      Если вы, как и я, никогда не работали со вложенной виртуализацией hyper-v, то в ней есть несколько нюансов. Во-первых, по умолчанию на новых виртуальных машинах она отключена. Если вы захотите в виртуальной машине включить роль hyper-v, то получите ошибку, о том, что оборудование не поддерживает данную роль. Во-вторых, у вложенной виртуальной машины (на втором уровне виртуализации) не будет доступа к сети. Для организации доступа необходимо либо настраивать nat, либо включать спуфинг для сетевого адаптера. Третий нюанс, для создания нод кластера, нельзя использовать динамическую память. Подробнее по ссылке.

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

      Включаем поддержку спуфинга на сетевых адаптерах ВМ:


      HDD10 и HDD 20 я использовал как системные разделы на нодах. Остальные диски я добавил для общего хранилища и не размечал их.

      Сетевой интерфейс Net1 у меня настроен на работу с внешней сетью и подключению к контроллеру домена. Интерфейс Net2 настроен на работу внутренней сети, только между нодами кластера.

      Для сокращения изложения, я опущу действия необходимые для того, чтобы добавить ноды к домену и настройку сетевых интерфейсов. С помощью консольной утилиты sconfig это не составит большого труда. Уточню только, что установил Windows Admin Center с помощью скрипта:

      По сети из расшаренной папки установка Admin Center не прошла. Поэтому пришлось включать службу File Server Role и копировать инсталлятор на каждый сервер, как в мс собственно и рекомендуют.

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

      Приступим к созданию кластера. Напомню, что все необходимые консоли у меня установлены на контролере домена. Поэтому я подключаюсь к домену и запускаю Powershell ISE под администратором. Затем устанавливаю на ноды необходимые роли для построения кластера с помощью скрипта:

      И перегружаю сервера после установки.

      Запускаем тест для проверки готовности нод:

      Отчёт в фомате html сформировался в папке C:UsersAdministratorAppDataLocalTemp. Путь к отчету утилита пишет, только если есть ошибки.

      Ну и наконец создаем кластер с именем hpvcl и общим IP адресом 192.168.1.100

      После чего получаем ошибку, что в нашем кластере нет общего хранилища для отказоустойчивости. Запустим Failover cluster manager и проверим что у нас получилось.

      И получаем оповещение, что не найдены диски для кэша. Поскольку тестовая среда у меня на SSD, а не на HDD, не будем переживать по этому поводу.

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

      На каждой из нод, у нас появился общий том C:ClusterStorageVolume1.
      Кластер с общим диском готов. Теперь создадим виртуальную машину VM на одной из нод и разместим её на общее хранилище.

      Для настроек сети виртуальной машины, необходимо будет подключиться консолью hyper-v manager и создать виртуальную сеть с внешним доступом на каждой из нод с одинаковым именем. Затем мне пришлось перезапустить службу кластера на одной из нод, чтобы избавиться от ошибки с сетевым интерфейсом в консоли failover cluster manager.

      Пока на виртуальную машину устанавливается система, попробуем подключиться к Windows Admin Center. Добавляем в ней наш гиперконвергентный кластер и получаем грустный смайлик

      Подключимся к одной из нод и выполним скрипт:

      Проверяем Admin Center и на этот раз получаем красивые графики

      После того, как установил ОС на виртуальную машину VM внутри кластера, первым делом я проверил Live migration, переместив её на вторую ноду. Во время миграции я пинговал машину, чтобы проверить насколько быстро происходит миграция. Связь у меня пропала только на 2 запроса, что можно считать весьма неплохим результатом.

      И тут стоит добавить несколько ложек дёгтя в эту гиперконвергентную бочку мёда. В тестовой и виртуальной среде все работает неплохо, но как это будет работать на реальном железе вопрос интересный. Тут стоит вернуться к аппаратным требованиям. Сетевые адаптеры 10GB с RDMA стоят порядка 500$, что в сумме с лицензией на Windows Server Datacenter делает решение не таким уж и дешёвым. Безусловно это дешевле чем выделенное хранилище, но ограничение существенное.

      Читайте также:  Если потерял айфон как его найти

      Вторая и основная ложка дёгтя, это новость о том, что функцию (S2D) уберут из следующей сборки server 2016 . Надеюсь, сотрудники Microsoft, читающие Хабр, это прокомментируют.

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

      Построение кластера Hyper-V 3.0 с использованием сетевого хранилища данных (SAN)

      В данной статье я расскажу о реальном примере внедрения отказоустойчивого кластера Hyper-V 3.0 с использованием SAN сетей. На написание данной статьи меня подтолкнуло отсутствие в интернете реальных примеров внедрения корпоративных решений. В свое время когда я собирал свой первый кластер я так и не смог увидеть ни одной статьи описывающей реальный боевой опыт с серьезным оборудованием, конечно полно статей типа «кластер на коленке» с помощью которых и было получено общее представление о технологии, а далее развив тему решил поделиться опытом с теми кому нужен кластер Hyper-V уже «вчера».

      1. Описание основных понятий

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

      Сеть хранения данных (англ. Storage Area Network, SAN) — представляет собой архитектурное решение для подключения внешних устройств хранения данных, таких как дисковые массивы, ленточные библиотеки, к серверам таким образом, чтобы операционная система распознала подключённые ресурсы как локальные.

      Microsoft Hyper-V — система виртуализации для x64-систем на основе гипервизора. Гипервизор обеспечивает параллельное выполнение нескольких ОС на одном и том же хосте, изоляцию операционных систем друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами.

      2. Подбор оборудования и ПО

      Аппаратные требования: Процессор должен поддерживать аппаратную виртуализацию и трансляцию адресов второго уровня (Intel EPT или AMD RVI). У Intel эта технология называется Intel-VT (также может обозначаться VMX), у AMD — AMD-V (SVM). Однако чтобы виртуализация заработала, поддержка должна быть не только на уровне процессора, но и на уровне материнской платы. Включить виртуализацию можно в разделе Advanced BIOS Featured. Обычно здесь есть параметр Virtualization, или Intel-VT.

      При выборе оборудования необходимо собрать данные о серверах которые вы хотите виртуализировать и сделать их анализ, необходимо понять какие ресурсы используют все ваши сервисы которые подлежат виртуализации. Данный анализ поможет сделать Microsoft Assessment and Planning ToolKit. С помощью него вы сможете: инвентаризировать ресурсы, собрать показатели производительности, получить рекомендации по виртуализации, и даже рассчитать рентабельность инвестиций. В итоге вы сможете точно сказать какое оборудование вам нужно(вплоть до конкретного процессора).

      После сбора и анализа данных с помощью MAP, мы подобрали оборудование которое позволило бы нам виртуализировать все наши ресурсы, плюс оставили запас под рост сервисов. В общих чертах можно сказать что с данной(ниже) конфигурацией мы смогли на предприятии (количество пользователей пользующихся виртуализированными сервисами — 600 чел.) без потери производительности перевести в виртуальную среду около 15 серверов с разнообразнейшими сервисами в составе: нескольких SQL серверов разных версий (на них крутится 1С 8.2 Предприятие, Эл.документооборот, ServiceDesk, и другое ПО), терминальный сервер, WEB сервер, один из контроллеров домена, сервер антивируса, и т.д и т.п. И все это прекрасно и беспроблемно уживается в виртуальной среде.

      Итак основываясь на результатах собранной информации с помощью MAP, и используя функцию MAP Server VirtualizationServer Consolidation Rezults подобрали с помощью вендора оптимальную конфигурацию для нашей инфраструктуры. В ее состав входят два сервера, схд, коммутаторы для организации сети SAN. Отдельно замечу что мы не рассматриваем варианты с использованием SMB (Hyper-V 2012 это позволяет), Microsoft iSCSI Software Target, StarWind iSCSI Software Target, по многим причинам (ввиду хотя бы названия этой статьи) которые рассматривать здесь не будем, поэтому примите как данность.

      Состав оборудования:

      Ноды кластера (сервера)

      Сервер IBM System x 3850 X5 Rack в составе:

      Процессор Xeon E7-4820 2.00GHz/24MB L3 – 2 шт.,

      Оперативная память PC3L-10600 CL9 ECC DDR3 1333MHz – 48GB (12х4Гб)

      Блок питания 1975W p/s – 2 шт.,

      Сетевой адаптер IBM NetXtreme II 1000 Dual Port Express Adapter,

      FC-адаптер IBM QLogic 8Gb FC Single-port HBA for IBM System x – 2 шт.,

      Дисковый массив IBM Storwize V7000 в составе:

      Дисковая система хранения IBM Storwize V7000 в комплектации: Два контроллера 8 GB RAM, 4 (четыре) порта iSCSI 1 GB/s, 8 (восемь) портов FC 8 GB/s, батареи хранения содержимого кэша.

      Жесткий диск IBM 600GB 2.5in SFF Slim-HS 10K 6Gbps SAS HDD – ХХХ шт.,

      Кабель 5 m Fiber Optic Cable LC-LC – 8 шт.,

      Кэш-память Cache 8 GB – 2 шт.,

      Лицензия для внешней виртуализации IBM Storwize V7000 External Virtualization – 3 шт.,

      Коммутатор для организации сети IBM System Storage SAN24B-4, 2 шт в составе:

      Коммутатор Express IBM System Storage SAN24B-4 (8 ports activated),

      Лицензия для активации портов IBM 8-Port Activation,

      Трансиверы SFP 8 Gbps SW 8-Pack – 2 шт.

      Windows Server 2012 Datacenter

      Вот в принципе то что нам понадобится для построения нашего кластера(пример взят из реального проекта), отдельно хочу сказать что по лицензированию Windows Server 2012 отдельная история, но в нашем случае мы выбираем Datacenter ввиду большого количества виртуалок которые будут у нас крутится (Datacenter позволяет запускать неограниченное количество виртуальных экземпляров). Отдельно замечу по языку ОС: рекомендую использовать английскую версию, ибо как говорит один знакомый MVP – «врага надо знать в лицо» да и от использования родного языка ОС вы получите «бонус к карме» что обязательно скажется на вашей зарплате на ваших профессиональных навыках.

      3. Построение схемы SAN

      На данной схеме мы видим вариант 4-х узлового кластера либо двух отдельных кластеров использующих одно и тоже хранилище (но разные пулы дисков). Данная схема позволяет увидеть как мы можем использовать наше оборудование. В случае с нехваткой пространства на полке, мы всегда можем подцепить полку расширения(у Storwize V7000 по интерфейсу SASx4 6 Gb/s – 24 Gb/s) и использовать новое пространство для своих нужд.

      В реальном примере мы будем собирать двух узловой кластер состоящий из СХД IBM Storwize V7000, двух FC коммутаторов Express IBM System Storage SAN24B-4, двух серверов IBM System x 3850 X5 (на последующих скринах вы увидите элементы другого кластера – не обращайте внимания). Причем полка и коммутаторы уже задействованы под реально работающий кластер Hyper-V, хочу отметить что во время работ ни одно животное не пострадало ни одно наше действие не сказалось на работе действующих сервисов. Что конечно и ожидалось – ведь это решение корпоративного уровня позволяющее решать наши задачи без каких либо остановок и перезагрузок. Итак ниже схема по которой мы будем собирать наше оборудование:

      4. Настройка SAN

      Настройка SAN сетей конечно совершенно отдельная тема и для этих целей зачастую нужен дорогостоящий квалифицированный специалист по данной тематике, но как всегда кластер нам нужно собрать «еще вчера» и коммутатор вроде не страшный.. значит разберемся сами. Настраивать оптические коммутаторы Brocade желательно в следующей последовательности(а в большинстве случаев у вас будет именно такой правда с наклейкой другой компании, в нашем случае это IBM SAN24B-4 но на самом деле это Brocade 300B)

      Общая последовательность настройки SAN коммутаторов Brocade

      1. Подключим все оборудование согласно схеме и включим все элементы нашей сети

      2. Подключится к COM(RS232) порту (9600-8-1, no-flow-control) спец. кабелем

      3. С помощью ПО “Putty” либо “HyperTerminal” из дистрибутива windows подключится к COM порту к которому подключен наш коммутатор.

      4. Ввести логин/пароль

      5. Изменить имя коммутатора командой switchname

      6. Настроить сетевые параметры командой ipaddrset , все необходимые параметры у вас запросит мастер настройки.

      7. Меняем Domain-ID:

      switchdisable — этой командой дезактивируем коммутатор.

      configure — этой командой меняем Domain-ID (диапазон 1…239), отвечаем yes на вопрос о изменении фабрики, следующий параметр как раз Domain-ID, а все остальные параметры оставляем по умолчанию (просто нажимаем Enter).

      switchenable – этой командой активируем коммутатор.

      8. Перезагрузка командой reboot

      9. Cмотрим что у нас на коммутаторе командой switchShow – если оборудование подключено, но WWN не показаны смотрим порт portShow

      10. Командой alicreate “ ”, “ ; ; … ” можно создать алиасы: alicreate «Storwize1», «50:05:22:11:00:11:22:33» потом можно будет использовать этот алиас при создании зоны в след.пункте

      11. Создаем зоны, зоны создаем по wwn, т.е. алиасам созданным в предыдущем пункте. Зоны делаем из двух членов: инициатор(hba/виртуальный fc), таргет (порт дисковой системы или библиотеки и пр.)

      Читайте также:  Знакомства павлодар друг вокруг

      Для создания зоны используем команду zonecreate “ ”, “ ; ; … ”.

      zoneCreate «z_имязоны1″, «алиас_сервера1; алиас_дисковой_системы1»

      zonecreate «z_имязоны2″, «алиас_сервера1; алиас_дисковой_системы2»

      zonecreate «z_имязоны3″, «алиас_сервера2; алиас_дисковой_системы1»

      zonecreate «z_имязоны4″, «алиас_сервера2; алиас_дисковой_системы2»

      PS: Старайтесь создавать зоны, так чтобы в каждой зоне был 1 порт сервера и 1 порт устройства, лучше пусть у вас будет больше зон, чем все свалено в кучу.

      12. Создаем конфигурацию командой cfgCreate «cfgSAN1″, «z_зона1; z_зона2; z_зона3; z_зона4″. Если конфигурация уже есть то активную зону можно посмотреть командами alishow или cfgactvshow и добавить новую зону в конфигурацию командой cfadd “ ”, “ ; ; … ” и сохраняем конфигурациюcfgsaveфабрики и применяем конфигурацию с помощью команды cfgenable “ ”

      13. Если мы создали новую конфигурацию то активируем ее командой cfgenable “ ”

      14. Посмотрим на результат наших усилий командой cfgactvShow

      15. P.S. все это конечно можно сделать из GUI, попасть в которой мы можем через браузер прописав в адресной строке ip коммутатора, но это не путь джедаев 🙂

      16. Если мы все правильно настроили то в следующем разделе мы сможем отдать будущим узлам кластера необходимые ресурсы с СХД.

      5. Подготовка СХД

      Подготовим нашу СХД IBM Strorwize V7000 к работе(все узлы согласно приведенной выше схемы уже подключены, сама СХД быстро и легко настраивается по мануалам которые легко найдете на сайте IBM : http://pic.dhe.ibm.com/infocenter/storwize/ic/topic/com.ibm.storwize.v7000.doc/tbrd_bkmap_quickinstbk.pdf ) отдельно отмечу что наша полка поддерживает подключения хостов только через коммутаторы, в нашем случае это пара IBM SAN24B. После первичной настройки заходим в GUI нашей полки и нарезаем диски:

      5.1 Вставляем диски в нашу полку

      5.2 Переходим Physical Storage >Internal и контролируем их состояние

      5.3 Помечаем диски как Candidat

      5.4 Создаем массивы: Configure Storage – Select a different configuration. Выбираем необходимые параметры, в продакш рекомендую использовать только RAID 10 но это отдельная история требующая отдельного рассмотрения. После данных манипуляций мы сконфигурировали mdisk2 и mdisk3 а также так называемые пулы (pools). Пулы можно создавать при конфигурировании MDisk, а также в меню Physical Storage >Pools. Новые пулы мы назвали Pool3_HostBoot_HyperV2012 и Pool4_Cluster_HyperV2012 и связали их соответственно с mdisk2 и mdisk3.

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

      Переходим в VolumesAll Volumes и создаем диски с помощью функции (слева вверху) New Volumes, выбираем вид Generic, выбираем из какого пула будем создавать, указываем имя и объем . Для текущих целей нам необходимо создать следующие диски(названия даны исходя из текущей ситуации на конкретном оборудовании, вы называйте как хотите):

      QuorumDisk2 – кворумный диск, необходим для работы нашего двухузлового кластера.

      Host3OS – диск с которого будет загружаться ОС первой ноды

      Host4OS – диск с которого будет загружаться ОС второй ноды

      ClusterResourse2 – общий кластерный ресурс на котором будут хранится виртуальные машины.

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

      5.6 Подключим наши ноды к СХД в разделе HostsAllHosts.

      NewHost-FibreChanel Host— Пишем имя – Выбираем порты по которым этот хост подключен. Если мы все правильно сделали при настройке SAN коммутатора то полка должна без проблем найти активные нераспределенные порты подключенных устройств.

      5.7 Отдадим наши тома соответствующим узлам.

      VolumesallVolumes – выбираем том – Actions(либо ПКМ) – Map to host – выбираем хост.

      Аналогично все тома:

      6. Настройка Boot From SAN

      Итак мы имеем готовую к работе SAN сеть, осталось только установить на наши хосты операционные системы, установить все обновления, установить роль Hyper-V, компоненты средство отказоустойчивости кластеров, MPIO и собрать кластер.

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

      Так как зонирование мы уже настроили, следовательно проблем с «видимостью» оптических устройств не должно возникнуть, поэтому сразу заходим в BIOS FC адаптера .

      • Для адаптеров Qlogic(а именно они у нас и используются) нажмите при загрузке сервера Ctrl+Q.
      • В начале диалога нам предлагают выбрать адаптер для настройки – выбираем
      • Дальше в Configuration Settings

      • Выберите Adapter Settings ,
      • Включите опцию Host Adapter BIOS (enable)
      • Вернитесь в Configuration Settings, выберите Selectable Boot Settings.
      • Включите опцию Selectable Boot и выберите загрузочный LUN.

      • Повторить настройки для второго интерфейса FC адаптера
      • Установить ОС Windows Server 2012. Если установщик не увидел LUN, то, скорее всего, в образе не хватает драйверов для HBA-карточки.

      7. Подготовка к сбору кластера

      Подготовимся к сбору кластера, а именно необходимо установить компоненты: средство отказоустойчивости кластеров, MPIO, ну и естественно роль Hyper-V. Итак приступим:

      7.1 Установка ОС (если еще не установили) + все обновления.

      7.2 Установка Multipath I/O через Add Roles and Features Wizard

      Multi-Path Input Output — технология, позволяющая соединять устройства хранения и серверы, используя несколько портов или контроллеров, обеспечивая тем самым избыточность подключений. С помощью дополнительных компонентов физических путей (адаптеры, кабели, коммутаторы) создаются логические пути между сервером и хранилищем. При выходе из строя одного или нескольких компонентов, логика MultiPath позволит использовать альтернативный логический путь, сохраняя для приложений доступ к данным.

      7.3 Настройка MPIO

      После установки Multipath I/O можно открыть диалоговое окно Свойства MPIO из панели управления сервером (для Windows Server 2012: Server Manager-Tools-MPIO) либо командой mpiocpl. Не будем подробно освещать данный компонент, а настроим его применительно к нашему случаю.

      Переходим во вкладку Discover Multi-Paths, в нашем случае в списке появится устройство IBM 2145. Выбираем его и нажимаем Add, после добавления ОС попросит перезагрузку. После перезагрузки у нас будет виден только один диск(или несколько – по количеству отданных томов нашему узлу), посмотрев его свойства через оснастку diskmgmt.msc можно увидеть вкладку MPIO где можно тонко настроить необходимые параметры. По умолчанию MPIO выберет режим работы Round Robin With Subset т.е режим балансировки нагрузки, оставляем все по умолчанию либо настраиваем под себя. Вот и все.

      7.4 Установка Failover Clustering (средство отказоусточивости кластеров) через Add Roles and Features Wizard.

      Тут все стандартно, устанавливать нужно через Add Roles and Features Wizard. Выбираем Failover Clustering и устанавливаем.

      7.5 Установка роли Hyper-V

      Опять же все через Add Roles and Features Wizard. Ничего сложного, просто следуйте по пунктам, рекомендую оставить все по умолчанию. Необходимые настройки вы все равно будете делать позже, в процессе наладки работы кластера Hyper-V.

      8. Сбор кластера

      8.1 Проверка на возможность сборки кластера

      Перед тем как собрать наш кластер необходимо провести проверку на саму эту возможность. Запускаем Fileover Cluster Manager, далее – Validation a Configuration Wizard и указываем узлы будущего кластера. После проверки можно посмотреть отчет, где будут указаны ошибки, после устранения которых можно собирать кластер.

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

      8.2 Создаем кластер (Create Cluster)

      Запускаем Fileover Cluster Manager, далее – Create Cluster Wizard

      • указываем узлы будущего кластера
      • Пишем имя кластера и его ip адрес
      • Проверяем еще раз введённую информацию и запускаем процесс

      • После создания кластера читаем отчет и устраняем возможные ошибки
      • Открываем Fileover Cluster Manager и видим что у нас появился наш свежеиспеченный кластер из двух узлов, причем из доступных дисков мастер настройки выбрал наименьший диск в качестве кворума, второй диск используется в качестве кластерного ресурса. Также смотри Cluster Events на предмет ошибок – устраняем их.
      • Далее для размещения виртуальных машин нам надо сделать так чтобы конфигурация и виртуальный жесткий диск (VHD) были доступны одновременно на обоих узлах. Сделать такой ресурс мы можем используя решение именуемое Cluster Shared Volume. Технология Cluster Shared Volume не предъявляет никаких специальных требований, кроме наличия хранилища с общим доступом в отказоустойчивом кластере. Более подробно о данной технологии всегда вам подскажет google. Сделать это легко и просто: кликните ПКМ на нужном диске (не кворум), в меню выбираем Add Cluster shadow volume – профит! Диск будет смонтирован на C:ClusterStorageVolume1, так что все совместно используемые данные будут находиться там. В том числе и виртуальные машины. Причем если вы собрали кластер на основе ОС Windows Server 2008 R2 то на этом ресурсе могут располагаться только виртуальные машины, в Windows Server 2012 эти ограничения сняты.
      • Вот и все, осталось только проверить работоспособность!

      8.3 Проверка работоспособности кластера Hyper-v с помощью Fileover Cluster Manager

      8.4 Проверка работоспособности кластера Hyper-v с помощью Hyper-V Manager

      8.5 Проверка работоспособности кластера Hyper-v с помощью SCVMM

      Комментировать
      0 просмотров
      Комментариев нет, будьте первым кто его оставит

      Это интересно
      No Image Компьютеры
      0 комментариев
      No Image Компьютеры
      0 комментариев
      Adblock detector