Еще совсем недавно весь ИТ-рынок активно обсуждал «аутсорсинг всего и везде». Затем стала актуальна тема виртуализации. Сегодня разговоры ИТ-специалистов витают вокруг мобильных сервисов, больших данных и облаков. Попробуем разобраться, что влияет на выбор аппаратной части облака.
В зависимости от целевого назначения облака будет меняться и набор оборудования, который используется для его построения. При планировании облачной инфраструктуры необходимо продумать несколько важных вопросов: частное или публичное облако мы строим, создаем его с нуля или интегрируем с уже существующей ИТ-инфраструктурой, каковы целевые показатели, какие нам известны ограничения. Все это влияет на конфигурацию аппаратных средств и программных компонентов будущего облака.
Для любого инфраструктурного решения, в том числе облачного, самый подходящий способ снижения первоначальных затрат — это поэтапное наращивание функциональных возможностей.
Если рассматривается вариант публичного облака, то вопрос масштабируемости надо учитывать в первую очередь. При этом уменьшаем использование классических архитектур, масштабируемых вертикально, и максимально заменяем их на горизонтально расширяемые системы.
То есть экономичней вычислительную мощность наращивать путем увеличения количества серверов малой и средней конфигурации вместо наращивания количества процессоров (или их замены на более многоядерные версии) в многопроцессорных системах. Примерно такая же ситуация и с хранилищами: выбираем для облака такие решения, где можно добавлять множественные узлы (серверы) хранения, а не дисковые полки к одной паре контроллеров.
Например, при планировании СХД можно отметить, что вернулся из глубины истории подход использования дисков, подключенных непосредственно к серверу (подключение DAS). Набор подобных серверов с дисками может быть преобразован в единую систему хранения данных — программно-определяемые хранилища. Для этого на рынке существует множество решений: VMware VSAN, EMC ScaleIO, Red Hat GlusterFS, Ceph и другие. Использование подобного подхода позволяет снизить затраты $/Тб и получить хорошие возможности в части масштабирования.
Помимо масштабируемости при любом типе облака желательно предусмотреть разделение по уровням производительности для систем хранения. Однако соотношение между быстрыми и медленными уровнями для публичного и частного облаков (и даже между двумя частными облаками) будут различными. Для определения этого соотношения при построении публичного облака необходимо ориентироваться на внешние запросы клиентов. Например, если вы строите сервис, подобный «google-яндекс-дроп диск», то вкладываться в SSD-хранилище с высокой долей вероятности окажется экономически не выгодно.
При создании частного облака обязательно исследуем профиль нагрузки существующих приложений. Технические ИТ-руководители могут удивиться после проведения анализа, узнав, что у них запись в системы хранения превалирует над чтением. А ведь данное понимание значительным образом меняет архитектуру хранения, делая возможным смещение акцента в сторону расширения пула флэш-хранения.
Интеграция с существующей инфраструктурой предсказуемо влечет за собой многочисленные ограничения — дешевле сделать выделенный облачный сегмент.
Также необходимо учитывать, что для автоматизации предоставления инфраструктурных ресурсов в облако потребуется адаптировать средства системной оркестрации, например, разработать соответствующие коннекторы. Соответственно, чем меньше разнообразия в оборудовании, тем проще (дешевле) автоматизировать процессы предоставления IaaS.
В целях унификации начинают меняться классические сегменты, например такие, как выделенная сеть хранения. Если использовать набирающую обороты облачную платформу OpenStack, то большинство референсных архитектур от различных производителей вообще не подразумевают использование Fiber Channel. Похожая ситуация и для VMware: переход на VSAN снижает долю FC-решений в пользу Ethernet. Здесь главное не переусердствовать и не выкинуть сеть хранения заодно с FC в целом.
В части оборудования для системы резервного копирования критериями выбора являются программное обеспечение для резервирования, наличие выделенных сетей хранения, требования к RTO/RPO. Программная платформа организации управления облачными ресурсами на это оборудование влияет в меньшей степени.
В части систем информационной безопасности все очень индивидуально. Например, наличие криптошлюзов определенного производителя чаще всего влечет за собой приобретение других криптошлюзов этого же вендора. К облаку это отношения не имеет, если у вас нет цели предоставлять VPN как сервис, в таком случае потребуются дополнительные ресурсы на будущие вычислительные узлы.
Также могут появиться дополнительные средства управления и мониторинга, которые уже адаптированы для выбранной платформы управления облаком. В целом, для сервисов, организующих предоставление IaaS, обязательно потребуются ресурсы для размещения и функционирования, в связи с чем образуется специальный сегмент управления облаком.
По части выбора типа процессора в серверах, где будут запускаться виртуальные машины, стоит провести внимательный ценовой анализ, прежде чем выбирать топовые многоядерные процессоры. В таком случае можно получить более дорогостоящее решение, т. к. цена процессора растет нелинейно при увеличении количества ядер: например, CPU с 15 ядрами может стоить в три раза дороже, чем с восемью. В конфигурациях, где общее количество ядер составляет порядка 30, для сохранения соотношения RAM/vCPU может потребоваться установить около 1,5 Тб оперативной памяти, что не всегда реализуемо в серверах высокоплотной установки. Таким образом, на основную часть оборудования, с точки зрения соотношения $/ядро, сегодня выгодней установить 8-10-ядерные процессоры, нежели
Ограничения по свободному месту в существующих шкафах или недостаток площадей в целом будут явным образом влиять на плотность установки оборудования. Если места мало (или оно очень дорого), включаем в рассмотрение высокоплотные системы (четыре полноценных
При рассмотрении аспектов, влияющих на выбор аппаратной инфраструктуры, может потребоваться рассмотреть широкий спектр критериев для формирования итоговой конфигурации. Ряд производителей предлагают программно-аппаратные комплексы, позволяющие сформировать облачное решение на основе собственных протестированных базовых архитектур. С их помощью можно собрать облачное ядро быстро и с высокой целевой готовностью к запуску в эксплуатацию. В рамках подобных конвергентных решений предоставляются в базовом виде готовые физические и виртуальные вычислительные ресурсы, сети, возможности хранения на нескольких уровнях производительности. В большинстве решений есть также встроенный мониторинг и средства резервного копирования. Программное обеспечение для управление облаком — портал самообслуживания, системный и бизнес-оркестраторы, каталог сервисов — необходимо заказывать отдельно, но оно также может быть установлено в рамках поставки комплексного решения.
Сегодня на российском рынке обозначены готовые конвергентные и гиперконвергентные решения для построения широкого спектра инфраструктурных решений, подходящих для построения облака: CPS (Dell и Microsoft), Cloudate (AT Consulting), FlexPod (Cisco + Netapp), HP ConvergedSystem (HP), Lenovo Converged System (ранее известное решение под именем IBM PureFlex), Nutanix, Primeflex (Fujitsu), UCP (Hitachi Data Systems), VCE Vblock Systems (EMC, VCE).
На текущий момент и конечным потребителям, и системным интеграторам предоставляются широчайшие возможности для самостоятельного проектирования и создания как аппаратной, так и программной части под общие или специализированные задачи. Возможно, не все шаги будут простыми, поэтому может оказаться полезным использование чужого опыта для сокращения сроков развертывания и снижения стоимости внедрения облачного решения.
Автор статьи — системный архитектор компании AT Consulting.
