Референсная архитектура что это

Референсная архитектура Cloudera CDP Private Cloud Base

Введение и обоснование

Выпуск версии Cloudera Data Platform (CDP) Private Cloud Base означает появление гибридной облачной архитектуры следующего поколения. Ниже представлен обзор методов проектирования и развертывания кластеров («лучшие практики»), включая конфигурацию оборудования и операционной системы, а также руководство по организации сети и построению системы безопасности, интеграции с существующей корпоративной инфраструктурой.

Обзор Private Cloud Base

CDP Private Cloud Base – локальная версия Cloudera Data Platform (то есть развертываемая на площадке заказчика), которая сочетает в себе все лучшее из Cloudera Enterprise Data Hub и Hortonworks Data Platform Enterprise, а также добавляет новые функции и улучшения во всем стеке. Этот унифицированный дистрибутив представляет собой масштабируемую и настраиваемую платформу, на которой вы можете безопасно запускать многие типы рабочих нагрузок.

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

Основные изменения

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

Лучшее из CDH и HDP с добавленными аналитическими и платформенными функциями.

Уровень хранения для частного облака CDP, в том числе хранилище объектов.

Cloudera SDX для согласованной безопасности и управления в масштабе всей платформы.

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

Рекомендуемые шаблоны развертывания

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

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

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

Назначение ролей

Master (главный)

Узлы, которым присвоены роли «главных» (master), обычно управляют набором сервисов распределенного кластера. К ним относятся HDFS NameNode, менеджер ресурсов YARN, Impala Statestore, главный сервер HBase и мастер-сервер Kudu. Должно быть не менее трех главных узлов, на двух из которых будут HDFS NameNode и YARN RM. Все три требуют кворума узлов Zookeepers и HDFS Journal для отслеживания изменений метаданных HDFS, хранящихся на NN. Для достижения консенсуса большинства нужно минимум три узла. В кластерах из более 200 узлов, могут быть пять и более главных узлов.

Worker (рабочий)

Edge/Gateway (граничный узел или шлюз)

Граничные узлы действуют как шлюз между остальной частью корпоративной сети и кластером CDP. Многие сервисы CDP Private Cloud поставляются с edge ролями. Они используются вместе с конечными точками для вызовов REST API и соединений типа JDBC/ODBC из корпоративной сети. Если вы разрешаете трафику корпоративной сети проходить только к этим узлам, в отличие от прямого доступа к «мастерам» и «рабочим», это часто упрощает защиту периметра сети.

Ingest (узел приема)

Обычно узлы приема работают по той же схеме, что и рабочие узлы. Ключевыми требованиями для них являются несколько выделенных дисков как для ролей брокера Kafka, так и для ролей Nifi. Размер диска Kafka требует отдельного обсуждения, однако количество выделенных дисков пропорционально предполагаемому объему хранимых данных и настройкам длительности хранения и/или требуемой пропускной способности тем сообщений с минимум 3 узлами-брокерами для обеспечения устойчивости.

Utility (служебный узел)

Служебные узлы содержат сервисы и службы, которые позволяют управлять кластером и контролировать его. К таким сервисам относятся Cloudera Manager (CM) и связанные с ним сервисы управления Cloudera (CMS), СУБД Hive metastore (если она также размещена в кластере), хранящая метаданные от имени различных сервисов и, возможно, настраиваемые сценарии администратора для резервного копирования, развертывания специальных двоичных файлов и многое другое.

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

По периметру кластера устанавливают межсетевые экраны, поэтому объем сетевого трафика и число портов, используемых для внутрикластерной связи, будет значительным. Многие службы, такие как Spark, будут использовать динамические порты, чтобы роли мастера приложений, такие как драйвер Spark, могли управлять исполнителями, выполняющими работу. Внешние сервисы, такие как роли Hue и Hive on Tez (HS2), могут быть в большей степени ограничены определенными портами и сбалансированы по нагрузке, если это необходимо для обеспечения высокой доступности.

