О том, как это работает, и как могут разработчики использовать модуль поддержки облачных хранилищ, отлично
В этой статье я хочу рассказать об облачных хранилищах немного с другой стороны - более подробно описать, что это вообще такое; какие бывают хранилища, что в них общего и чем они отличаются; и - самое главное - какую практическую пользу может принести их использование для владельцев сайтов.
Эта же статья
В этом посте мы расскажем, что же это такое, какие бывают хранилища, как они работают, и как их можно с большой пользой применять на своем сайте.
К чему стремится его владелец? За исключением узкоспециализированных ресурсов — к росту сайта, расширению его аудитории, увеличению той прибыли (денежной — в явном виде, или же «прибыли вниманием»), которую приносит проект. Хорошая и понятная цель для любого интернет-магазина, информационного ресурса, социальной сети и т.п.
Такая цель сама собой подразумевает несколько более мелких задач, которые нужно научится наиболее эффективно решать:
- Минимизация расходов на эксплуатацию и снижение финансовых рисков на старте проекта
- Масштабирование при росте нагрузки и обратное масштабирование
- Надежность – обеспечение SLA, при чем, возможно, разный уровень SLA для разных категорий клиентов
- Быстрая отдача динамического и статического контента
Решение, как нам кажется, получается не очень гибким.
Гораздо удобнее, а главное — эффективнее (на наш взгляд) — научиться работать в облачной инфраструктуре, использовать ее сервисы, масштабироваться и быть готовыми к разработке не просто сайта, а настоящего облачного сервиса. (О преимуществах «облака» по сравнению с традиционным хостингом
Именно поэтому в 11-ой версии «1С-Битрикс: Управление сайтом» появился
Что же это такое — облачное хранилище?
Если попробовать описать буквально в двух словах: для пользователя — это большой-большой сервер для хранения статического контента, который можно очень быстро раздавать по HTTP. Изнутри (с точки зрения провайдера) — все «немножко» сложнее: все данные в хранилище реплицируются в несколько точек, что обеспечивает его надежность; есть API для работы с файлами в хранилище и т.д. (О некоторых особенностях напишем далее более подробно.)
Идея модуля работы с облачными хранилищами в нашем продукте очень проста — любые файлы, с которыми может работать пользователь системы, могут абсолютно прозрачно для него сохраняться не на локальном сервере веб-сайта, а в облачном хранилище.
Какие задачи мы решаем переносом файлов в «облако»?
1. Снижаем стоимость эксплуатации
В общем случае стоимость размещения файлов в облаке будет ниже, чем использование аналогичного по объему файлового сервера. Если будете проводить самостоятельные расчеты, не забудьте посчитать стоимость сервера («голый» диск использовать не получится ), организацию бэкапов, траффик и т.п.
2. Можем использовать совместно с CDN для ускорения отдачи контента
Почти все провайдеры облачных хранилищ предлагают клиентам CDN (Content Delivery Network или Content Distribution Network — географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию контента конечным пользователям в сети Интернет,
3. Снижаем нагрузку на web-узлы
Ваши серверы приложений могут заниматься только выполнением скриптов и отдачей динамического контента пользователям. Процессы веб-сервера не заняты отдачей статики (особенно актуально для видео и дистрибутивов). Плюс снижается нагрузка на диск.
4. Используя централизованное хранилище, решаем задачу синхронизации контента между множественными web-узлами
Если вы используете балансировщик нагрузки и несколько веб-серверов, вам нужно решить задачу синхронизации контента между ними. Варианты — либо периодически запускать синхронизацию на локальных хранилищах (rsync, csync2), что достаточно проблематично при работе с большими объемами данных; либо использовать то или иное централизованное хранилище. Например, облачное.
5. Ускоряем рендеринг страниц в браузере
Если все картинки сайта отдаются с основного домена (например,
Поэтому, даже если скорость вашего интернет-канала позволяет получать контент с сайта очень быстро, вы будете ограничены количеством соединений. Визуально страница в браузере будет отрисовываться не слишком быстро.
Если картинки вынесены на отдельный домен относительно самого сайта — это ускоряет загрузку всего необходимого контента.
Провайдеры облачных хранилищ
Мы поддерживаем облачные хранилища Amazon S3, Google Storage, Windows Azure Storage от Microsoft, RackSpace, OpenStack.
Почти все они предлагают примерно похожий функционал (с точки зрения пользователя):
- Любое количество объектов (чаще всего — до нескольких Тб каждый)
- Возможность размещения в разных датацентрах (регионах)
- Группировка объектов
- Механизмы авторизации и ACL
- REST и SOAP интерфейсы для работы с объектами
- Прямая отдача файлов по HTTP
- Высокая доступность
- Низкая цена
- Доступ через внешние инструменты (FUSE, клиенты)
Сервис, реализованный в рамках целого комплекса облачных услуг от компании Амазон — Amazon Web Services (AWS).
Можно использовать совместно с другим сервисом Amazon —
Файлы из S3 можно раздавать не только по HTTP, но и по протоколу BitTorrent.
Интересная особенность — можно использовать специальный тип хранилища — Reduced Redundancy Storage (RRS). В этом случае гарантируется меньшая надежность сохранности данных (по сравнению со стандартным хранилищем), однако при этом пользователям предлагается меньшая цена хранения данных. Можно использовать для возобновляемого контента.
Цены (для стандартного хранилища; варьируются в зависимости от региона):
- Хранилище — 1 Гб (до 1 Тб) $0.14/мес.
- $0.01 за 1000 запросов PUT, COPY, POST или LIST
- $0.01 за 10000 запросов GET
- Траффик – 1 Гб (до 10 Тб) $0.12 (первый 1 Гб – бесплатно)
Хранилище, реализованное компанией Google, в основном, для хранения данных при работе с Google App Engine (однако, конечно же, может использоваться и в других приложениях).
Отдача контента может осуществляться через CDN Google.
До конца 2011 года есть возможность воспользоваться бесплатным триальным предложением (размер хранилища — до 5 Гб, есть лимиты на траффик и количество запросов). Хорошее предложение для желающих просто попробовать и оценить сервис.
Цены (варьируются в зависимости от региона):
- Хранилище — 1 Гб (до 1 Тб) $0.13/мес.
- $0.01 за 1000 запросов PUT, COPY, POST или LIST
- $0.01 за 10000 запросов GET
- Траффик – 1 Гб (до 1 Тб) $0.12
Хранилище, созданное компаний Microsoft в рамках развития облачной платформы Windows Azure.
Есть собственный CDN. Интересны дополнительные сервисы (например, Table Service, Queue Service).
Пользователи могут воспользоваться
Цены (варьируются в зависимости от региона):
- Хранилище — 1 Гб $0.15/мес.
- $0.01 за 10000 запросов
- Траффик – 1 Гб $0.15
Rackspace — один из крупнейших мировых облачных провайдеров. Который среди прочих своих услуг предлагает своим клиентам и облачное хранилище.
Файлы могут раздаваться через CDN, который организован в партнерстве с
Цены:
- Хранилище — 1 Гб $0.15/мес.
- Запросы по файлам меньше 250 Кб, а также HEAD, GET, DELETE — бесплатно
- Траффик – 1 Гб $0.18
Уже упомянутый ранее Rackspace совместно с NASA разрабатывали облачную платформу Nebula.
В середине 2010 года было принято решение об открытии этой платформы и создании на ее базе нового проекта — OpenStack.
В настоящее время OpenStack — этой целый комплекс программного обеспечения, которое любой желающий может использовать для создания собственного облака. Одна из составных частей OpenStack — OpenStack Swift — комплекс для организации файлового хранилища.
Проект поддерживается очень многими компаниями (Citrix, Dell, AMD, Intel и т.д.)
Универсальная поддержка OpenStack Swift API на уровне платформы «1С-Битрикс» дает возможность любому хостеру реализовать собственное файловое хранилище на базе OpenStack — и им сразу же сможет воспользоваться любой владелец сайта, созданного на Битриксе (без дополнительных затрат на интеграцию и изучение нового специфичного API).
Первыми (и, насколько мы знаем, пока единственными) в России собственное облачное файловое хранилище на базе OpenStack
Некоторые технические особенности реализации хранилища
В итоге у Clodo можно купить хостинг (виртуальную машину) под «1С-Битрикс», сразу же с ним — лицензию на продукт, и затем подключить к проекту облачное хранилище.
Мы призываем российских хостинг-провайдеров развивать собственные облачные решения!
Мы надеемся, что появление таких решений даст толчок к развитию облачной инфраструктуры и CDN-сетей в России.
Как это все работает в платформе «1С-Битрикс»?
К любому сайту, работающему на «1С-Битрикс», можно подключить одно или несколько хранилищ. Делается это в административном интерфейсе — делается это просто, достаточно указать несколько параметров:
В простейшем варианте можно просто перенести все файлы проекта в облака, выбрав нужный пункт в контекстном меню:
В дальнейшем все новые файлы (фотографии в фото-галерее, картинки к описаниям товаров в интернет-магазине, аватарки пользователей в соц. сети и т.п.) будут автоматически загружаться в облако, а ссылки на них будут автоматически формироваться правильным образом.
Если же хочется большей гибкости в управлении файлами, можно воспользоваться системой «правил-фильтров», реализованных в платформе.
Правила настраиваются:
- по модулям системы
- по расширениям файлов
- по размерам файлов
Например, можно подключить два разных хранилища и для каждого из них настроить свои правила-фильтры. Допустим, все файлы более 100 Мб перемещать в облако Google Storage, а все видео — в Amazon S3. В зависимости от выгодности предложений провайдеров можно менять свои правила, «переливая» данные в другие «облачные» папки. Или совсем отключать хранилища, которые стали дорогими или чем-либо неудобными.
Немножко «внутренностей» для разработчиков
Самое главное — мы считаем возможность «прозрачной» работы с «облаком» очень важной для клиентов. Именно поэтому модуль поддержки облачных хранилищ включен во все редакции продукта, начиная со «Старта».
На первый взгляд реализация поддержки «облаков» в платформе может показаться достаточно простой. Однако нашим разработчикам пришлось доработать около 30 модулей в системе! Все они так или иначе работают с файлами. И для пользователя, который решит «переехать в облако», все должно быть прозрачно.
Таким же прозрачным остался API для разработчиков по работе с файлами (подробно можно прочитать в
А это значит, что любой разработчик, работая с API платформы, можно полностью использовать весь функционал облачных хранилищ.
* * *
Платформа «1С-Битрикс» стала еще более гибкой как для конечных пользователей, так и для разработчиков. Появились новые инструменты для масштабирования сайтов и эффективного решения других задач.
Мы стремимся сделать «1С-Битрикс» платформой не только для создания сайтов, но и для разработки облачных веб-сервисов, крупных масштабируемых веб-проектов, размещаемых в «облаке».
А раз уж
Пока же всех провайдеров можно по пальцам одной руки пересчитать.
Если серьезно - переедем в ближайшее время. У нас статики очень много. Нужно спокойно распланировать процесс переезда.
Раз мы и так размещаемся в Амазоне, вполне логично будет перенести все в S3.
А соответствующий пост в блогах или на Хабре планируется?
Подскажите пожалуйста, каким образом можно перенести весь сайт с выделенного сервера в S3? Буду благодарен за ссылки на статьи и руководства.
Нужно взять виртуальную машину Amazon EC2, настроить ее, например, взяв наше веб-окружение. Затем - штатным средствами сделать полную резервную копию и перенести ее на новую машину.
Исходя из интереса к облачным технологиям, как с вашей стороны, так и со стороны пользователей, думаю что было бы очень полезным, написание статьи на тему подробной установки сайта на БУС в облаке.
А сейчас для одной местной ТВ-компании нужен видео-архив. И лучшего решения просто не придумать
Так что о Вебинаре не жалею, и теперь постараюсь не один не пропускать
Было бы не плохо если бы появился Сертификат по "облачным решениям".
Учитывая стоимость хостинг с большим объемом, облачные решения взгляд вперед...
После вашего ответа на форуме. Вопросов больше не имею
Возникнут какие-либо более конкретные вопросы - пожалуйста, обращайтесь.
По моему разумению в бекап должно уйти все то что находится на хостинге. кроме облачной папки /upload
И еще вопрос можно ли настроить складывание бекапов в облако.
Хранение бэкапов в облаке - пока такого нет, но есть у нас в планах.
Например, в определенной папке.
Это возможно?
Хотели использовать облако именно для больших иллюстраций, получается, что такой возможность нет
Вторая задача, которую хотели решить (и тоже никак) - вынос статических элементов шаблона, js и css. Картинки только можно из шаблона - но это мы и раньше могли
Список модулей - iblock, список размеров - по вкусу.
2. Элементы шаблона (css, js) пока в облако не вынести. Обязательно подумаем на эту тему.
2. Думаю, для посещаемых проектов это будет востребованной функцией
Пока такого нет. Планируем сделать.
Ждем
Например, записать решение проблемы, когда облачное хранилище подключается не к новому проекту, а к уже существующему. Соответственно, все картинки давно проиндексированы и перелинкованы, и нужно сохранить урлы вида "http://сайт.ru/upload/и-так-далее/моя-картинка.jpg"
Не напомните?
Спасибо!
Например, images.site.ru.
Все URL'ы, которые были созданы в самом продукте, при переезде в "облако" автоматически переименуются в новые.
Если же где-то в явном виде были указанны ссылки на картинки, например, в тексте в записе в блоге, можно настроить переадресацию site.ru/upload/ -> images.site.ru/upload/ средствами веб-сервера (например, mod_rewrite в Apache).
Не могу разобраться.
Какую необходимо сделать запись в DNS через CNAME для Google Cloud Storage
У себя прописал такую строчку
И получается такое
The requested URL /iblock/000/243_preview.jpg was not found on this server.
1. Имя контейнера, которое задается при подключении хранилища в админке, должно совпадать с тем доменом, который будет указан в DNS. То есть, контейнер должен называться "images.site.com".
2. Для этого домена в DNS надо прописать CNAME на адрес c.commondatastorage.googleapis.com.
P.S. В таком варианте не работает HTTPS.
Как быть?
Подозреваю что ограничение на то что нельзя в имени контейнера указать знак "." в битриксе установлено ошибочно, потому как в документации гугл сказано, что этот знак можно использовать, но только следует тогда пройти процедуру верификации домена.
Убираем ограничение на использование "." в названии (будет в ближайшем обновлении модуля).
Длина компонента идентификатора контейнера (подстрока между точками) должна быть не менее 3-х символов и не более 64-х.
Чучуть не дочитал.
2. В облако не грузятся файлы, прикрепленные к задачам, файлы называемые "Документы", файлы в "Файловом хранилище". Это 99% файлов загружаемых в портал ресурсов... В облако грузятся ТОЛЬКО фото профиля, фотографии из фотогалереи.
Планируется ли доработка модуля "Облачные хранилища" для портала? Ведь в таком виде для портала мало пользы от модуля..
Все должно работать корректно.
Напишите, пожалуйста, в тех. поддержку.
Кратко ситуация:
- Используется медиатека
- Создан контейнер, который перехватывает файлы медиатеки (модуль fileman, определенные типы файлов).
- Контейнеру присвоен канонический адрес (
clodo.ru, контйнер public ) - Заведен инфоблок со свойством типа Видео.
- В это свойство выбираются видео файлы из медиатеки (помним, они в облаке).
- Реальный путь к файлу при таком способе работы - это полный URL (c доменом). Он хранится в базе данных в свойстве типа Видео (в поле path).
Т.е. имеем файлы (таблица b_files, CFile из API), которые хранятся в облаке и полные URL на эти файлы, также сохраненные в БД.Задача - сменить облачный хостинг не убив сайт.
Если место на диске WEB-хостинга есть, то проблема решается элементарно:
- Выгрузка файлов из облака на сайт.
- Настройка нового контейнера с тем же каноническим адресом и теми же правилами.
- Загрузка файлов с сайта в облако уже в новый контейнер.
А что делать если места на WEB-хостинге нет?Хакерское решение не убивающее хотя бы инфоблок есть. Перенос файлов между контейнерами с правильными настройками канонического адреса сохранят рабочими URL, хранящиеся в свойстве типа Видео. А вот медиатеку придется править SQL запросами к БД - нужно менять поле HANDLER_ID вручную. И ведь нет уверенности что это все.
Правильное решение - это хотя бы коленочный скрипт, написанный на API Битрикс. Такой есть?
То, что я описал - это ситуация, которая неизбежно наступит в будущем, а я к ней не готов. Напрягает. Все описанное, кроме самой необходимости переезда там - реально есть.
WEB-хостинг на одном из сайтов я менял за все время его существования (8 лет) 4 раза. Как часто придется менять облака я не могу сказать. Возможно, реже. Но и проблема острее, когда возникнет.
Сейчас я присматриваюсь к облачным хранилищам, готовлю планы для разных ситуаций, отрабатываю технологию. Похоже, полной технологии нет и на деле придется обращаться в поддержку.