Как сохранить олимпиаду?

Все средства массовой информации нынче живут и дышат только олимпиадой. Дабы не нарушать этот тренд и не упускать возможность “поспекулировать" на этом событии, позволю себе немного порассуждать на тему взаимного проникновения технологий в спорт и спорта в технологии. По некоторым данным олимпиада в Сочи стала большим событием не только для спортсменов и болельщиков, но и для российского IT сообщества, т.к. явила собой пример использования последних веяний IT индустрии для спортивных мероприятий. В качестве платформы для быстрого разворачивания вычислительных мощностей организаторами была выбрана облачная среда Microsoft Windows Azure, работающая поверх гипервизоров Hyper-V, расположенных в дата центрах Microsoft, автоматизацию бухгалтерского учета, логистики и бюджетирования делали с помощью Microsoft Dynamics AX. Были подняты распределенные системы видео и аудио стриминга, множество веб-порталов, баз данных и других приложений, обеспечивающих проведение этого события планетарного масштаба. Помимо облачных мощностей специально для олимпиады была также создана и локальная сеть ЦОДов. Вся эта инфраструктура генерирует огромное количество данных – только представьте, сколько различных типов статистики, документов, отчетов, медицинских данных, видео и аудио контента генерируется за короткий отрезок времени проведения игр! Это петабайты информации. А теперь представьте, что весь этот контент должен быть доступен 24х7 в течение игр и в виде архивов/резервных копий ещё очень длительное время – ведь эта информация в дальнейшем используется для различного рода аналитике, а вся финансовая и логистическая отчётность должна храниться годами в соответствии с законодательством. Да, я намекаю на то, что все эти данные надо как-то длительно и эффективно хранить, а ещё неплохо бы это делать дёшево!

Но как только погаснет Олимпийский огонь, эти данные уже будут фиксированными – так что дорогие решения, ориентированные на модификацию и скорость доступа уже не будут подходить.
Система хранения такой «lazy data» должна отвечать трем требованиям:

1. Доступность данных — данные должны быть доступны в любой момент времени для аналитики или восстановления (в случае резервной копии)
2. Масштабируемость хранилища – должна быть возможность как легко увеличить, так и уменьшить объем хранилища любым инкрементом (диск, сервер)
3. Стоимость хранения – хочется хранить данные на недорогих, легко заменяемых носителях
К этим трём основным вопросам глобальной проблемы хранения “Big Data” я бы прибавил ещё один немаловажный аспект – удобство развертывания, мониторинга и контроля над хранилищем данных. Далее я попытаюсь кратко прокомментировать, как именно решает вышеупомянутые задачи Acronis Storage:

1. Для того, чтобы гарантировать надёжность хранения данных, Акронис использует технологию собственной разработки, которая обеспечивает избыточность с помощью применения специальных кодов коррекции ошибок, а контрольные суммы служат для обеспечения целостности хранимых данных.
Логика, лежащая в основе алгоритма, позволяет организовывать систему хранения в следующих минимальных конфигурациях:
• Минимальная избыточность – необходимо как минимум 4 сервера хранения, при этом можно потерять один сервер без потери данных;
• Нормальная избыточность – необходимо как минимум 9 серверов хранения, при этом можно безболезненно потерять 2 сервера хранения;
• Максимальная избыточность – необходимо 13 серверов хранения, при этом можно безболезненно потерять 3 сервера хранения.
Стоит отметить, что накладные расходы дискового пространства в первом варианте составят 50%, во втором 40%, а в третьем 43%. Для сравнения, если вы попытаетесь организовать хранилище на HDFS, то ваши накладные расходы составят 200%, т.к. Hadoop два раза “среплицирует” исходные данные.

2. Что касается масштабируемости данной системы, то можно с лёгкостью добавлять и убавлять сервера хранения без риска потери данных. Система сама будет балансировать нагрузку. Узел (node) – элемент масштабируемости и повышения надежности Acronis Storage — работает на любом типовом серверном железе под управлением ОС Linux.Компонентами узла могут быть (в любой комбинации):
• Сервис метаданных (MDS) – отслеживает распределение данных по серверам хранения и обеспечивает целостность данных.
• Сервис ввода-вывода (FES) – распределяет данные по серверам хранения и выполняет операции чтения-записи.
• Сервер хранения (STS) – хранит блоки (chunks) данных.

Архитектура

3. Решение Acronis Storage нацелено на то, чтобы хранить данные не только эффективно, но и дешево, поэтому данную систему софтверного хранилища можно развернуть на самых простых серверах (не обязательно брендовых), подключив к ним напрямую жёсткие диски. Все эти жесткие диски со всех серверов система объединит в единый пул и предоставит к ним доступ по протоколу NFS либо с помощью FUSE-клиента, обеспечивая при этом высокоскоростной кэш.
Что касается удобства инсталляции системы – деплоится она с помощью загрузочного образа ISO, с которого загружается основной узел, далее по PXE грузятся все остальные узлы системы. После этого вам понадобится несколько минут для конфигурации серверных ролей (MDS/FES/STS) через веб интерфейс, а также создания и настройки NFS шары. После этого система готова к использованию.
Скриншоты ниже иллюстрируют мониторинг и управление данным решением с помощью современной и удобной веб консоли.

В заключении хочется отметить, что решение Acronis Storage не имеет ограничений на размер хранимых данных и является уникальным предложением на рынке по совокупности характеристик. Оно специально заточено разработчиками для надёжного и гибкого хранения “lazy data” (резервных копий, логов, документов, аудио, видео, медицинских данных) наиболее дешевым и эффективным способом. Самым ярким доказательством этого служит тот факт, что именно эта технология собственной разработки используется компанией Акронис в своих датацентрах по всему миру для организации облачного хранилища бэкапов пользователей c 2009 года.