Первоначально этот пост появился на The New Stack .
Несколько лет термин «частное облако» имел негативный оттенок. Но, как мы знаем, технология — это скорее колесо, чем стрела, и как раз вовремя частное облако привлекает массу внимания, и все это в позитивном ключе. Статистика ясна: в исследовании Forrester Infrastructure Cloud Survey 2023 79% из 1300 руководителей предприятий, которые ответили, заявили, что внедряют частные облака. Согласно
Причины различны, и мы подробно их рассмотрим, но что еще важнее, какая архитектура является правильной для репатриации? Каковы основные принципы проектирования частного облака? И, наконец, как мне проектировать инфраструктуру данных с учетом требований ИИ?
Основная причина, по которой компании репатриируют, — это стоимость. Они экономят до 70% за счет репатриации. Это было публично доказано такими разными компаниями, как
Связанная, но не идентичная, предсказуемость. Частные облака обладают меньшей эластичностью, но большей предсказуемостью (ниже мы рассмотрим некоторые приемы эластичности). Для большинства ИТ-директоров, которые понимают свои рабочие нагрузки, этот компромисс того стоит. Для финансовых директоров это еще более простой выбор.
Вопросы безопасности на третьем месте. Это не значит, что публичное облако изначально небезопасно, это не так. Это говорит о том, что CISO не полностью доверяют своим партнерам по публичному облаку (на самом деле большинство поставщиков облачных услуг оставляют за собой право заглядывать в ваши бакеты) на этом фронте. В эпоху ИИ ставки только растут.
В связи с этим, контроль входит в список каждого ИТ-директора. Вместе с экономией затрат, предсказуемостью и безопасностью вы не только полностью контролируете свою инфраструктуру данных ИИ, но и эти данные доступны для потребления всеми вашими приложениями, что позволяет вам размещать свои модели в инфраструктуре данных ИИ, где стандарты безопасности могут быть установлены вами и вашей командой в соответствии с вашими уникальными требованиями к безопасности — даже физическим доступом.
Зрелость тоже имеет значение. Современное облако — это операционная модель, а не местоположение. Эта модель, когда-то бывшая эксклюзивным поставщиком основных публичных облаков, теперь повсюду — от периферии до ядра. Контейнеризация, оркестровка, микросервисы, программно-определяемая инфраструктура, RESTful API — это стандартные операционные процедуры. Неважно, где вы их запускаете, — а если это неважно, зачем вам платить в два-три раза больше?
Правила также играют свою роль, особенно по мере их развития. Некоторые архитектуры, некоторые географические регионы, некоторые сценарии развертывания (военные/разведывательные) изначально не требовали частных облаков, но теперь требуют.
Опять же, причины будут разными, но эффект тот же. Частное облако снова в моде. Вопрос в том: что изменилось за последние несколько лет?
Как было отмечено выше, частное облако, как и публичное облако, работает по облачной операционной модели. Периферийное облако работает по облачной операционной модели. Размещение работает по облачной операционной модели.
Эта операционная модель определяет определенную архитектуру, и раз за разом эта архитектура делает возможным современное озеро данных. Конечно, есть и другие архитектуры, но использование частного облака для создания вашего современного озера данных позволяет организациям платить только за то, что им нужно. Когда их бизнес растет, масштабирование становится таким же простым, как добавление дополнительных ресурсов в кластер. Редизайн не требуется.
Современное озеро данных — это наполовину хранилище данных и наполовину озеро данных, использующее объектное хранилище для всего. Уровень объектного хранилища — программно-определяемый, масштабируемый, облачный и производительный. Производительность настраивается путем выбора
Использование хранилища объектов с озером данных является стандартным, использование его с хранилищем данных является новым, что стало возможным благодаря форматам Open Table Formats (OTF), таким как Apache Iceberg, Apache Hudi и Delta Lake. Существует множество подробностей об этой архитектуре, которые выходят за рамки этой статьи. Для этого я рекомендую прочитать полную версию Keith Pijanowski
Эта архитектура разработана для реализации следующих принципов, которые являются основными принципами работы облака и, в более широком смысле, основными принципами частного облака:
Высокая производительность: в то время как частное облако может быть спроектировано для емкости, современное частное облако стремится обеспечить производительность в масштабе. Эта архитектура отдает приоритет инструментам, которые подчеркивают скорость и эффективность. Как говорит Джефф Безос, кто хочет платить больше и ждать дольше, чтобы получить это? Здесь применяются те же принципы: кто хочет медленнее?
Разделение вычислений и хранения: разделение этих компонентов обеспечивает повышенную гибкость и масштабируемость, позволяя выбранной вами инфраструктуре, услугам и инструментам преуспеть в соответствующих областях специализации.
Открытые стандарты: Открытые стандарты не только поощряют взаимодействие, но и обеспечивают будущее ваших инвестиций. Это охватывает не только решения с открытым исходным кодом, но и открытые форматы таблиц, которые мы рассмотрим. Не создавайте частное облако с устройством хранения по этим причинам (и потому, что они никогда не будут облачными).
Совместимость с RESTful API: Взаимосвязанность обязательна. Ваши инструменты должны использовать общий язык, а S3 должен служить языком общения для облачного хранилища. По этой причине не создавайте свое частное облако с помощью решения, ориентированного на POSIX, даже если оно заявляет о поддержке S3. Используйте реальную сделку.
Программное обеспечение/Инфраструктура как код: автоматизируйте и позвольте Kubernetes позаботиться об организации вашей инфраструктуры, что позволит вам абстрагироваться от сложностей ручного управления и обеспечит быструю и эффективную масштабируемость.
Улучшенная безопасность и соответствие требованиям: поскольку частные облака предоставляют выделенную инфраструктуру, они предлагают больший контроль над данными и улучшенные меры безопасности. Это особенно выгодно для отраслей, которые обрабатывают конфиденциальную информацию, таких как финансы и здравоохранение.
Соответствие нормативным требованиям: данная архитектура может поддерживать соблюдение нормативных требований, предоставляя настраиваемые параметры безопасности и средства контроля аудита для соответствия определенным отраслевым стандартам.
Запускаем ваше частное облако в действие
Мы видели несколько подходов к освещению частного облака. Все они могут работать; это действительно зависит от предприятия и варианта использования.
Гибридный подход с ограничением по времени: Гибридный подход с ограничением по времени по сути превращает публичное облако в холодное хранилище и наращивает ваш частное облако в течение некоторого периода времени (месяцы/кварталы, а не годы). Это включает в себя покупку и настройку инфраструктуры и программного стека в частном облаке. Затем вы указываете свой конвейер данных на частное облако, а не на публичное облако. Может быть некоторый период времени, когда вы можете делать и то, и другое. Однако цель состоит в том, чтобы использовать публичное облако как многоуровневое холодное хранилище, а частное облако как горячее хранилище. Со временем публичное облако переходит из холодного в замороженное, в то время как частное облако становится основным и доминирующим типом хранилища.
Это то, что сделал ведущий игрок в области кибербезопасности. Он начал с настройки частного облака совместно с MinIO и Equinix, а затем направил поток данных объемом 250 тебибайт (ТиБ) в день в этом направлении. Учитывая, что аналитика журналов имеет высокую функцию затухания с точки зрения эксплуатационной ценности, не потребовалось много времени, чтобы новое частное облако стало основным источником данных для поиска угроз. Это частное облако выросло почти до эксабайта (и скоро пересечет этот порог), и решение перенести эти рабочие нагрузки (фактически основной бизнес) в частное облако (с операционными расходами, а не капитальными), увеличило валовую прибыль бизнеса более чем на 2%. В результате эта компания имеет оценочный мультипликатор, которому завидуют ее коллеги.
Полная репатриация : бывают случаи, когда хранение приложений и данных как в публичном, так и в частном облаке не представляется возможным. В таких случаях вам нужно расстаться с вашим поставщиком облачных услуг. Это сложно, и даже с отменой платы за выход они делают это болезненным (мелкий шрифт в основном говорит, что все должно быть отправлено, чтобы получить какое-либо освобождение от платы за выход). Это вполне выполнимо; это просто требует немного больше планирования и немного больше деловых трений. В этом случае предоставьте свое облако colo или частное облако и стек приложений. Затем сделайте резервную копию грузовика данных или арендуйте сеть, чтобы переслать данные в инфраструктуру данных вашего частного облака. На этом этапе вы свободны, но рассчитывайте на двойную оплату за месяц или два, если вы из тех, кто любит пояс и подтяжки. Одна из ведущих потоковых компаний использовала этот подход, когда вышла из публичного облака. Она перенесла полэкзабайта в новое частное облако, включая все фильмы, шоу, документальные фильмы и т. д. Процесс занял около трех кварталов. Однако отдача была огромной, и сложность для команды, управляющей сервисом, значительно снизилась. Они также наслаждались приятным бонусом в виде поп-арта «
Частное облако Greenfield:
Это довольно простое предложение, и оно обычно включает в себя все новое. Проект новый, данные по проекту будут новыми (или относительно новыми) или сгенерированными из какого-то источника, который выходит в сеть (например, гигантский завод по производству или новый облачный сервис видео по запросу). Здесь вы определяете размер рабочей нагрузки — вы даже можете протестировать ее в публичном облаке — но идея заключается в том, что она с самого начала будет работать в частном облаке. Мы видим это довольно часто с инфраструктурой данных ИИ. Первые эксперименты проводятся в публичном облаке. Данные не так уж и значительны. Доступность графического процессора довольно хороша. Тем не менее, предприятие знает, что рабочая нагрузка должна находиться в частном облаке для производства — как для масштабирования, так и для безопасности, конфиденциальности и контроля. Одна из ведущих автомобильных компаний в мире недавно перевела свою полную инициативу по беспилотному вождению с системы, основанной на правилах, на систему, основанную на поведении реальных водителей.
Это поведение «изучается» из миллионов и миллионов видео и файлов журналов, которые поступают с ее транспортных средств. Хорошие водители, плохие водители, средние водители. Не только из видео, но и из других элементов телеметрии автомобиля, таких как торможение, ускорение, крутящий момент рулевого управления и т. д. Подход МО на основе правил имел масштаб петабайт; видео имеет масштаб эксабайт. Компания ни с кем не делится этими данными (действительно, у двух публичных облаков есть конкурирующие инициативы). Эта рабочая нагрузка ИИ — все 300+ серверов — всегда была инициативой частного облака.
Частное облако Brownfield:
Будем честны: мы это видим, но нам это не нравится. Это включает в себя попытки запустить высокопроизводительные рабочие нагрузки на жестких дисках, чтобы наложить MinIO на
Это работает, но редко является оптимальным решением. Это экономично (вы повторно используете оборудование), это низкое трение (нет закупок), но это редко бывает производительным. Тем не менее, мы включаем это сюда, чтобы быть всеобъемлющим. Это поднимает важный вопрос. Когда вы проектируете свое частное облако, в любом из сценариев планируйте неоднородность. Это гарантия и, честно говоря, должно быть частью плана. В одном из сценариев выше половина оборудования от Supermicro. Другая половина от Dell. Поскольку мир меняется и становятся доступными новые технологии, вашему программному обеспечению должно быть все равно.
Другие:
Есть еще два сценария, которые встречаются реже, но должны быть в смеси для рассмотрения. Один из них — гибридный подход с всплеском, а другой — подход с внешними таблицами. Оба связаны с гибридным вариантом, но могут не быть ограниченными по времени. В гибридном подходе с всплеском вы поддерживаете частное облако, одновременно проектируя его для плавного расширения или «всплеска» в публичное облако для дополнительной гибкости. Эта стратегия часто применяется для использования дополнительной мощности графического процессора или использования определенных облачных сервисов. В этой модели определенные задачи временно переносятся в публичное облако для обработки. После завершения анализа результаты отправляются обратно в частное облако, а затем ресурсы публичного облака выводятся из эксплуатации. У нас есть крупный клиент финансовых услуг, который делает это с расчетами кредитного риска и рыночного риска. Он использует публичное облако для некоторых вычислительных операций и объединяет его с озером данных частного облака, которое использует MinIO и Dremio. Прелесть облачной операционной модели заключается в том, что архитектура должна поддерживать операции в обоих местах. По сути, это улица с двусторонним движением.
В какой-то момент это была улица с односторонним движением, но мир изменился, и теперь у предприятий есть возможность выбора. С опцией внешних таблиц организации по-прежнему могут извлекать выгоду из принципов облачной операционной модели, интегрируя свои существующие облачные хранилища данных, такие как Snowflake и SQL Server, с озером данных, созданным на основе частного облака. Эта гибридная установка позволяет предприятиям извлекать выгоду из производительности, безопасности данных и открытого стандарта дизайна современного озера данных, при этом продолжая извлекать выгоду из существующих инвестиций в облачную инфраструктуру. Каждый крупный поставщик баз данных теперь предлагает поддержку внешних таблиц. Эта функциональность позволяет пользователям запрашивать данные в объектном хранилище, где бы они ни находились, как если бы это была обычная таблица в базе данных, без хлопот по миграции. Ваши данные остаются в частном облаке, но становятся доступными везде, где они нужны.
Заключительные мысли и советы
За эти годы мы стали участниками многих таких репатриаций/новых сборок частного облака. Одной из неожиданностей для команд стало повторное управление оборудованием. В облаке это прозрачно. DevOps и инженеры по надежности сайта взаимодействуют с инфраструктурой только на уровне API. Если виртуальная машина барахлит, завершите ее работу и запустите новую вместо нее. К сожалению, в новом частном облаке вместо того, чтобы просто выбросить оборудование и купить новое, нам приходится заставлять работать существующее оборудование.
Управление инфраструктурой — это вещь. Это приходит с территорией. Это не должно быть страшно, но это должно быть запланировано. Необходимо разграничение обязанностей между инженерами программного обеспечения/DevOps и инженерами центров обработки данных. Этот SME (эксперт в предметной области) в центрах обработки данных должен знать все тонкости всего оборудования. Он будет отвечать за все, что связано с оборудованием, включая сбои, замены и любое обслуживание.
Здесь важно программное обеспечение. Вот почему MinIO встроила возможность наблюдения в свою глобальную консоль. В мире частного облака вы должны использовать умное программное обеспечение и глупое оборудование. Но это программное обеспечение должно нести операционное бремя этого экономического изобилия. Ребята из аппаратного обеспечения просто не смогли построить слой возможности наблюдения, MinIO пришлось это сделать.
Если вы организация, которая развертывает раз в неделю, это означает, что каждое развертывание, вероятно, является зрелищем. Это связано с тем, что при нечастых развертываниях трудно предсказать и исправить ошибки. Когда развертывания идут не по плану, все сдаются на палубу. Обычно поток выглядит следующим образом:
Когда эти принципы CI/CD применяются на практике, один сильный инженер центра обработки данных, работающий в тесном сотрудничестве с другим сильным инженером DevOps/SRE, может легко управлять более чем 5000 узлов в частном облаке или colo-объекте. У нас есть клиенты, которые делают именно это. Как только вы следуете базовым принципам CI/CD, почти все может и должно быть автоматизировано, а инженеры центра обработки данных и DevOps будут фокусироваться только на тех задачах, которые не могут быть автоматизированы. Наконец, если вы это пропустили, colo являются синонимами нашего определения частного облака.
Размещение обеспечивает золотую середину между полностью локальной инфраструктурой и публичным облаком, предлагая преимущества обоих миров. Имея доступ к сетям высшего уровня и близость к поставщикам публичных облаков, размещение в Colo облегчает соединения с низкой задержкой и гибридные облачные конфигурации, обеспечивая эффективную передачу и обработку данных. Эта гибкость и потенциал для успешного развертывания гибридного облака имеют решающее значение для предприятий, стремящихся оптимизировать свои операции и сохранить конкурентное преимущество. Чтобы узнать больше о том, как это работает, ознакомьтесь с нашим