[«Облака» и «потоки»] Другой путь. Смена направления потоков данных
Мы не можем обойтись без постоянного притока свежей информации. Но получить её недостаточно: необходимо обработать и проанализировать в максимально короткие сроки. Информация, как вода, должна постоянно перетекать от источников на периферию и в локальные дата-центры, а затем в облако, иногда возвращаясь обратно.
источник: images.pexels.com
Что изменилось в потоках данных?
Предприятия регулярно переносят данные между разными пунктами хранения, но их объемы растут намного быстрее емкости сети, и привычный способ перемещения информации по сетевым каналам становится все менее эффективным. На это, в частности, указывает недавно вышедший отчет Mass Data on the Go от компании Seagate.
Для иллюстрации все более колоссальных объемов корпоративных данных там приводится пример активных систем содействия водителю (ADAS). На начальном этапе развития ADAS их возможности ограничивались предотвращения блокировки тормозов и регулировки тягового усилия для противодействия пробуксовке. Уже сейчас эти системы в состоянии самостоятельно парковаться и предотвращать столкновения с использованием радара, но для перехода к полностью автономным автомобиля потребуются многие годы и бесчисленные петабайты данных.
Чем выше уровень автономии, на который нацеливаются проектировщики, тем больше информации им требуется. Для полной автономии может понадобиться до 20 ТБ в час в расчете на автомобиль, используемый для записи данных ИИ. А общий объем набора обучающих данных, полученных от группы таких автомобилей, составит не меньше 20 ПБ в час. Обработка всей этой информации происходит в гипермасштабных дата-центрах, но как перенести в них нужную информацию? На пересылку всего 1,5 ПБ данных, созданных 10–20 исследовательскими автомобилями, по гигабитному соединению корпоративного класса понадобится более 150 суток. За это время информация полностью потеряет свою актуальность и станет практически бесполезной.
Но это лишь один, самый яркий пример проблемы. Помимо него с аналогичными проблемами сталкивается приложения для мультимедиа и развлечений, обработки данных систем видеонаблюдения, здравоохранения и умного производства. Специалисты Cisco считают главной движущей силой нынешнего роста объема данных системы межмашинной связи (M2M), а в IDC прогнозируют резкий рост общемирового объема созданных данных: если в 2020 году он составил 64 ЗБ, то в 2025-м достигнет уже 180 ЗБ. Главным же «виновником» этого, по словам аналитиков, станет интернет вещей, особенно камеры и автоматизированные M2M-взаимодействия с участием цифровых приборов учета потребления коммунальных услуг, систем управления медицинским оборудованием и т.д.
Почему без периферии не обойтись
Десять лет назад перед предприятиями стоял простой выбор – хранить данные в публичном или частном облаке. Но сегодня этот выбор заметно расширился, а для оптимизации доступа к данным, их размещения, распределения и использования, организации все чаще прибегают к мультиоблачной и гибридной моделям. Аналитики IDC Storage Systems & Infrastructure Trends Survey выяснили, что в настоящее время централизованную архитектуру облачного хранилища использует 47% предприятий, но уже через два года их доля упадет до 22%. Напротив, доля гибридной архитектуры хранилища из централизованных и периферийных систем пока не так велико – 25%, однако через те же два года эта цифра вырастет до 47%.
Как видно из отчета IDC, непрерывный рост корпоративных данных приводит к постепенному смещению акцентов в сторону облачного ядра и периферии, и если в 2015 году там хранилось только 30% данных, то в 2020 году их доля увеличилась до 50%, а в 2025-м, согласно прогнозу, достигнет уже 70%.
Ограниченных возможностей сетевых каналов уже недостаточно для оперативного перемещения растущих массивов данных. Но помимо ограничений, связанных с сетевыми характеристиками и задержкой, есть еще несколько барьеров, осложняющих доступ к данным и их перемещение – нехватка волоконно-оптических каналов и совокупная стоимость таких услуг. Причем, как показывают опросы, наибольшее влияние на выбор решения для транспортировки или миграции данных предприятия оказывает именно последний фактор. Ну а выбор в пользу физических средств миграции данных в 78% случаев объясняется недостаточными характеристиками сети для передачи требуемых объемов информации.
Активнее всего данные создаются на периферии, ну а периферийные системы все чаще становятся важнейшим участком маршрута данных и ключевым элементом стратегии в области хранения. Они могут работать на периферии любой сети и, по сути, делятся на три уровня. Микропериферия расположена ближе всего к внешней границе сети и конечным точкам. На этом уровне происходит сбор наибольшего количества данных, а задержка не превышает 5 мс. Устройства сбора данных микропериферии – это обычно внешние накопители, соединенные с периферийными серверами либо по беспроводной связи.
Городская периферия работает уже на уровне города. Время отклика в такой системе заметно выше – 5-10 мс, намного выше и емкость ее хранилищ. Объектом сетевой периферии может быть небольшой центр обработки данных в здании головного офиса компании или какое-то количество стоек в коммерческом центре колокации. Ее близость к источникам данных и большая емкость делают такую систему хорошим выбором для транзакционные СУБД, систем поточной передачи мультимедиа и других приложений. Наконец, третий уровень периферии – макропериферия. Это крупномасштабные объекты со временем отклика 10–20 мс, обслуживающие до десяти арендаторов и расположенные на расстоянии 10–150 км от конечных точек. Как правило, это центры колокации или полноценные дата-центры с резервными магистральными каналами, которые всего на ступень ниже сетевого ядра.
На рост периферии оказывают влияние те же движущие силы, которые отвечают за рост данных. В первую очередь, это развитие технологий искусственного интеллекта, набирающие популярность Интернет вещей и 5G-сети. Кроме того, далеко не последнюю роль в этом играет конвергенция ИТ и операционных технологий в производстве, а необходимость дополнения облачных мощностей периферийными привела к появлению периферийных ЦОДов.
«Центр тяжести» данных теперь меняется
Бурное развитие систем периферийных вычислений приводит к сдвигу в сфере хранения данных, которые все больше распределяются между различными облачными и периферийными ресурсами. Данные в экосистеме «конечная точка – ядро» перемещаются по большему количеству маршрутов, чем раньше, а это значит, что их можно размещать вблизи приложений, чтобы обеспечивать максимальную производительность последних.
По мере накопления данных они приобретают собственную силу притяжения, действующую на приложения, сервисы и новые данные. Причем чем больше объем (или так называемая масса) данных, тем больше сила притяжения. На определенном этапе данные могут достичь критической массы, превратившись в своеобразную «черную дыру», затягивающую в себя приложения, сервисы и данные. Для того чтобы избежать этого, специалисты IDC рекомендуют размещать данные вместе с соответствующими приложениями, независимо от их местонахождения.
Одним из самых эффективных средств преодоления этого гравитационного колодца может стать корпоративный автомобиль или защищенный грузовик специальной службы, перевозящий петабайты данных. Они позволяют выполнять миграцию больших объемов данных гораздо быстрее, чем глобальная сеть. Однако здесь нужно понимать необходимость принятия строгих мер безопасности. Перевозимая информация должна быть зашифрованной на всех этапах транспортировки, а организациям в обязательном порядке необходимо учитывать требования регуляторов и законы о суверенитете данных.
Все дело в объемах этих данных. С появлением умных устройств объемы начали генерироваться сумасшедшими темпами. Недавно компания Seagate выпустила отчет «Массивные данные в движении», где коротко рассказала о перемещениях больших объемов информации. Чтобы вы понимали, насколько они велики, приведем пример.
Откуда берется такой объем данных?
Сегодня активно развиваются автономные транспортные средства — то есть автомобили, способные ездить без участия человека. Для того, чтобы машина умела ориентироваться в потоке и двигаться безопасно, необходимо ее обучить: собрать максимум информации о реальных дорожных ситуациях, разработать правильные алгоритмы реакции на те или иные события. Сейчас сбором такой информации занимаются исследовательские автомобили: каждый из них записывает до 150 Тбайт информации каждый день.
Более того, когда машины все-таки научатся обходиться без людей (достигнут так называемого пятого уровня автономности), каждая из них будет генерировать до 20 Тбайт информации в час! И значительную часть этих данных нужно обрабатывать — на уровне производителя этих машин, локального центра или даже города. Причем делать это максимально быстро, пока данные не потеряли актуальность.
Но автомобили — не единственный пример. Скажем, по оценке журнала Production Engineering Solutions, фабрика, на которой используется «умное» оборудование, генерирует около 5 Пбайт (петабайт, примерно 1 млн гигабайт) данных. По прогнозам специалистов в 2020 году если общий объем созданных данных составил 64 Збайт, то к 2025-му достигнет уже 180 Збайт, то есть увеличится почти в 3 раза.
Добавьте к этому огромный поток данных, который будут генерировать системы умных домов. Умными становятся даже самые банальные устройства вроде чайников — и ведь они тоже передают информацию. Большие объемы данных традиционно передают видеоустройства. Если еще 5-6 лет назад для того, чтобы организовать систему видеонаблюдения на предприятии или даже собственной даче, нужно было вызывать специалистов, покупать дорогое оборудование, протягивать кабельные соединения, то сегодня достаточно приобрести несколько IP-камер, объединить их в единую сеть и подключить к облаку.
Ради интереса просто оцените, насколько больше камер стало в вашем городе за последние годы. А ведь каждая из них — генератор значительного объема данных.
Когда облака уже не так привлекательны
Ну и что, скажете вы, — у нас уже даже маленькие города покрыты высокоскоростными сетями, по которым данные разлетаются за минуты. Но это не совсем так. Чтобы переслать всего 1,5 Пбайт даже по гигабитному соединению, потребуется… 150 суток! То есть тот же недельный объем данных от умной фабрики можно перекачивать почти 2 месяца! Согласитесь, теперь сценарий «записать на внешний диск и привезти лично» уже не выглядит таким странным.
Большие затраты времени на передачу информации по сетям — это не просто дискомфорт. Информацию можно сравнить с пакетом молока, который имеет определенный срок годности. До истечения этого срока молоко, как и данные, можно использовать в самых разных целях — таких, каких сочтете нужными. А после истечения — ну разве что творог. Когда информация теряет актуальность, ее тоже можно разве что сохранить для архива, но для обработки она уже не годится.
Проблему пытаются решить за счет локализации дата-центров. Если раньше (еще 6-7 лет назад) они были, простите за тафтологию, централизованными, то сегодня растет спрос на периферийные системы хранения и обработки информации. Чем ближе к источнику появления этих данных находится дата-центр, тем быстрее можно будет начать ее обработку.
По прогнозам Grand View Research рынок периферийных вычислений до 2028 года будет расти в среднем на 37,4% ежегодно. А количество предприятий, которые используют централизованную модель, за следующие пару лет упадет более, чем в 2 раза — это уже прогнозы из отчета Seagate.
Но нехватка объемов все равно дает о себе знать. Согласно недавно проведенным опросам (они вошли в отчет Future-Proofing Storage) более половины представителей бизнеса сообщили, что емкость хранилищ их локальных центров обработки данных исчерпана. Одним из выходов стала как раз физическая транспортировка информации. Но, конечно, с помощью не простых жестких дисков, а целых систем хранения и транспортировки.
Новые решения для новых потребностей
Современные рынок предлагает на этот счет несколько решений. Например, Lyve Data Transfer Services от Seagate — комплексная услуга по хранению и транспортировке данных, которую можно оформить по подписке (правда, в России она пока недоступна). Такие сервисы используют несколько вариантов накопителей. Lyve Mobile Shuttle — самый маленький (по объему и физическим размерам) модуль емкостью до 16 Тбайт, который можно разместить, скажем, в багажнике автомобиля.
У такого модуля есть свой 4-ядерный процессор, средства шифрования и небольшой сенсорный экранчик, так что он может работать напрямую с другими накопителями — даже подключать компьютер не придется.
В свою очередь, Lyve Mobile Array — это уже более емкое решение, которое может стать промежуточным звеном между полевыми вариантами и централизованными хранилищами. В один модуль Lyve Mobile Array (такие поддерживают
шифрование Seagate Secure AES, интерфейсы Thunderbolt 3 (40 Гбит/c), USB 3.2 (10 Гбит/c) и PCIe Gen3 можно записать до 96 Тбайт информации.
Так что, как это ни покажется странным обычному обывателю, в обозримом будущем значительная часть данных будет перемещаться по обычным физическим каналам. Возможно, именно сейчас мимо вас проезжает очередной автомобиль с внушительным накопителем в багажнике, который везет данные в ближайший дата-центр на обработку. Конечно, облака по-прежнему остаются актуальными, но объемы информации растут гораздо быстрее, чем пропускные способности каналов.
Про облачные вычисления, разумеется, знают все. Даже на бытовом уровне мы привыкли складывать лишние данные в облако – отдавать их на хранение в центр обработки данных. Что уж говорить о компаниях, которые используют в работе интернет вещей – те самые «умные датчики», которые окружают нас почти повсюду.
Интернет вещей везде – от огромных заводов до частных ферм, на крышах наших домов, на улицах и шоссе, и уж точно во всех видах средств передвижения, какие только существуют в мире. Датчики IoT собирают и генерируют петабайты данных, и их обработка давно вышла на промышленный уровень, а это требует совершенно иных вычислительных мощностей.
Периферийные вычисления: потому что не хватает облачных
Как уже было сказано, традиционно обработка данных, собираемых устройствами IoT, ведется на крупных централизованных облачных серверах. Проблема заключается в том, что эти масштабные центры обработки данных находятся далеко от самих устройств, выдающих или собирающих информацию. Эти устройства и есть периферия.
Потоку информации нужно время, чтобы дойти от периферии к центру, что тянет за собой целый ряд проблем.
- Пониженная надежность. Если устройства IoT установлены там, где нет стабильного доступа к интернету, то пересылка данных в облако наталкивается на помехи, а зачастую и на потерю данных.
- Риски безопасности. Когда данные идут через интернет в огромных объемах, перехватить их – дело техники и настойчивости. Но ведь это данные интернета вещей, зачастую обладающие секретностью или персональные.
- Затраты на передачу данных. Если речь идет о промышленном интернете вещей, необходимо обеспечить поистине масштабную пропускную способность сети, чтобы принимать данные на обработку в облако.
А ведь можно сделать так, чтобы камеры наблюдения, установленные в гипермаркете, производили анализ покупательского поведения в режиме реального времени, не выводя данные из торгового зала, – достаточно дать им немного вычислительных ресурсов. Повышается скорость анализа, а значит, и получения интересующих выводов. Именно здесь и начинаются периферийные вычисления.
Незаметная периферия: клад вычислительных ресурсов
Между ЦОД и видеокамерой, которая следит за покупателями в зале, есть масса устройств более низкого уровня – например, шлюзы, коммутаторы, хранилища данных. Эти устройства находятся физически гораздо ближе, но задействуются для служебных задач: сбора, консолидации, передачи данных. Да и к самой камере можно подключить некие вычислительные мощности.
Именно на этом и строится концепция периферийных или граничных вычислений (edge computing). Суть в том, что часть процессов обработки данных переносится из центра обработки данных именно на эти служебные устройства. Либо, если их нет или не хватает, они вводятся в ИТ-инфраструктуру и помещаются как можно ближе к источнику данных – датчикам, камерам, считывателям…
Это основа концепции периферийных вычислений – максимально приблизить место обработки данных к их источнику.
Зачем это нужно на практике?
Расскажем на примере собственной производственной линии. Один завод Seagate производит миллионы единиц техники в квартал и триллионы в год. Все производство глубоко автоматизировано, и система управления принимает от 20 до 30 решений в секунду.
Если при таких темпах производства в какой-то части линии произойдет сбой, просто невозможно ждать, пока данные с конвейера дойдут до центральной системы, пока она их проанализирует, пока отправит автоматике соответствующую команду. Мы не можем тормозить весь конвейер, если что-то пойдет не так.
Поэтому мы перенесли систему распознавания и автоматического устранения сбоев на вычислительное оборудование, имеющееся прямо в цехах. И задержки в работе конвейера сократились с сотен до 10 миллисекунд.
Как это можно сделать?
Вышеописанное выглядит как шаг назад, но нет. Мы не переписывали систему распознавания сбоев и не делали ее проще. Она по-прежнему принимает огромное количество данных с конвейера и выдает не менее 30 решений в секунду. Мы перенесли ее на другое аппаратное обеспечение, находящееся рядом с отдельными частями конвейера.
Есть три способа добыть мощности для работы сложной системы вне ЦОД.
- «Туманные вычисления». В этой реализации периферийные вычисления производятся на устройствах внутри сети, которые мы не привыкли считать вычислительными: роутеры, сетевые коммутаторы, шлюзы, хранилища данных и даже IPTV-приставки. Программа-оркестровщик собирает их в некое виртуальное вычислительное устройство, на котором и работает система обработки данных.
- Мобильные вычисления. Здесь вычислительные устройства и конечные устройства IoT объединяются в одну мобильную сеть. В качестве вычислительных устройств используются любые мобильные устройства, способные «ловить сеть», – они предоставляют свои ресурсы для работы разных частей системы обработки данных. Как правило, рядом физически присутствует базовая станция или контроллер радиосети, который обеспечивает связь.
- «Клаудлет». Это в буквальном смысле мини-ЦОД, выделенный из основного ЦОД и установленный в месте, где собираются данные. Мощный компьютер со стабильным интернет-соединением, по функциям подражающий основному ЦОД (это решается за счет виртуальных машин) и способный обеспечивать работу системы обработки данных.
Каждый из способов внедрения периферийных вычислений имеет свои преимущества и области применения: «туманные вычисления» дешевле, клаудлеты более функциональны и надежны, а мобильные периферийные вычисления незаменимы там, где интернет малодоступен или недоступен вовсе.
Если вам нужна инфраструктура периферийных вычислений…
…то есть несколько аспектов, которые необходимо учитывать при ее проектировании.
1. Центр против периферии
Каков анализ затрат и выгод от использования общедоступного облака (от различных поставщиков) по сравнению с периферийными вычислениями (закупка и настройка оборудования, приобретение услуг частного облака), и что наиболее подходит для потребностей и бюджета вашей компании? Насколько быстрая окупаемость у каждого из вариантов? Прозрачное ценообразование поставщиков готовых решений позволяет планировать расходы на хранение в долгосрочной перспективе.
2. Взаимодействие с данными и время отклика
Какова скорость, с которой необходимо анализировать исходные данные и принимать решения на основе полученных данных? Системы управления и защиты устройств IoT всегда должны быть на пределе, даже если контуры управления работают относительно медленно. Крайне важен вопрос времени отклика. Чем дальше вычислительные ресурсы находятся от периферии, тем медленнее возможное время отклика и анализа новых данных. Периферическая инфраструктура обеспечивает мгновенный доступ к данным без дорогостоящих задержек.
3. Подключение и передача данных
Какие данные должны обрабатываться на периферии, а какие централизованно? В решении этого вопроса важную роль могут сыграть соображения пропускной способности и подключения. Если пропускная способность сети низкая и ненадежная, локальная обработка данных на периферии должна превалировать. Если соединение быстрое и надежное, больше данных можно отдавать в ЦОД, оставляя на периферии те, для которых требуется моментальная обработка или закрытое хранение.
4. Политика кибербезопасности
Проектирование инфраструктуры периферийных вычислений должно согласовываться со всеми действующими правилами и политиками кибербезопасности. Любая сеть, даже включающая периферийные ресурсы, может быть очень небезопасной, если она неправильно спроектирована и настроена. В безопасном хранилище на периферии данные защищены от атак, повреждения и удаления. Важный момент: репликация данных с несколькими зонами на периферии гарантирует, что данные будут всегда доступны в случае сбоя.
5. Набор технических навыков
Наконец, важно понять, обладает ли команда ИТ-специалистов набором навыков для разработки такой системы? Возможно, потребуется глубокое погружение в каждый из вышеперечисленных пунктов, прежде чем принимать какие-либо важные решения о применении периферийных вычислительных решений в своей инфраструктуре.
Приемлемым выходом здесь может стать приобретение периферийных вычислений как услуги у компании-поставщика. Здесь все аналогично облакам: партнерство с надежным поставщиком решений для периферийных вычислений предоставляет компаниям новые мощности без необходимости глубокого погружения в технологию.
Периферийные вычисления как услуга
Как видите, организация периферийных вычислений – дело полезное, но хлопотное и технически сложное. Такая повышенная сложность часто вызывает нежелание со стороны руководства что-то менять в уже существующей системе обработки данных. Между тем есть несколько готовых решений с довольно простой интеграцией. Например, у нас это Seagate® Lyve Cloud, разработанная в сотрудничестве с компанией Equinix. Периферийные системы хранения предоставляются как услуга, а это позволяет клиентам легко масштабировать их вплоть до эксабайтных размеров и дольше хранить большие объемы данных. С помощью Equinix Fabric™ можно подключать источники данных к самым разнообразным периферийным и облачным приложениям и выбирать вычислительные услуги для работы в средах Amazon S3. То есть у клиентов есть полноценное облако, но размещено оно ближе к источникам данных, поэтому работает на периферии.
Вы можете узнать больше о наших решениях для периферийных систем вычисления на официальном сайте.
Облачные системы хранения — это все системы, в которых данные и файлы хранятся за пределами корпоративной сети, а доступ к ним осуществляется через публичную (интернет) или частную сеть. Эти данные могут храниться на другом континенте и у другого юридического лица, но пользуетесь ими вы в интересах своей компании.
Корпоративные облачные системы обычно делят на четыре типа:
- Публичные,
- Частные,
- Гибридные,
- Мультиоблака.
Давайте разбираться, зачем придумывать столько видов, и не является ли это изобретением велосипеда.
К публичным облакам мы привыкли как простые пользователи. У вас ведь, наверняка, есть хотя бы одно облако Google Drive, Dropbox, Яндекс.Диск или Облако Mail.ru? Эти провайдеры предоставляют услугу хранения данных: вам не нужно знаний в IT, за размещение, хранение и обеспечение безопасности данных отвечает другая сторона. Она же обслуживает серверы, обновляет программное обеспечение и заботится о том, чтобы в случае выхода из строя оборудования информация не пропала.
Для небольшой компаний, у которой нет требований к скорости передачи и больших наборов данных, генерируемых людьми и машинами, эта информация не ограничена секретностью, а совокупный объем данных ограничивается несколькими десятками Тб, вполне подойдет публичное облако.
Дополнительные преимущества: гибкость — рост и масштабирование ограничены только финансами заказчика, — а также доступ к обширному каталогу служб, включая приложения, вычислительные ресурсы и инструменты для отслеживания.
С плюсами понятно, теперь о минусах:
- Сложно хранить и использовать большие наборы данных. Чем больше у организации данных, тем больше времени нужно для их передачи из локальной среды на облачные серверы и обратно.
- Сложно с безопасностью и доверием. Есть компании с данными, которые по закону должны храниться в стране, есть просто персональные и критически важные для бизнеса данные. Многие руководители считают, что публичные облака не так хорошо защищены от злоумышленников и фишинговых схем.
- Непредсказуемость расходов. Компании переходят в облако, чтобы сохранить ресурсы: физические (не нужно выделять место под серверную), финансовые (не нужно тратить деньги на закупку оборудования и его поддержание), человеческие (меньше нагрузка на IT-службу). Но сэкономить получается не всегда. В публичном облаке клиенты платят за используемую пропускную способность — чем больше данных или перемещений, тем выше расходы. Организации, которые не уверены в будущих потребностях, выбирают публичные облака за гибкость, и только получив счета, понимают, во что эта гибкость может обойтись.
- Низкая скорость. Перенос всех локальных данных в облако — долгий процесс. Облачные провайдеры строго контролируют пропускную способность. На перенос архивов могут уйти годы, а пользователи не смогут быстро передавать данные в облако для анализа.
- Мертвые зоны. Данные с добычи шельфовой нефти, при обслуживании промышленных ферм на Ближнем Востоке или съемке фильмов о дикой природе в Сибири не всегда могут быстро и в полном объеме переданы на какой-то удаленный внешний сервер.
«Методы, которые работают для 1 Пб в публичном облаке, окажутся бесполезными для 100 ПБ — рост объема данных приводит к слишком большим счетам, недостаточной прозрачности и непредсказуемым расходам», — комментирует старший вице-президент и генеральный директор Seagate Рави Наик.
Компании, которые столкнулись с тем, что данные в публичных облаках двигаются медленно, их хранение и передача стоят дорого, а безопасность сомнительна, решают организовать своё локальное облако на базе мощностей компании или внешнего провайдера.
Вот несколько преимуществ частных облаков
- IT-отделы могут настраивать разрешения, доступ и мониторинг в облаке, чтобы обеспечить дополнительную защиту локальных данных.
- Компании имеют предсказуемые расходы.
- Право собственности на IP-адреса хранилищ тоже у организации, что важно для аудита или соблюдения нормативных требований.
- Скорость переноса данных и частота обращения к большим наборам данных ограничены только пропускной способностью оборудования компании.
- Сохраняется возможность доступа к информации членами команды с удаленных устройств.
Небольшие компании, которые хотят выбрать формат частного облака, могут использовать NAS-системы. О них мы рассказывали в этой статье.
Но есть два существенных недостатка:
Первый — сложность создания частного облака своими силами. Управление аппаратной инфраструктурой и обслуживание программных решений для перемещения и хранения данных лучше доверить экспертом. Если вам не хватает объемов NAS-систем, другие варианты займут больше времени и компетенций.
Второй — частное облако требует существенных капитальных расходов на оборудование и площади для расширения локальной инфраструктуры. Это снижает возможность быстрого развертывания и расширения суммарного объема хранилища.
В поисках золотой середины между негибкими, но надежными и закрытыми частными облаками, и гибкими публичными облаками специалисты решили объединить два вида: наиболее чувствительные с точки зрения безопасности и частоты обращения к ним данные оставить внутри компании, а внешние ресурсы использовать для расширения объемов в моменты пиковой нагрузки. Такой подход также позволяет оптимизировать экономическую составляющую.
Минус всего один: сложная структура. IТ-специалистам приходится управлять взаимодействием сразу двух облаков одновременно. Следить, чтобы данные не дублировались, были представлены в единообразном виде и не утекали вовне.
Мультиоблако является чуть более сложной формой всё того же гибридного облака: оно объединяет облака из разных мест для хранения и обработки информации. По определению аналитиков IDC, многооблачность — организационная стратегия или архитектурный подход к проектированию комплексных цифровых служб, которые предполагают получение облачных услуг от нескольких поставщиков. Это могут быть услуги прямых конкурентов, например, общедоступные хранилища от разных поставщиков, а также предоставление инфраструктуры как услуги (Iaas) или ПО как услуги (SaaS) одним или несколькими поставщиками.
«Многооблачную инфраструктуру сложнее развернуть, и управлять ей также сложнее, поскольку для каждой облачной платформы предусмотрены собственные инструменты, оптимизированные для работы с ней. Кроме того, смежные функции управления данными или аналитики, предлагаемые поставщиками общедоступных облаков, чаще всего разрабатываются для использования с инфраструктурой конкретной платформы и при попытке интегрировать их с другими общедоступными облачными платформами могут работать с ограниченной функциональностью или не работать вовсе», — комментирует Эндрю Смит, руководитель исследования IDC.
Многооблачные и гибридные облачные среды решают разные задачи. Они могут облегчить доступ к данным и их анализ, повысить их безопасность, сократить расходы и обеспечить администраторам более полноценный контроль.
Недавно мы рассказывали о перемещении данных на периферию и росте вычислений в этих средах и, как следствие, необходимости перенести хранилища ближе к источнику данных, чтобы обеспечить быстрый обмен информацией. Так вот многооблачность является тем ответом, который позволяет организовать хранение данных в соответствии с актуальным трендом смещения одновременно на периферию и в центр.
Но из-за сложности организации такой среды, как показывает опрос IDC, проведенный в рамках исследования Rethink Data для Seagate в 2020 году, только каждая третья компания внедрила у себя многооблачные среды. А ещё, согласно недавнему исследованию Deloitte, почти половина опрошенных компаний признаются, что внедрение облака оказалось сложнее, чем они думали.
Если вы поняли, что мультиоблачные и гибридные системы — это именно то, что нужно компании, и технически вы готовы к такому переходу, стоит обдумать ещё пять аспектов:
- Совокупная стоимость владения. Если бюджет ограничен, выбор можно сделать в пользу публичного облака, которое обеспечивает минимальное соотношение стоимости владения и ресурсов. Частные облака могут потребовать больше вложений на начальных этапах, но со временем оказаться более выгодными.
- Различные функции данных. Персональные данные и финансовые документы лучше хранить в частных облаках, тогда как анонимизированные могут принести больше пользы, если анализировать их с помощью инструментов публичного облака.
- Увеличение объема данных. Физическое оборудование не всегда успевает за растущими требованиями к емкости. Хранилище в публичном облаке поможет восполнить пробел.
- Перемещение и репатриация данных. Поскольку инструменты анализа данных все чаще включают функции ИИ и машинного обучения, компании репатриируют данные — перемещают из публичного облака в частные стеки для локального анализа.
- Изменение требований к безопасности данных. Потребители и надзорные органы требуют проводить тщательную проверку компании, что тоже влияет на выбор варианта архитектуры. Хотя в последние пять лет публичные облака стали значительно безопаснее, часто невозможно переложить всю ответственность на провайдера.
Хорошие новости в том, что востребованность мультиоблачных вычислений и вероятность завязнуть в этой запутанной архитектуре у клиентов понимают и провайдеры услуг хранения данных. Конкуренция за этот растущий рынок заставляет их развивать сервис и выпускать всё более совершенное ПО. Оно решает задачу оркестрации (управления) данными и обеспечивает их быстрое свободное движение. Так что корпоративные облачные системы постепенно становятся проще и доступнее для понимания и использования бизнесом.