Cloudera поддерживает работу кластеров частного облака CDP с SELinux в режиме разрешения (permissive mode), однако Cloudera не предоставляет конфигурации политик SELinux для включения принудительного режима (enforcing mode). Если заказчику требуется принудительное выполнение SELinux, то необходимо самостоятельно протестировать и реализовать политики. Учитывая сложность платформы, Cloudera рекомендует придерживаться разрешающего режима или полностью отключить SELinux.

Диски операционной системы

Обычно операционную систему устанавливают на пару зеркалируемых дисков емкостью 4 ТБ или более, которые можно разделить с помощью диспетчера логических томов, обеспечивая достаточную емкость для журналов (логов) и временных файлов. Следует отметить, что файловая система /tmp и требования к логам могут быть значительными, и нужно предусмотреть достаточную емкость. Кроме того, мы также рекомендуем отключить Transparent Huge Pages (THP), настроенный демон и свести к минимуму подкачку (свопинг).

Поддерживаются файловые системы ext3, ext4 и XFS. Обычно XFS v5 используют для каталогов данных. Как правило, они монтируются как напрямую подключенные диски JBOD, чтобы максимально увеличить производительность ввода-вывода для HDFS в формате / data1, / data2, dataN для каждого соответствующего диска с данными. Обычно используют 12-24 диска емкостью 4–8 ТБ с максимальной емкостью 100 ТБ на каждый узел. Схема доступа к диску для мастер-сервисов несколько отличается от выделенных дисков, рекомендованных для узлов журнала Zookeeper и HDFS, и какого-нибудь отказоустойчивого хранилища, например, RAID 5 или 10 для каталогов HDFS NameNode. Чтобы повысить производительность чтения, диски следует монтировать как noatime. Полная информация о требованиях к оборудованию приведена в руководстве по релизу.

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

Поддерживающие инфраструктурные сервисы

Для Hive, Atlas, Ranger, Cloudera Manager, Hue и Oozie требуется реляционная СУБД. Их следует развертывать с учетом как устойчивости работы, так и производительности, поскольку неэффективная база данных будет негативно влиять на производительность кластера.

Интеграция средств безопасности

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

Kerberos используется в качестве основного метода проверки подлинности для служб кластера, состоящих из отдельных ролей узла, а также, как правило, для приложений. Корпоративные кластеры будут использовать существующий корпоративный каталог, такой как Microsoft Active Directory, для создания этих участников Kerberos и управления ими. Кроме того, конечную точку аутентификации для кластерных REST API и пользовательских интерфейсов, поддерживающих LDAP и SAML, предоставляет Apache Knox.

Авторизация

Apache Ranger предоставляет ключевую структуру политики, определяющую права доступа пользователей к ресурсам. Администраторы могут определять политики безопасности на уровне базы данных, таблицы, столбца и файла, а также управлять разрешениями для определенных групп, ролей или отдельных пользователей на основе LDAP. Также можно определить политики потока данных и потоковой передачи (NiFi, Kafka и т. Д.).

Apache Ranger позволяет поддерживать авторизацию через членство в корпоративной группе с помощью таких инструментов, как sssd или Centrify, синхронизировать права доступа к сервисам и данным с корпоративным каталогом. Затем эта авторизация периодически синхронизируется с соответствующими объектами Hive.

Для надежной аутентификации, целостности и конфиденциальности в сети коммуникации между службами кластера шифруются с использованием TLS 1.2. Cloudera Manager упрощает управление сертификатами TLS с помощью функции AutoTLS, которая позволяет администраторам определять и развертывать полностью интегрированную схему инфраструктуры открытых ключей (Public Key Infrastructure, PKI).

Заключение

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

Источник

Референсная архитектура управления ИТ

