X

News, tips, partners, and perspectives for the Oracle Solaris operating system

Объявление о поддержке Solaris Cluster в доменах ввода-вывода LDoms

Guest Author
Если вы следите за разработкой пакета Solaris Cluster, то, вероятно, уже видели недавно опубликованное Рекламное объявление . В данной записи блога эта новая возможность поддержки рассматривается с более технической точки зрения.
Прежде всего, уточним, что имеется в виду именно страница, рассматриваемая в данной статье, речь идет о поддержке Solaris Cluster в областях ввода-вывода LDoms. Для получения дополнительных сведений о доменах ввода-вывода LDoms см. Руководство администратора LDoms . Если говорить просто, область ввода-вывода LDoms "владеет" по крайней мере одной шиной PCI в системе и поэтому имеет непосредственный физический доступ к устройствам, использующим эту шину. После этого область ввода-вывода может экспортировать службы в другие гостевые области в системе. Эти "службы" являются виртуальными устройствами, ставшими доступными для других областей.
В чем же заключается поддержка Solaris Cluster и гостевых областей LDoms? Можно создавать гостевые области в той же системе, где работает пакет SC, в области ввода-вывода и выполнять развертывание не высокодоступных приложений в эти гостевые области. Это обеспечивает лучшее использование оборудования и гибкость в отношении развертывания приложений. В настоящий момент мы работаем над обеспечением возможности управления высокодоступными приложениями изнутри гостевых областей LDoms, следите за новостями.
Завершив неофициальное описание и определение рамок, рассмотрим развертывание пакета Solaris Cluster 3.2 в подобных областях ввода-вывода LDoms. Прежде всего необходимо отметить, что на некоторых серверах LDoms доступна только одна шина PCI, и поэтому в подобных системах может быть только одна область ввода-вывода (которая по определению также будет являться контрольной областью). Этот случай развертывания показан на приведенном ниже рисунке.

Для указанной выше настройки необходимо отметить, что некластеризованные гостевые области используют общую сеть через контрольную область, в которой работает пакет SC. Это позволяет разделять пропускную способность между некластеризованными приложениями, выполняющимися внутри гостевых областей, и высокодоступными приложениями внутри контрольной области. Таким образом, при решении вопроса о количестве гостевых областей в системе и нагрузке сети необходимо учитывать требования к размеру. Подобные требования относятся к любой пропускной способности ввода-вывода, которая может совместно использоваться гостевыми областями и областями ввода-вывода. Отсутствуют какие-либо ограничения на использование функций виртуализации LDoms в гостевых областях, например различные виды устройств виртуальных хранилищ, динамическое назначение ЦП и т.д.
В следующем примере развертывания будет использоваться серверная платформа с несколькими шинами PCI. Это позволит создать в системе дополнительные области ввода-вывода и сделает возможными более интересные (и, возможно, более полезные для клиентов) случаи. В качестве целевой системы будет использоваться сервер Sun Fire T2000 (Ontario), поскольку на нем установлено две шины PCI. Имейте в виду, что подобной гибкостью обладают не все системы; в некоторых используется только одна шина PCI. В этом случае развертывания используется два сервера Ontario с разделенной шиной. Дополнительные сведения о настройке разделенной шины см. запись блога Алекса о настройках ldom разделения шины для T2000. Затем 4 полученные области ввода-вывода (2 на каждой системе Ontario) настраиваются как два различных кластера. На приведенном ниже рисунке изображено объяснение данного случая.

