Все средства массовой информации последнее врем живут и дышат только Олимпиадой. Дабы не нарушать этот тренд и не упускать возможность “поспекулировать" на этом событии, позволю себе немного порассуждать на тему взаимного проникновения технологий в спорт и спорта в технологии.
По некоторым данным олимпиада в Сочи стала большим событием не только для спортсменов и болельщиков, но и для российского IT сообщества, т.к. явила собой пример использования последних веяний IT индустрии для спортивных мероприятий.
На чём всё крутится?
В качестве платформы для быстрого разворачивания вычислительных мощностей организаторами была выбрана облачная среда Microsoft Windows Azure, работающая поверх гипервизоров Hyper-V, расположенных в дата центрах Microsoft, автоматизацию бухгалтерского учета, логистики и бюджетирования делали с помощью Microsoft Dynamics AX. Были подняты распределенные системы видео и аудио стриминга, множество веб-порталов, баз данных и других приложений, обеспечивающих проведение этого события планетарного масштаба. Помимо облачных мощностей специально для олимпиады была также создана и локальная сеть ЦОДов.
Основная проблема
Вся эта инфраструктура генерирует огромное количество данных – только представьте, сколько различных типов статистики, документов, отчетов, медицинских данных, видео и аудио контента генерируется за короткий отрезок времени проведения игр! Это петабайты информации. А теперь представьте, что весь этот контент должен быть доступен 24х7 в течение игр и в виде архивов/резервных копий ещё очень длительное время – ведь эта информация в дальнейшем используется для различного рода аналитике, а вся финансовая и логистическая отчётность должна храниться годами в соответствии с действующим законодательством в соответствующих областях. Да, я намекаю на то, что все эти данные надо как-то длительно и эффективно хранить, а ещё неплохо бы это делать дёшево!
Но с окончанием Олимпийских игр, эти данные практически моментально станут фиксированными – дорогие решения, ориентированные на модификацию имеющегося контента и скорость доступа уже не будут подходить.
Система хранения такой «lazy data» должна отвечать трем требованиям:
- Доступность данных — данные должны быть доступны в любой момент времени для аналитики или восстановления (в случае резервной копии);
- Масштабируемость хранилища – должна быть возможность как легко увеличить, так и уменьшить объем хранилища любым инкрементом (диск, сервер);
- Стоимость хранения – хочется хранить данные на недорогих, легко заменяемых носителях.
К этим трём основным вопросам глобальной проблемы хранения “Big Data” я бы прибавил ещё один немаловажный аспект – удобство развертывания, мониторинга и контроля над хранилищем данных. Ну и в качестве наглядного примера я попытаюсь кратко прокомментировать, как именно решает вышеупомянутые задачи Acronis Storage:
Храним данные надёжно
Для гарантированно надёжного хранения данных, Acronis использует технологию собственной разработки, которая обеспечивает избыточность с помощью применения специальных кодов коррекции ошибок, а контрольные суммы служат для обеспечения целостности хранимых данных.
Так или иначе, от некоторой избыточности данных избавиться не получится никаким путём, но логика, лежащая в основе алгоритма, позволяет организовывать систему хранения в различных конфигурациях:
- Минимальная избыточность – необходимо как минимум 4 сервера хранения, при этом можно потерять один сервер без потери данных;
- Нормальная избыточность – необходимо как минимум 9 серверов хранения, при этом можно безболезненно потерять 2 сервера хранения;
- Максимальная избыточность – необходимо 13 серверов хранения, при этом можно безболезненно потерять 3 сервера хранения.
Стоит отметить, что накладные расходы дискового пространства в первом варианте составят 50%, во втором 40%, а в третьем 43%. Для сравнения, если вы попытаетесь организовать хранилище на HDFS, то ваши накладные расходы составят 200%, т.к. Hadoop два раза “среплицирует” исходные данные.
Масштабируем систему
Что касается масштабируемости данной системы, то можно с лёгкостью добавлять и убавлять сервера хранения без риска потери данных. Система сама будет балансировать нагрузку. Узел (node) – элемент масштабируемости и повышения надежности Acronis Storage — работает на любом типовом серверном железе под управлением ОС Linux. Компонентами узла могут быть (в любой комбинации):
- Сервис метаданных (MDS) – отслеживает распределение данных по серверам хранения и обеспечивает целостность данных.
- Сервис ввода-вывода (FES) – распределяет данные по серверам хранения и выполняет операции чтения-записи.
- Сервер хранения (STS) – хранит блоки (chunks) данных.
Архитектурные решения
Acronis Storage создавался с прицелом на то, чтобы хранить данные не только эффективно, но и дешево, поэтому данную систему софтверного хранилища можно развернуть на самых простых серверах (не обязательно брендовых), подключив к ним напрямую жёсткие диски. Все эти жесткие диски со всех серверов система объединит в единый пул и предоставит к ним доступ по протоколу NFS либо с помощью FUSE-клиента, обеспечивая при этом высокоскоростной кэш.
Что касается удобства инсталляции системы – то тут тоже никаких проблем нет. Разворачивается Acronis Storage с помощью загрузочного образа ISO, с которого поднимается основной узел, далее по PXE грузятся все остальные узлы системы. После этого вам понадобится несколько минут для конфигурации серверных ролей (MDS/FES/STS) через веб-интерфейс, а также создания и настройки NFS шары. После этого система готова к использованию.
В заключении хочется отметить, что решение Acronis Storage не имеет ограничений на размер хранимых данных и является уникальным предложением на рынке по совокупности характеристик. Оно специально заточено разработчиками для надёжного и гибкого хранения “lazy data” (резервных копий, логов, документов, аудио, видео, медицинских данных) наиболее дешевым и эффективным способом.
Самым ярким доказательством этого служит тот факт, что именно эта технология собственной разработки используется компанией Acronis в своих датацентрах по всему миру для организации облачного хранилища бэкапов пользователей c 2009 года.
Автор: Alexey_Ru