В области управления ИТ целый ряд стандартов и лучших практик традиционно используется компаниями в качестве ориентира: ITIL, MOF, TOGAF, PMBoK, BABOK, RUP и т. д. Однако специалистам всегда хотелось собрать все эти вещи воедино, чтобы получить общую картину управления ИТ. В 2014 году была выпущена первая публичная версия IT4IT — открытого стандарта и референсной архитектуры управления ИТ. IT4IT издан от имени The Open Group — уважаемой в области ИТ организации, которая является владельцем многочисленных стандартов, например TOGAF в части архитектуры или Single UNIX Specification. Соавторами IT4IT стали крупные международные компании: Shell, Hewlett Packard, Achmea, Accenture, AT&T, PWC, ING, Университет Южной Флориды, Nestle, Barclays, Procter & Gamble, NBC, Disney и др.

Предпосылки появления IT4IT

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

Однако и процессный, и системный ландшафт управления ИТ зачастую представляли собой «лоскутное одеяло». Различные стандарты и лучшие практики, такие как ITIL, COBIT, PMBoK, TOGAF и др., хотя и совершенствовались с целью взаимного соответствия, все же не воспринимались как единое целое. С системами автоматизации еще хуже — интеграция систем даже одного вендора не всегда была простой задачей, а уж если предстоит интегрировать смежные решения от разных производителей, нужны существенные вложения времени, денег и сил. В этой ситуации ряд крупных компаний организовали IT4IT-консорциум, в рамках которого и был разработан открытый стандарт управления ИТ — IT4IT и одноименная референсная архитектура управления ИТ.

Принципиальный подход

В основу IT4IT легло понятие цепочки ценности (value chain), описанное Майклом Портером в его книге «Конкурентное преимущество». Вся деятельность ИТ-организации была разделена на четыре основных потока создания ценности (value stream) и пять вспомогательных видов деятельности. Четыре потока создания ценности объединены и детализированы в виде референсной архитектуры управления ИТ.

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

При этом IT4IT не отменяет существующие стандарты и своды лучших практик (ITIL, TOGAF, PMBoK и т. д.), а скорее выступает «надстройкой», позволяющей соединить их вместе, и является не сводом рекомендаций, а предписывающим стандартом. Важным является и то, что IT4IT — полностью открытый стандарт. С более подробной информацией о нем можно ознакомиться на сайте opengroup.org/IT4IT.

Участие Hewlett Packard Enterprise в работах по IT4IT

Компания Hewlett Packard Enterprise принимала участие в разработке IT4IT с самого начала и, по сути, являлась единственным производителем программного обеспечения, вовлеченным в этот проект.

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

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

IT4IT можно использовать для оценки текущего состояния и планирования гармоничного развития управления ИТ — как в части процессов, так и в части автоматизации.

Источник

Референсные архитектуры: как построить программно-определяемый ЦОД?

Что такое SDDC?

Итак, что же такое программно-определяемый (или программно-конфигурируемый) ЦОД (Software Defined Data Center, SDDC)? Прежде всего, это центр обработки данных с высокой степенью автоматизации, практически не требующий физического вмешательства. Все компоненты инфраструктуры такого ЦОД виртуализированы, а управление им полностью автоматизировано с помощью программного обеспечения. В случае VMware SDDC это программное обеспечение vSphere. VMware vSphere обеспечивает виртуализацию на каждом уровне, включая уровни вычислительных, сетевых ресурсов и ресурсов хранения данных.

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

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

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

Для чего это нужно?

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

VMware SDDC включает в себя все программное обеспечение, необходимое для построения корпоративной инфраструктуры.

Продукты VMware SDDC включают в себя ПО виртуализации вычислений VMware vSphere, виртуализации хранилищ VMware vSphere и VMware vSAN, виртуализации сети VMware NSX, а также облачную платформу управления VMware vRealize и интегрированную систему VMware EVO.

Цель — получить гибкую, простую в управлении инфраструктуру ИТ, адаптируемую к меняющимся потребностям. Благодаря виртуализации вычислений, хранилищ и сетей SDDC меньше зависит от физического оборудования, базовой аппаратной платформы. Конфигурирование на основе политик и предоставление ресурсов ИТ по требованию упрощает управление ЦОД, расширение и обновление его инфраструктуры.

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

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

