Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Миграция локального хранилища данных в облако требует тщательного планирования. Данная статья от разработчиков компании DST Global, поможет в процессе принятия решений, обращая внимание на критические факторы.
Миграция вашего локального хранилища данных в облако — эффективное и масштабируемое решение для хранения данных — требует тщательного планирования. Вам нужно будет оценить влияние затрат, преимущества масштабируемости, прирост производительности, структуры управления и требования соответствия, не говоря уже о последствиях для безопасности и конфиденциальности.
В этой статье будут рассмотрены эти критические факторы, а также представлен общий обзор проблем, связанных с переносом ваших данных в облако.
Понимание перехода: от локальной среды к облаку
Традиционные локальные хранилища данных имеют ограничения — значительные первоначальные инвестиции, ограниченная масштабируемость и огромные затраты на обслуживание. Поскольку предприятия сталкиваются с растущими потребностями в данных, эти ограничения могут препятствовать масштабируемости и гибкости, что приводит к операционной неэффективности.
В этом отношении перемещение вашего хранилища данных в облако становится привлекательным решением, поскольку оно предлагает эластичные ресурсы, экономичное масштабирование и управляемые услуги, устраняя тем самым многие недостатки локальной среды. Тем не менее, внедрение облака не является универсальным решением, такие соображения, как суверенитет данных , безопасность и задержка. поскольку на решение могут повлиять
Например, глобальное предприятие с переменными рабочими нагрузками может процветать благодаря облачному хранилищу данных, используя его масштабируемость по требованию для эффективного использования ресурсов. И наоборот, организация с конфиденциальными данными, подлежащими строгому нормативному контролю, может выбрать локальное решение для обеспечения более жесткого контроля.
Приведенные выше сценарии подчеркивают необходимость взвесить преимущества и ограничения каждого подхода, создавая основу для углубленного изучения плюсов и минусов облачных хранилищ данных.
Плюсы и минусы облачного хранилища данных: факторы, которые следует учитывать перед миграцией локальной инфраструктуры
Действительно, облачные хранилища данных предлагают убедительное решение для многих организаций благодаря своим моделям оплаты по мере использования, плавной масштабируемости и сокращению накладных расходов на обслуживание. Однако пригодность облака зависит от индивидуальных вариантов использования, которые мы рассмотрим далее, чтобы вы могли принять обоснованное решение.
Стоимость последствий
Переход на облачное хранилище данных сопряжен со многими финансовыми соображениями. На начальном этапе этот сдвиг потенциально может снизить капитальные затраты, поскольку отпадает необходимость инвестиций в физическую инфраструктуру. Модель ценообразования в облаке с оплатой по факту использования предлагает переменную структуру затрат, позволяющую предприятиям платить только за используемые ими ресурсы хранения и вычислительные ресурсы, что приводит к значительной экономии.
Тем не менее, при переходе в облако крайне важно учитывать общую стоимость владения (TCO), включая некоторые «скрытые» затраты, которые часто упускаются из виду. Подумайте о комиссиях за передачу данных (исходящая плата), стоимости услуг по управлению и обеспечению безопасности хранилища данных, а также о потенциальных расходах на дополнительные функции или более высокие уровни производительности. В целом масштабируемость облака — это палка о двух концах: хотя она позволяет предприятиям без проблем справляться с возросшими нагрузками, она также может привести к неожиданным затратам, если ею не управлять разумно.
Например, рассмотрим компанию, которая традиционно имела большой локальный центр обработки данных. Эксплуатационные расходы включали амортизацию оборудования, электроэнергию для питания и охлаждения, а также выделенный ИТ-персонал для обслуживания. При переходе в облако компания переходит на модель подписки, оплачивая вычислительные ресурсы и ресурсы хранения по мере необходимости. Первоначально эта модель снижает затраты за счет исключения инвестиций в оборудование и снижения счетов за электроэнергию. Однако по мере роста использования данных компания может выбрать услуги более высокого уровня для повышения производительности, непреднамеренно увеличивая ежемесячную стоимость подписки. Таким образом, структура ценообразования выбранного поставщика облачных услуг и способность компании управлять облачными ресурсами и оптимизировать их становятся решающими при определении того, снизятся или вырастут операционные расходы после миграции.
Другими словами, при оценке финансовых аспектов миграции хранилища данных в облако учитывайте конкретные потребности вашего бизнеса в данных, прогнозы роста и модели использования. Тщательный анализ поможет определить, соответствуют ли масштабируемость и эксплуатационная гибкость облака вашим финансовым целям.
И последнее, но не менее важное: помните, что наиболее экономически эффективное решение не всегда может быть самым дешевым на начальном этапе, но то, которое предлагает наилучшую ценность в долгосрочной перспективе.
Вопросы безопасности и конфиденциальности данных
Помимо затрат, переход на облачное хранилище данных создает новый ландшафт вопросов безопасности и конфиденциальности.
С одной стороны, крупные поставщики общедоступных облаков вкладывают значительные средства в меры безопасности, предлагая надежную защиту, которая может превосходить то, что отдельные предприятия могут реализовать локально. Шифрование данных как при хранении, так и при передаче, расширенные брандмауэры и регулярные проверки безопасности — это стандартные предложения, обеспечивающие защиту данных.
Тем не менее, передача конфиденциальной информации третьей стороне требует всестороннего понимания политики безопасности провайдера и соблюдения таких правил, как GDPR, HIPAA или PCI DSS. По этой причине крайне важно уточнить роли и обязанности по обеспечению безопасности данных и убедиться, что уровень безопасности поставщика соответствует стандартам конфиденциальности вашей компании.
Местонахождение данных является еще одной проблемой; физическое расположение серверов может повлиять на соблюдение национальных законов о защите суверенитета данных. Поэтому предприятия должны внимательно следить за тем, где хранятся и обрабатываются их данные.
Показательным примером является переход медицинской организации на облако. Хотя поставщик облачных услуг обеспечивает шифрование и сетевую безопасность, организация по-прежнему должна соблюдать правила HIPAA, которые требуют контроля над доступом к данным пациентов. Организация должна установить четкие политики доступа и убедиться, что облачная среда настроена для обеспечения соблюдения этих политик, что потенциально может потребовать дополнительных инструментов или услуг управления.
С другой стороны, финансовое учреждение, подчиняющееся строгому соблюдению нормативных требований, может счесть облачное хранилище данных неоптимальным. Причина проста.
В целом, хотя переход к облачному хранилищу данных может повысить возможности безопасности, он также передает некоторый контроль над конфиденциальными данными поставщику облака. Вот почему крайне важно, чтобы компании проводили комплексную проверку для исчерпывающей оценки рисков безопасности, которым они подвергаются при переходе в облако, и того, противоречат ли эти риски управлению данными и соблюдению требований, применимых к их отрасли.
Управление данными и соблюдение требований
Планируя миграцию облачного хранилища, рассматривайте управление данными и соблюдение требований как важнейшие элементы вашей стратегии.
Помимо оценки местонахождения и суверенитета данных, вы также должны оценить сертификацию центров обработки данных, чтобы убедиться, что они соответствуют отраслевым стандартам. Например, финансовые услуги могут потребовать оценки SSAE 18 , а здравоохранение может потребовать соответствия HITRUST CSF. Другим отраслям, таким как государственные подрядчики США, может потребоваться все это и даже больше.
В зависимости от вашего варианта использования вам также может потребоваться использовать частные подключения, такие как AWS Direct Connect, Equinix Fabric или Azure ExpressRoute. Эти частные подключения могут повысить безопасность и соответствие нормативным требованиям, установив выделенное сетевое соединение между вашим помещением и поставщиком облачных услуг. Эта настройка сводит к минимуму подверженность общедоступным уязвимостям Интернета и повышает надежность передачи данных.
поставщика облачных услуг Кроме того, вам также следует изучить политику хранения данных и его способность поддерживать управление жизненным циклом ваших данных, гарантируя, что методы удаления и архивирования данных соответствуют юридическим и бизнес-требованиям.
Наконец, рассмотрите возможности поставщика по соблюдению требований и аудиту . То есть для проверки со стороны регулирующих органов и внутреннего аудита вам потребуются точные журналы и журналы аудита. Убедитесь, что выбранное вами облачное хранилище предлагает комплексные инструменты для мониторинга, отчетности и оповещений, которые поддерживают ваши рабочие процессы обеспечения соответствия.
Производительность и масштабируемость
Значительное улучшение производительности и масштабируемости, вероятно, является основной причиной, по которой многие организации переходят на облачные хранилища данных.
То есть облачные хранилища предоставляют гибкие вычислительные ресурсы, которые можно увеличивать или уменьшать в зависимости от меняющихся требований к обработке данных. Такая эластичность позволяет предприятиям справляться с пиковыми нагрузками без необходимости выделения избыточных ресурсов, оптимизируя использование ресурсов и затраты.
Кроме того, облачные решения, такие как Amazon Redshift, Google BigQuery, Microsoft Azure Synapse Analytics, Oracle Autonomous Data Warehouse и IBM Db2 Warehouse, используют массовой параллельной обработки (MPP), чтобы обеспечить максимальную производительность и масштабируемость. технологию
Например, погодное приложение может использовать облачное хранилище данных MPP для быстрой обработки и анализа огромных объемов метеорологических данных из нескольких источников. Это позволит предоставлять пользователям локализованные прогнозы погоды в режиме реального времени, а также плавно масштабироваться во время таких событий с высоким спросом, как штормы или волны жары.
Это только один пример того, как облачные хранилища данных обеспечивают эффективный запрос данных, позволяя проводить аналитику в реальном времени и быстрее принимать решения.
Еще одним преимуществом являются возможности глобального развертывания крупных поставщиков общедоступных облаков. Они предлагают несколько регионов и зон доступности, сокращая задержку за счет размещения данных ближе к конечным пользователям и обеспечивая более высокую доступность и возможности аварийного восстановления.
Например, розничная компания, испытывающая значительные всплески трафика в период праздников, может извлечь выгоду из облачного хранилища данных. Они могут временно масштабировать свои вычислительные ресурсы, чтобы справиться с растущим спросом на отслеживание запасов в реальном времени и аналитику клиентов, обеспечивая бесперебойную работу и удовлетворенность клиентов. После праздников их можно сократить, чтобы сократить расходы и сохранить эффективность.
В целом, облачные хранилища данных предлагают уровень производительности и масштабируемости, с которым с трудом могут сравниться традиционные локальные решения. Используя эти аспекты, предприятия могут оставаться гибкими и конкурентоспособными, имея возможность адаптироваться к меняющимся требованиям к данным.
Проблемы миграции и интеграции данных
Миграция в облачное хранилище часто сопряжена со сложными проблемами миграции и интеграции данных; давайте рассмотрим наиболее важные из них.
- Безопасность данных . Безопасная передача конфиденциальных данных имеет решающее значение. Меры защиты должны включать шифрование во время транспортировки и в состоянии покоя, чтобы предотвратить взломы.
- Совместимость форматов данных . Устаревшие системы часто используют форматы данных, которые могут не соответствовать современным облачным хранилищам. Например, финансовому учреждению может потребоваться преобразовать исторические данные о транзакциях из собственного формата.
- Интеграция бизнес-приложений . Обеспечение работы существующих приложений с новым облачным хранилищем может оказаться сложной задачей. Например, розничная компания, интегрирующая свою CRM-систему с облачным хранилищем, должна избегать простоев и несогласованности данных.
Решение этих проблем требует детального планирования, соответствующих инструментов миграции и, возможно, помощи экспертов по хранилищам данных для обеспечения бесперебойного процесса.
Заключение
В этой статье разработчики DST Global, подчеркивают, что успешная миграция облачного хранилища данных зависит от управления затратами, обеспечения безопасности данных, соблюдения нормативных требований и оценки преимуществ повышения производительности и масштабируемости. Расставив приоритеты между этими элементами, организации могут использовать потенциал облака для улучшения управления данными и значительно улучшить свои решения, основанные на данных, сохраняя при этом операционную и финансовую стабильность.
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Ижевск, ул. Воткинское шоссе, д. 170 Е, Технопарк Нобель, офис 1117
Задать вопрос по почте
Есть два типа миграции: постепенная и полная.
При постепенной миграции мы сначала переносим не самые критичные сервисы, всё остальное — потом. При полной миграции мы просто берем всё, что у нас есть, и сразу перевозим в облако.
Мы выделили 5 простых шагов:
Стратегия;
Инвентаризация и анализ;
План;
Дорожная карта;
Миграция.
Сначала нам нужно разработать стратегию миграции, чтобы оценить, нужно ли нам вообще ехать в облако: иногда этого делать не стоит. На втором этапе мы смотрим на всю бизнес- и IT-инфраструктуру и оцениваем риски, ценность и плюсы переезда в облако.
Далее, как и в старом добром видео, — у нас с самого начала должен быть какой-то план, которого мы должны придерживаться. Нам нужно понять, какие системы можно сразу перенести в облако, а какие проприетарные решения лучше оставить в локальной инфраструктуре.
Разработку дорожной карты мы выделили в отдельный пункт, потому что о ней часто забывают. Она поможет сразу определить, какие существуют временные рамки, риски, денежные затраты и т.п. Кроме того дорожная карта позволит выставить готовый таймлайн, по которому должны работать ваши инженеры.
Последний шаг — это провести миграцию, выполнив все подготовленные шаги.
Case Study
Какие проблемы могут возникнуть при миграции:
1. Многим коммерческим компаниям и финансовым институтам в наследство достался legacy-продукт в виде монолита, и они не знают, что с ним делать.
2. Несмотря на продвинутость клиентов и их знания о PaaS, немногие понимают архитектуру данного решения. Это может вызывать некоторые сложности.
3. Иногда клиент просит IaaS виртуалками, чтобы создать собственный PaaS: пользователю просто не нравится версия сервиса провайдера, которая чуть старее опенсорсной.
4. Клиент всегда прав, и это действительно так, но иногда у него бывает недостаточно опыта, чтобы провести определённые операции. Более того, он не общается со своим облачным провайдером.
Посмотрим, как облачная платформа Advanced от Cloud поможет решить эти проблемы.
Что такое Advanced
Решение OpenStack + KVM, на базе которого можно разворачивать как IaaS, так и PaaS-решения.
OpenStack — модульная платформа, состоящая из нескольких компонентов с открытым исходным кодом — их можно модифицировать под свои нужды. Чаще всего OpenStack по умолчанию используют с гипервизором KVM.
Мы уже знаем, что OpenStack — это довольно продвинутый и популярный инструмент, который используют многие зарубежные провайдеры. По большому счету Cloud Native — тренд нашего времени, который в свою очередь тоже связан во многом с OpenStack.
Примеры подходов cloud-native в виде PaaS. Среди них я выделил:
— Cloud Container Engine — сервис для развёртывания приложений на базе Kubernetes;
— DMS for Kafka — распределённый брокер сообщений с высокой пропускной способностью, горизонтальной масштабируемостью и потоковой обработкой данных;
— RDS for PostgreSQL — профессиональная платформа управления базами данных PostgreSQL.
Есть и другие сервисы, на базе которых работает Advanced. Разберём их подробнее.
Server Migration Service (SMS)
Служба миграции помогает переносить локальные физические серверы x86 или виртуальные машины из частных и публичных сред в облако.
Процесс миграции — это довольно простая история. На вашу исходную машину устанавливается агент, а в облаке зеркально по техническим характеристикам в вашей инфраструктуре разворачивается виртуальная машина, куда потихоньку начинают заливаться данные. Для Windows используется VSS, для Linux — Rsync.
Основное преимущество же сервиса в том, что нет никакого простоя. Пока ваше приложение в локальной инфраструктуре продолжает работать, параллельно с этим переносятся данные в облако. Как только перенос завершен, вам достаточно переключить приложение с локальной инфраструктуры на облако. Например, в DNS поменять адреса с вашей локальной инфраструктуры на облачные адреса.
Data Replication Service (DRS)
Похож на предыдущий сервис, только для баз данных. DRS помогает переносить БД в облако Advanced, а также синхронизировать данные в реальном времени.
Часто возникает вопрос, как переносить базы данных, делать бэкапы или другие действия. Именно тут Advanced предлагает готовый сервис, который подключается к вашей БД и начинает переносить таблицы и сами структуры.
Основная фишка такого сервиса — возможность не только импортировать, но и экспортировать данные. Если вам нужна offside-реплика вашей БД в своей локальной инфраструктуре, вы можете сделать её с помощью этого сервиса.
Image Management Service (IMS)
Сервис позволяет быстро создавать экземпляры виртуальных машин из образов, а также загружать, создавать и настраивать свои собственные образы.
Многие выходцы от VMware часто говорят, что хотят развернуть свою ванильную виртуалку из образа. Встречаются такие клиенты, которых приходится уговаривать заехать к облачному провайдеру, а они в свою очередь думают, что тот не позволит им развернуть ничего из своих образов. Инженеры Cloud подумали и сделали сервис IMS таким, чтобы он позволял не только использовать образ как основу для виртуальной машины клиента, но VMDK для VMware, VHDX для Hyper-V и QCOW2 для вашего OpenStack или KVM.
DAYU
Универсальная платформа для интеграции и работы с данными. Позволяет создавать комплексные интеллектуальные системы обработки данных.
Этот сервис — волшебная палочка. Он может всё, если вы работаете с данными и вам нужно перенести неординарные истории. В качестве источников данных могут быть S3-bucket, Data Lake Insight (DLI), Data Warehouse и пр. На выходе вы загружаете их в похожий сервис в облаке Advanced.
Case Study. Решение
Теперь у нас есть представление, как устроена миграция. Посмотрим на решение указанных ранее проблем:
1. Не надо монолитить. Если ПО не готово к облакам, мигрировать просто так не стоит. Но никто вам не мешает заказать у облачного провайдера уже готовый кластер, инфраструктуру или ресурсы, начать готовить и перерабатывать своё решение и адаптировать его к облаку, чтобы заехать чуть позже.
2. Оставьте в покое PaaS. Конфигурацию сервиса выставляет и регулируют Control Plane облака. PaaS представляет уже готовое коробочное решение, которое со стороны облачного провайдера, в частности Cloud, гарантирует работу данного сервиса, его отказоустойчивость, SLA. Попытка клиентов что-то изменять в этом сервисе может привести к тому, что их сервис упадёт, а провайдер помочь не сможет.
3. Лучше взять готовое, чем строить своё. Когда клиент пытается развернуть свой PaaS на IaaS, часто может произойти неприятная ситуация: некоторых кросс-интеграций и фичей, которые уже есть в готовом сервисе от провайдера, просто не будет в том решении, которое клиент построит сам.
4. Слушаем, консультируем, помогаем. Команда миграции проконсультирует клиента и поможет решить задачу. Нежелание клиента общаться с облачным провайдером иногда приводит к большим факапам.
Почему это актуально?
Статистическая оценка
По данным исследований, 68% компаний сейчас занимаются переходом с монолита на микросервисы. При этом из них 36% — крупные компаний, 50% — средние и 44% — малые.
Что касается роста рынка PaaS: 38% приходится на обычный публичный рынок и 30% на рынок гибридных решений. Мы наблюдаем рост спроса на различные виды PaaS. Так, спрос на сервисы хранения вырос в два раза. На потребления Kubernetes — в 3,5 раза, на базы данных — в 2,5 раза, а на сервисы информационной безопасности — в 5 раз.
Да и в целом спрос на рынке IT-услуг и IT-консалтинга вырос на 5%.
Примеры неудачной миграции
Разберем такой случай. Это будет обезличенная история, где собраны неудачные практики многих клиентов:
— Клиент развернул свою инфраструктуру (PaaS) на базе IaaS. В итоге он потерял возможность использовать интеграцию с соседними облачными сервисами.
— Клиент использовал Ansible вместе с Terraform. Теперь, чтобы «прикрутить» остальные сервисы, он должен начать дополнительную разработку.
— Клиент развернул свой кластер Kubernetes. Это зря потраченное время и не готовая к использованию инфраструктура.
Клиент вроде бы следовал всем принципам Cloud Native, использовал Terraform и Ansible для развертывания, но у него получился обычный кластер Kubernetes. Когда он начал сравнивать своё решение и аналогичное от Cloud, понял, что различные кросс-интеграции готовых решений для него недоступны. К ним относятся:
— Использование PVC на базе объектного хранилища Cloud;
— Использование NFS, как того же самого PVC;
— Использование балансировщиков нагрузки.
А всё потому, что у него была своя разработка Kubernetes.
Клиент пришёл в поддержку Cloud, попросил помощи в доработке интеграции. Но как бы специалисты ни старались, клиенту будет нужна своя команда, чтобы поддерживать подобного рода направления и разрабатывать интеграции, драйвера и пр.
Пример удачной миграции
Теперь перейдём к удачному кейсу. Начнём с плана миграции, как профессиональные архитекторы.
Как и в задачах по физике, у нас есть «дано»:
— Физические серверы;
— Kubernetes as a Service;
— MySQL, PostgreSQL.
И «решение» следующими опциями:
— Виртуальные машины с дисками Elastic Cloud Server;
— Cloud Container Engine — сервис для развёртывания приложений на базе Kubernetes;
— RDS — сервис для адаптации баз данных MySQL и PostgreSQL.
В существующий манифест добавлена пара аннотаций.
Дальше облако, зафиксировав в манифесте запрос от Kubernetes о развёртывании определённого типа PVC (s3fs), получает сигнал о том, что надо создать новый бакет и примонтировать его нужным драйвером к кластеру..
То же самое касается балансировщиков нагрузки, ingress и остальных компонентов Kubernetes. Все они в Advanced кросс-проинтегрированы с существующими сервисами в облаке, потому бэкендом выступает уже настоящий физический сервер, а не виртуальные сущности.
В итоге за одни выходные получили прирост в 12000 ядер. Причем оказалось, что среди этих 12000 ядер 8000 — клиента, а оставшиеся 4000 — ядра клиентов, которые решили расшириться просто параллельно в эти же выходные.
Кстати, команду Advanced вдохновил опыт миграции наших клиентов и сейчас мы запустили большую акцию «Переезжай совсем»: предлагаем гранты на миграцию в облако Cloud.
Лучше мигрировать не только IaaS, но и PaaS. Нельзя забывать о том, что PaaS, помимо хорошего инфраструктурного решения, которое позволяет упростить работу с приложениями и системами, предлагает ещё одну полезную опцию: вы делаете описание ваших приложений один раз и потом можете их интегрировать с различными облачными провайдерами. Если упадёт метеорит и один из дата-центров вашего провайдера “умрёт”, вы можете переехать к другому, просто перенеся манифесты и конфигурации, а не заниматься конкретной миграцией всех данных и виртуальных машин.