Об авторе. Арчи Рассел (Archie Russell) — инженер бэкенда во Flickr

Одна из самых затратных статей в работе сервиса вроде Flickr — это хранение. За последние годы мы описывали различные техники для снижения стоимости: использование COS, динамическое изменение размера на GPU и перцептивное сжатие. Эти проекты были очень успешны, но мы продолжали терять много денег на хранении данных.

В начале 2016 года мы поставили перед собой задачу выйти на новый уровень — продержаться целый год вообще не закупая новые носители информации. Используя различные техники, нам это удалось.

История затрат

Небольшие арифметические расчёты на салфетке показывают, что затраты на хранение представляют собой предмет реального беспокойства. В день с высокой посещаемостью пользователи Flickr загружают до 25 млн фотографий. Каждая из них требует в среднем 3,25 МБ, что в сумме составляет 80 ТБ. Наивно размещая их на облачном хостинге вроде S3 фотографии одного дня потянут на $30 тыс. в год и продолжат генерировать затраты каждый последующий год.

В предыдущих постах мы делились инструкциями по настройке резервного копирования и репликации на базе Veeam. Сегодня мы хотим рассказать про резервное копирование средствами Commvault. Инструкций не будет, зато расскажем, что и как уже бэкапят наши клиенты.


СХД системы резервного копирования на базе Commvault в дата-центре OST-2.

Пришло время рассмотреть все мифы и узнать где правда в вопросах дедупликации для массивов данных.



Несмотря на то, что технология дедупликации известна уже достаточно давно, но только сейчас технологии, применяемые в современных массивах данных, позволили ей пережить второе рождение. Во всех современных массивах данных на текущий момент используется дедупликация, но наличие этой функции в массиве еще не значит, что это даст весомые преимущества именно под ваши данные.
К сожалению, большое количество администраторов принимают «на веру» и считают, что дедупликация обладает безграничными возможностями.

/ фото grover_net CC

В одном их наших предыдущих материалов мы писали о новой разработке в сфере хранения данных. Нас, как IaaS-провайдера, очень интересуют технологии, способные изменить наше представление о дата-центрах. Потому мы решили уделить еще немного времени хранилищам данных. Очень емким хранилищам данных.

На днях озадачился резервным копированием данных в облако. Нашёл подходящий сервис попробовал, и понял, что существует необходимость в сжатии бэкапа перед отправкой (думаю нет необходимости объяснять зачем). Не стал заморачиваться в поиске готовых решений и решил сам написать скромный скриптик для этой цели. Исходные файл или папка жмутся в .tar.xz с уровнем сжатия 9, что позволяет сохранить права и выдаёт хорошую компрессию на выходе (у меня снэпшот системы сжимается 4 раза). Результатом остался доволен, думаю для малого бизнеса, да и для личных целей многим пригодиться.

Возможности скрипта:

• гибкая настройка
• проверка на доступность ресурсов (источник, директория назначения, рабочая директория)
• проверка на файл блокировки (предотвращает выполнение если источник еще создаётся)
• вывод информации о сжатии (размер источника, размер архива, соотношение этих размеров)
• логирование и дебагинг (вывод дополнительной информации о процессе выполнения)
• возможность менять вывод (как в консоль и лог-файл, так и только в лог-файл)
• сохраняет и ротирует предыдущие архивы
• возможность форматирования текста вывода
• отправка e-mail-а в случае успешного и/или неуспешного завершения

Я не хочу разжигать очередную священную войну, но комментарии на мой последний пост о «сжатии» в RAR навеяли на некоторое количество мыслей и рассуждений, которые я хочу донести до сообщества. Но перед этим хочу отметить, что я работаю под Windows'ем, поэтому всё ниже изложенное будет касаться именно его. Плюс к прочему попрошу отнестись к топику, как к информации к размышлению, а не как к красной тряпке для быка. Итак, давайте поговорим о форматах сжатия данных с пользовательской точки зрения.

Я давно заметил (впрочем, вон там есть и свежий пример того), что некоторые видеоподкастеры предпочитают не заливать своё видео на некоторые популярные видеохостинги (такие, как YouTube или Google Video), заранее зная, что эти видеохостинги если и принимают видеозаписи любого формата, то у себя преобразуют их (со значительным сжатием) в формат FLV, после чего мелкие детали подкаста расплываются во Flash-видеопроигрывателе.

Напомню поэтому, что сайт RuTube отличается от вышеупомянутых видеохостингов в лучшую сторону тем, что на него также можно закачивать (для последующего воспроизведения) и заранее подготовленные видеоролики в формате FLV, которые тогда на этом сайте никак не подвергаются дальнейшему преобразованию и сжатию.

При помощи программы Any Video Converter Free Version (или других аналогичных простых бесплатных средств) можно заранее изготовить FLV-видеоролик необходимой длины и качества, чтобы затем закачать его на RuTube.