Ниже мы представим референсную архитектуру для создания программно-определяемого ЦОД VMware с использованием сертифицированных узлов и устройств Lenovo ThinkAgile VX, а также рассмотрим компоненты для интеграции локального облака VMware vRealize с облаком Amazon AWS.

SDDC на базе Lenovo ThinkAgile VX

Эта архитектура охватывает следующие программные продукты VMware:

Ниже некоторые компоненты VMware SDDC описаны подробнее.

Архитектура Lenovo для VMware SDDC предоставляет предприятиям облачное решение для управления всеми виртуализированными рабочими нагрузками. Эта референсная архитектура создана на основе серверных узлов Lenovo ThinkAgile VX и сетевого оборудования, предоставляет готовые к развертыванию и проверенные конфигурации.

Узлы Lenovo ThinkAgile VX предназначены для развертывания гиперконвергентного программного обеспечения (Hyper-Converged Infrastructure, HCI) от VMware. Они поставляют собой проверенное и интегрированное аппаратное и программное обеспечение Lenovo с гипервизором VMware ESXi. Это решение сертифицировано для работы с программным обеспечением VMware и отвечает функциональным требованиям к SDDC. Его цель — упростить развертывание, обеспечить быструю окупаемость инвестиций и снизить затраты на ИТ.

Функциональные требования к SDDC

Архитектура VMware SDDC. Разделение функций на кластеры упрощает масштабирование. Кластер управления обеспечивает изоляцию ресурсов.

Компоненты VMware SDDC

Основные компоненты VMware SDDC.

VMware SDDC содержит следующие компоненты:

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

VMware vSAN

VMware vSAN — это решение с программно-определяемой системой хранения (SDS), интегрированное с гипервизорои ESXi. VMware vSAN объединяет кэш на флэш-памяти диски на трех или более серверах, подключенных по 10GbE, в одно общее хранилище данных. Согласно исследованию Gartner, в ближайшие пять лет доля программно-определяемых СХД на мировом рынке вырастет до 50%.

VMware vSAN можно масштабировать до 64 серверов, причем каждый сервер поддерживает до пяти групп накопителей. Группа включает твердотельные накопители (SSD) и до семи жестких дисков (HDD). Производительность и емкость хранилища можно легко увеличить, добавив диски, флэш-память или серверы. Кэш-память используется для ускорения чтения и записи.

Основные нагрузки, размещаемые на vSAN. 64% составляют критичные для бизнеса приложения (по данным опроса VMware).

VMware vSAN использует распределенную архитектуру RAID: данные распределены по кластеру. Используется метод RAID-0, RAID-1 или RAID-5/6. В этом решении применяется управления на основе политик хранения (SPBM). Ресурсы хранения выделяются динамически на основе запрошенной политики, а не заранее, как во многих традиционных решениях.

Особенности VMware vSAN.

Виртуализация сети передачи данных

VMware NSX Data Center — это решение SDN, позволяющее создавать оверлейные сети с теми же возможностями, которые доступны в физической сети. VMware NSX можно использовать с гипервизором VMware vSphere, а также с несколькими другими гипервизорами. По сути, VMware NSX представляет собой набор виртуальных машин, которые совместно работают для поддержки оверлейной сети. Эти компоненты распределены по нескольким хостам или кластерам.

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

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

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

Сертифицированные узлы Lenovo ThinkAgile VX

Сертифицированные узлы Lenovo ThinkAgile VX на основе двухсокетных серверов Lenovo ThinkSystem SR630 в корпусе 1U подойдут для работы с широким спектром рабочих нагрузок, таких как базы данных, виртуализация и облачные вычисления, инфраструктура VDI, корпоративные приложения, приложения для совместной работы и электронная почта, потоковая передача мультимедиа, HPC и др.