В указанной выше настройке шина pci@7c0 (bus_b) назначена "основной" области, а шина pci@780 (bus_a) – "альтернативной" области. Необходимо отметить, что в системе Ontario оба внутренних диска находятся на шине bus_b, поэтому к шине PCI (bus_a, разъем 0) "альтернативной" области добавлена двухканальная карта управляющего адаптера оптоволоконной шины для накопителей, предоставляющая локальное хранилище для образа ОС и т.д., а также доступ к общему хранилищу. Имейте в виду, что в такой ситуации диск с образом ОС должен поддерживать загрузку по оптоволоконной линии. На шине PCI bus_b также необходима другая карта управляющего адаптера шины для предоставления доступа к общему хранилищу. Таким образом используются все доступные гнезда ввода-вывода, и установка дополнительных сетевых плат в системе невозможна. Это означает, что на "альтернативном" кластере осталось всего 2 встроенных сетевых контроллера (e1000g0 и e1000g1) для подключения к общедоступным и закрытым сетям. Наличие одного сетевого контроллера для общедоступной сети не является проблемой (достаточно поддержки IPMP и SC), но для одного закрытого межузлового подключения необходимо использовать параметр custom команды scinstall непосредственно для установки кластера, поскольку при стандартном варианте установки необходимо как минимум 2 сетевых интерфейса закрытых сетей. Для наиболее важных развертываний, возможно, следует исключить подобную настройку, поскольку одно межузловое подключение в некоторых случаях может приводить к снижению доступности.
В приведенной выше настройке создаются два отдельных двухузловых кластера на двух системах T2000. Это полезно в случаях необходимости консолидации наиболее важного приложения и другого высокодоступного приложения на одном оборудовании для снижения издержек. Этот способ также подходит для тех случаев, когда необходимо обеспечение повышенного уровня изоляции (как в отношении ресурсов, так и с точки зрения административной изоляции) между различными приложениями, для чего требуются два различных кластера, обеспечивающие максимальную изоляцию.
В следующей настройке, которую мы рассмотрим, используются те же две системы Ontario с прежней настройкой разделенной шины, однако вместо создания двух различных двухузловых кластеров создается один четырехузловой кластер. Эта настройка показана на приведенной ниже схеме.

Обратите внимание на то, что два узла кластера, находящиеся на "альтернативных" областях, имеют только по одной плате межузлового подключения. Для установки кластера в такой настройке может потребоваться сначала установить четырехузловой кластер с одним межузловым подключением, а затем добавить дополнительное межузловое подключение к основным областям с помощью команды clsetup. Или можно сначала создать двухузловой кластер на основных областях, в которых имеется две платы межузловых подключений, а затем добавить к кластеру два узла альтернативной области с помощью команды clnode add после установки пакета SC. Например: clnode add -n node1 -c clustername -e node3:e1000g4,switch1
При выполнении указанной выше команды на узле node3 он добавляется к кластеру, используя node1 в качестве главного узла и одну сетевую плату e1000g4, подключенную к switch1, в качестве платы закрытого межузлового подключения. Кроме того, имейте в виду, что, хотя для четырехузлового кластера устройство кворума не является строго обязательным, в этом случае настройка устройства кворума определенно необходима, чтобы потеря одного физического компьютера не привела к потере целого кластера.
Указанная выше структура из четырех узлов может быть полезной, если для разворачиваемых приложений не требуется повышенный уровень изоляции двух различных кластеров, а необходима простота администрирования одного кластера. Обратите внимание, что в этих структурах доступны все возможности LDoms (моя любимая возможность: динамический перенос процессоров из одной обрасти в другую!), что делает развертывание очень гибким и экономичным.
Следует учесть, что приведенные в этом блоге структуры предназначены для систем Sun Fire T2000 первого поколения. В более новых системах, например в недавно выпущенных системах Sun SPARC Enterprise T5x20, назначение устройств немного отличается. Основные концепции развертывания пакета SC на таких платформах останутся прежними. Дополнительные сведения о системе T5520 приведены здесь . Узнайте мнение пользователей о технологиях CMT и UltraSPARC T2 в блоге Аллана Пэкера .
Надеюсь, этот материал был для вас полезным. Следите за поддержкой пакетом Solaris Cluster гостевых областей LDoms, что позволит выполнить кластеризацию гостевых областей LDoms и привнести в них все возможности управления данными/приложениями пакета SC.
Ашутош Трипатхи - Solaris Cluster Engineering Александр Шартр - LDoms Engineering

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.