Узел ThinkAgile содержит до 12 2,5-дюймовых жестких дисков SAS/SATA (SFF) с возможностью горячей замены или SSD-накопителей или четыре 3,5-дюймовых накопителя (LFF) с возможностью горячей замены, а также поддерживает до 10 накопителей SFF U.2 NVMe PCIe с горячей заменой.

Сертифицированный узел Lenovo ThinkAgile VX 1U с 4 отсеками для накопителей LFF или 10x SFF.

Сертифицированные узлы Lenovo ThinkAgile VX 2U на основе серверов Lenovo ThinkSystem SR650 аналогичны ThinkAgile VX 1U, но имеют форм-фактор 2U.

Сертифицированные узлы Lenovo ThinkAgile VX 2U с 16 отсеками для накопителей SFF, 12 LFF или 24 SFF.

Основные отличия такого варианте от сертифицированных узлов VX 1U заключаются в большем количестве слотов расширения и шасси с поддержкой до 24 2,5-дюймовых накопителей с горячей заменой или 14 3,5-дюймовых накопителей SAS/SATA с возможностью горячей замены, либо накопителей SAS и 8 на SSD-накопителями U.2 NVMe PCIe. ThinkAgile VX 2U также поддерживает до двух графических адаптеров NVIDIA.

Сертифицированные узлы Lenovo ThinkAgile VX 2U4N на основе Lenovo ThinkSystem SD530 — это сверхплотный двухпроцессорный сервер с форм-фактором 0,5U. С четырьмя узлами ThinkAgile VX 2U4N, установленными в корпус ThinkSystem D2 Enclosure, либо в ThinkSystem Modular, вы получите платформу высокой плотности 2U для корпоративных и облачных рабочих нагрузок.
ThinkAgile VX 2U4N может содержать до шести 2,5-дюймовых накопителей SAS/SATA с возможностью горячей замены и до четырех твердотельных накопителей PCIe U.2 NVMe.

Сертифицированные узлы Lenovo Think Agile VX 2U4N.

Системы ThinkAgile VX Series можно настраивать для любого сценария использования. Они поставляются с VMware ESXi и настроены для работы с vSAN.

Для сегмента SMB компания предлагает платформы Lenovo ThinkAgile серии VX2000 и VX3000:

Lenovo System Networking RackSwitch G8052 — это коммутатор Ethernet, разработанный для центра обработки данных. Он предлагает до 48 портов GbE и до 4 портов 10GbE, предусматривает резервные блоки питания, вентиляторы и различные функции высокой доступности.

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

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

Гиперконвергентное хранилище с использованием vSAN

Общая емкость для виртуальных машин кластера управления составляет 9 ТБ. Это при условии наличия двух виртуальных машин в режиме высокой доступности. Добавим 50% для потенциального роста. Это означает, что необходимо 13 ТБ. Большая часть данной емкости используется некоторыми виртуальными машинами SQL-сервера и зависит от среды заказчика. Для кластера управления требуется в общей сложности до 26 ТБ. Эту емкость можно получить, используя четыре сервера с двумя группами дисков на сервер. Каждая группа дисков состоит из одного 400 ГБ SSD и трех жестких дисков по 1,2 ТБ. Общее количество жестких дисков составляет 3 x 2 x 4 = 24, что дает емкость 26,2 ТБ.

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

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

Тест Yahoo (YCSB): результаты узлов Lenovo

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

Тест YCSB был запущен на виртуальных машинах Ubuntu 16.04.4 LTS с mongodb v3.6.3 и механизмом хранения «WiredTiger». Каждая виртуальная машина имела 2 виртуальных ЦП, 4 ГБ памяти и 50 ГБ памяти.

Тест был выполнен с 48 и 96 виртуальными машинами. Кроме того, четыре другие виртуальные машины Ubuntu 16.04.4 LTS с клиентами YCSB использовались для моделирования нагрузки на виртуальные машины mongodb. Чтобы оценить систему ввода/вывода, для достижения целевой скорости 5000 операций с базой данных в секунду использовались 125 одновременных потоков.
Были протестированы три разные рабочие нагрузки, каждая с разным соотношением операций чтения и записи. Использованы следующие рабочие нагрузки:

Сравнение производительности для рабочей нагрузки при 80% операций чтения и 20% операций записи.

Тест YCSB выполнялся на четырех сертифицированных узлах Lenovo ThinkAgile 1U. Узлы, использованные для тестирования ESXi 6.7, были оснащены 2 процессорами x 6130 (16 ядер, 2,1 ГГц) и 384 ГБ системной памяти, а узлы для ESXi 6.7u1 — 2 процессорами Intel Xeon Scalable Gen2 2 x 6230 (20 ядер, 2,10 ГГц). и 384 ГБ памяти. Виртуальные машины были равномерно распределены по четырем машинам. Для теста YCSB 48 ВМ используют 9,8 ТБ, а 96 ВМ — 19,6 ТБ емкости.

Для гибридного массива vSAN каждый из четырех серверов использовал две группы накопителей, каждая включала твердотельный накопитель емкостью 800 ГБ и три жестких диска емкостью 1,2 ТБ, то есть всего 8 кэш-накопителей и 24 жестких диска емкостью с общей емкостью хранения 27 ТБ. Для флэш-массива vSAN каждый из четырех серверов использовал две группы, каждая включала твердотельный накопитель емкостью 800 ГБ и два твердотельных накопителя емкостью 3,84 ТБ, то есть всего 8 SSD под кэш и 16 SSD-накопителей общей емкостью 43 ТБ.

Результаты для 48 виртуальных машин показывают лишь незначительное улучшение при работе с флэш-памятью. Результаты для 96 виртуальных машин демонстрируют заметно лучшую производительность для 96 виртуальных машин при работе с флэш-памятью (all-flash) по сравнению с гибридной системой. Это доказывает, что флэш-память гораздо быстрее при больших нагрузках ввода-вывода, как и ожидалось.

VMware Cloud Foundation

VMware Cloud Foundation (VCF) — это единая гибридная платформа для развертывания VMware SDDC как частного облака и для интеграции с публичными облаками. Это решение предоставляет программно-определяемые сервисы для управления вычислениями, хранением, сетями и облаком для различных рабочих нагрузок. Оно упрощает установку, обновление и компонентов SDDC благодаря управлению их жизненным циклом.

Возможности автоматизации обеспечивает новый компонент VMware SDDC Manager. ПО SDDC Manager автоматизирует установку и управление жизненным циклом vSphere, vSAN и NSX — от запуска и настройки до обновления, а также установку и настройку ПО vRealize Log Insight, vRealize Operations и vRealize Automation.

Cloud Foundation объединяет VMware vSphere (вычислительные ресурсы), vSAN (хранилище) и виртуализацию NSX (сеть) в один стандартный интегрированный пакет. Cloud Foundation можно развернуть в локальном частном облаке или использовать как сервис публичного облака.
VCF поставляется либо в виде интегрированного аппаратного стека, либо в виде пакета программного обеспечения для установке на оборудовании заказчика. VCF поддерживает развертывание компонентов SDDC на широком спектре физических серверов (vSAN Ready Nodes) и сетевых коммутаторов, формируя гибкую гетерогенную инфраструктуру для поддержки различных рабочих нагрузок. В частности, VCF можно установить на сертифицированных узлах Lenovo ThinkAgile VX.

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

Проверенные архитектуры Validated Design

Комплексные и тщательно протестированные схемы для разработки и эксплуатации программного ЦОД

Проверенная архитектура VMware Validated Design предоставляет комплексные, прошедшие всестороннее тестирование схемы для разработки и эксплуатации программного ЦОД.

Архитектуры VMware Validated Design — это комплексные архитектуры для развертывания и настройки полноценного программного ЦОД VMware в широком спектре сценариев с подробными рекомендациями по эффективной эксплуатации.

Источник