Терабайты файлов веб-проекта — храним и раздаем

    Всем привет!

    В последнее время наметился интересный тренд — быстрое «распухание» веб-проектов до бесконечности. Объем данных многих популярных сайтов растет все быстрее и быстрее, их нужно куда-то девать, при этом эффективно бэкапить (весело будет, если файлы на 500Т потеряются :-) ), и конечно супербыстро раздавать клиентам, чтобы все их могли качать, качать, качать… на высокой скорости.

    Для системного администратора задача даже редкого, ежедневного резервного копирования такого объема файлов навевает мысли о суициде, а менеджер веб-проекта просыпается в холодном поту от мысли о предстоящей профилактике датацентра на 6 часов (чтобы файлы перевести из одного датацентра в другой нужно пару раз загрузить багажник автомобиля винчестерами :-) ).

    Коллеги с умным видом советуют приобрести одно из решений от NetApp, но, жаль, что бюджет у проекта в 1000 раз меньше, это вообще стартап… что делать будем?

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


    Доступ в гардероб HighLoad


    Если Вы хоть раз посещали конференцию HighLoad, то наверняка знаете, что на входе нужно обязательно ответить на вопрос — почему ставят nginx перед apache? Иначе дальше гардероба не пройти ;-)

    Правильно, nginx или аналогичный обратный прокси позволяет эффективно раздавать файлы, особенно по медленным каналам, серьезно снижая нагрузку на сервер и повышая в целом производительность веб-приложения: nginx раздает кучу файлов, apache или php-fpm обрабатывают запросы к серверу приложений.

    Такие веб-приложения живут хорошо, пока объем файлов не увеличивается до, скажем десятков гигабайт — когда несколько сотен клиентов начинают одновременно скачивать файлы с сервера, а памяти для кэширования файлов в ОЗУ недостаточно — диск, а потом и RAID — просто умрет.

    Сервер статики


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

    Делают что-то типа:
    • www.mysite.ru
    • img.mysite.ru
    • js.mysite.ru
    • css.mysite.ru
    • download.mysite.ru
    • и т.п.


    Чтобы более эффективно раздавать статику с разных доменов, ее выносят на отдельный сервер(а) статики:

    Полезно на этом сервере использовать режим кэширования nginx и «быстрый» RAID (чтобы побольше клиентов требовалось для постановки диска «на колени»).

    CDN — раздача


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


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

    Ваши файлы действительно становятся доступны клиенту на расстоянии вытянутой руки, откуда бы он их не начал качать: с Красной площади или с Сахалина — файлы будут отдаваться с ближайших ему серверов провайдера CDN.

    «Вертикальное» масштабирование раздачи статики


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

    Вы боитесь подумать о следующем:
    • Рассыпятся диски на файловом хранилище (рейд10 может умереть, забрав с собой сразу пару зеркальных дисков и это — случается не очень редко) и придется доставать файлы из бэкапа в течении… двух-трех недель.
    • В датацентре наконец-то научились считать количество дизель-генераторов, однако вас с утра обрадовали сообщением, что диски рассыпались, а ваши бэкапы в результате ошибки софта — безвозвратно повреждены (такое в амазоне с нами один раз произошло).
    • Пройдет рекламная акция и начнется наплыв клиентов из Дальнего Востока или из Европы — и вы не справитесь с эффективной раздачей такого количества статики.


    Да и вообще, вы вложили в инфраструктуру уже столько денег, а риски, причем немалые — остаются. Как-то нечестно получается.

    Кружочки и колесики — распределенная файловая система


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

    Тогда придется все это хозяйство администрировать самостоятельно, что потребует наличие видимо целого отдела эксплуатации :-)

    Виртуальная файловая система


    Одним из наиболее эффективных и, что важно, дешевых решений, является использование возможностей известных облачных провайдеров, дающих в аренду по очень вкусным, особенно при большом объеме данных, ценам, способ хранить неограниченный объем ваших файлов в облаке с очень высокой надежностью (гигантский DropBox). Провайдеры организовали на своих мощностях описанные выше распределенные файловые системы, высоконадежные и размещенные в нескольких датацентрах, разделенных территориально. Более того, эти сервисы, как правило, тесно интегрированы в сеть CDN данного провайдера. Т.е. вы будете не просто удобно и дешево хранить свои файлы, но и их максимально удобно для клиента раздавать.

    Дело за малым — нужно настроить на своем веб-проекте прослойку или виртуальную файловую систему (или аналог облачного диска). Среди бесплатных решений можно выделить FUSE-инструменты (для linux) типа s3fs.

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

    Модуль «Облачные хранилища» платформы «1С-Битрикс»


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

    Мне честно нравится, что можно хранить данные отдельных модулей системы… в разных облачных хранилищах :-). Это реально диверсифицирует ваше файловое хранилище. Можно их раскидать в зависимости от адреса или типа клиента. Либо от типа информации — кто-то эффективно отдает легкую статику, кто-то тяжелый контент.

    Итоги


    Не важно, на чем вы пишите веб-проект — рано или поздно обязательно столкнетесь с леденящей душу проблемой лавинообразного увеличения объема файлов для хранения и раздачи и должны будете принять верное архитектурное решение.

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

    И конечно приглашаю всех на наш облачный сервис «Битрикс24», в котором мы активно используем вышеописанные технологии. Всем удачи!
    1С-Битрикс
    62.93
    Company
    Share post

    Comments 57

      +8
      Правильно ли я понял, что все сводится к тому, чтобы всю статику хранить в CDN и отдавать ее оттуда?
        +10
        Все сводится к 1C-Bitrix :)
          +1
          Спасибо, Кэп!

          То, что пост написан в «Блог компании 1С-Битрикс» на это как бы намекает. ;)
        –2
        Статику храним в облачном хранилище аля распределенная надежная файловая система, а отдаем через CDN.
          +7
          Чем это отличается от того чтобы просто хранить файлы в Amazon S3 и раздавать их через CDN?
            –3
            Ничем. Ну может еще можно хранить разные данные у разных провайдеров. Например грохнется амазон, а файлы у других провайдеров — останутся.
              +5
              Я пытаюсь понять какой в этом смысл? Вы оценивали как-нибудь вероятность потери своих данных из одного из облачных компаний? Windows Azure/Amazon/Google/etc?

              Насколько эта вероятность понижается, если хранить в двух местах?
              Если исходная вероятность 0.1%, а итоговая 0.01% (перемножили вероятности что сгорят все ДЦ и того и того провайдера), то что?
              Если исходная вероятность 0.01%, а итогвая 0.0001, то что?

              Как эта вероятность соотносится с затратами?
                –3
                Возьмем амазон. Я убьюсь но не смогу хранить файлы с такой же надежностью в нескольких ДЦ как они: aws.amazon.com/s3/

                «Reliable: Store data with up to 99.999999999% durability, with 99.99% availability. There can be no single points of failure. All failures must be tolerated or repaired by the system without any downtime.»

                Т.е. я во-первых экономлю на инфораструктуре надежности, т.к. трачу копейки (12 центов за гиг в мес), а храню данные в супернадежной инфраструктуре без бэд-блоков, сгорающих дисков и т.п.
                  +11
                  Все верно. Я лишь не понимаю зачем мне какой-то 1c-что-то-там для того чтобы хранить данные в s3.

                  p.s. 12 центов за гиг в мес — это 6000$ за 50TB/месяц. Я к тому, что в описанной вами ситуации, вы предлагаете хранить примерно те же объемы в нескольких ДЦ. Каждый из которых будет добавлять вам 180 000рублей / месяц к вашим затратам. Или чуть больше 2 млн рублей в год. Теперь вопрос: какой смысл все это дублировать? Какое соотношение риска эти данные потерять и цены за «спокойство»
                    –6
                    " 1c-что-то-там" — вам точно не нужен :-) А вот менеджеру проекта которому нужно быстро стартовать проект с кучей контента и чтобы качали все беспрерывно — возможно не помешает.

                    Не. Не нужно в нескольких ДЦ. Когда я храню данные в S3, амазон сам парится на эту тему и размазывает диски по своим датацентрам, выдерживая отказ сразу двух устройств (т.е. у них видимо в кавычках рейд1 на 3 дисках между датацентрами). Я продолжаю платить свои 12 центов за гигабайт, незаметно для меня размазанный по N датацентрам региона амазона.
                      +10
                      Я именно такой менеджер. И я не понимаю зачем мне какая-то приблуда между моим проектом и S3. А так как я целевая аудитория этого проекта, то я не понимаю какая была логика. Вот и все.

                      >Я продолжаю платить свои 12 центов за гигабайт, незаметно для меня размазанный по N датацентрам региона амазона.
                      Я про дублирование файлов с амазона на какой-нибудь google cloud или обратно.
                        –6
                        Если у вас проект изначально не на битриксе, то приблуда конечно не нужна, можно использовать s3fs свободно и попробовать аналогичные FUSE-инструменты для других хранилищ.

                        Мы в продукте, в веб-кластерной редакции, предлагаем просто из коробки эту приблуду + приблуды для мастер-слейв репликации, синхронизации и т.п. Манагер запускает проект на битриксе и не парится больше о нагрузках и объеме файлов.
                          +1
                          Приблуда может потребоваться в процессе роста проекта, когда потребуется то переносить все в облако, то поменять его на другое. Можно все делать вручную или воспользоваться тем, что уже есть в системе.
                      +2
                      SLA Амазона EC 99.95% — 4.38 часов простоя в год. ~ лежал 58 часов. что уже равно 99.5%

                      Store data with up to 99.999999999%
                      Так вот, потеряют они Ваш файл и предложат компенсацию. Облачный сервис не панацея.

                      Не верьте всему, что на заборе написано.

                        0
                        У нас десятки серверов в амазоне в нескольких регионах и ДЦ, сами нарывались на это падение. Но данные в S3 — не пропадали.
                      +3
                      Корректно мыслите, меня умиляют совещания, на которых люди с серьезной мордой лица мусолят нули после запятых рисков потери не таких уж критичных данных на амазоне, основываясь на 1-2 прецендентах, совершенно не осознавая какое место такие риски занимают в общей структури рисков.
                        +2
                        У нас в стране вообще как-то не принято к проекту прилагать план управления рисками, а стоит.
                          0
                          Ага, заклюют за «бюрократизацию процесса»
                +4
                Статья о бэкапах этого громного вороха файлов или нет? Если о бэкапах — то решение вида «хранить свои файлы у третьих лиц» мало меняет картину…
                  +1
                  Ну так что это за третьи лица…

                  1) У них есть, например в амазоне, возможность версионности файлов. Т.е. если я по дури удалю файлы клиента или он сам клиент это сделает и начнет утром просить поднять — их можно будет достать из истории, как в DropBox.

                  2) Можно через АПИ амазона выполнить рекурсивное копирование объектов из одной части хранилища в другое, и только измененных (из одного бакета в другой). Т.е. бэкапом занимается сам провайдер, а не я.

                  Да вообще, они файлы сами и бэкапят и проверяют диски на чексумы чтобы битые файлы заменять актуальными. Т.е. остается один недостаток — нам нужно бэкапить файлы от удаления приложением или хакером либо в само облако, либо себе, либо… что в Битриксе встроено, можно бэкапиить из одного облака в другое.
                    +1
                    У всех бывают факапы. Кто знает, действительно ли у этих сторонних компаний работа с моими данными организована так, как вы предположили. И как быстро они поднимутся в случае аппаратного сбоя.

                    Держать свои данные неизвестно где, когда между вами сотни километров проводов — ну, я бы не стал спокойно спать. Рекурсивные копирования, перемещения и т.д. — это обычное блабла, которое призвано отвлечь моё внимание от самого важного: бэкапы. Используя описанное выше решение, время на резервное копирование всех данных ну вообще не уменьшается. И в случае беды — всё-равно мы имеем те же устаревшие данные и недели на их перезаливку на сайт.
                      +1
                      Насколько я знаю, амазон вообще не терял данные в s3, во всяком случае в сети не находил. На EBS-дисках, да, факапы регулярные.

                      Я периодически удаляю случайно файлы в друпбоксе, который на самом деле лежит в S3. Благодаря версионности — файлы легко восстановить, вот и инкрементальный бэкап — быстрый и незаметный. А рекурсивное копирование… да, небыстрое, зато мне не нужно кучу дисков и серверов своих этим насиловать — дышать легче.
                        +1
                        Да, меня всю статью не оставляла мысль о том, что как же бэкапить-то!..

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

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

                        Интересно, существуют ли решения с такими свойствами?..
                          +1
                          а, тут выше это обсуждается.

                          Блин, как отучиться думать о технологиях ради технологий, и абстрактных девяток :)

                          Хорошо об этом 37signals писали: не парьтесь по поводу супермега-availability, тока денег вбухаете. Лучше хорошо относитесь к своим клиентам, будьте открыты, не замалчивайте, а признавайтесь в проблемах — и тогда они вас обязательно поймут и не уйдут косяками из-за какого-нибудь даунтайма, который хотя и портит картину девяток.

                            0
                            С такими рассуждениями (если в чистом виде) то можно сразу идти на govnohost.info
                            PS. 37signals уважаю
                              0
                              Я к тому написал статью, чтобы мы по максимуму заюзали новые технологии, сбросив с себя геморой ответственности на плечи облачных провайдеров и креативили сервисы для клиентов :-)
                              0
                              Я бы для начала все бекапил в несколько разделов одного облака. А вот особо важные данные, конечно, бэкапил в другое. Всегда есть данные очень важные и не очень :-)
                          +1
                          Если это секьюрные файлы, их можно перед загрузкой в облако шифровать. А если обычные — так пусть их смотрит персонал амазона, чего бояться.
                            +1
                            Фактически, это аутсорсинг у одной из лучших компаний в отрасли. Можете лучше (надежнее и дешевле)? Это является вашей основной сферой деятельности? Тогда — вперед, вам это не нужно. Но для большинства проектов хостинг, канал и нагрузка — головная боль. И хорошо, что есть такое решение.

                            До появления облаков считалось, что повышение надежности на один знак после запятой увеличивает стоимость на порядок.
                              –1
                              Какая из перечисленный компаний — одна из лучших компаний в отрасли?
                              Какой системный администратор считает, что бэкапы на удалённом хранилище — это надёжно? Мне жалко его проекты. Надеюсь, вы не являетесь одним из них.
                                +1
                                Я имел в виду Амазон, конечно. Да, про трафик — не учел, но если сайт тоже в облаке, то вроде трафик с S3 будет бесплатный — ниже Александр написал

                                Какой системный администратор считает, что бэкапы на удалённом хранилище — это надёжно? Мне жалко его проекты. Надеюсь, вы не являетесь одним из них.

                                Упс… Я- один из них. Я считаю, что хранить бекапы в облаке — надежно. Выше уже поясняли, почему вы, скорее всего, не сможете создать инфраструктуру такой же надежности, как крупные облачные провайдеры — слишком дорого. А если учесть скорость развертывания бекапа (тоже очень немаловажный фактор)…

                                Но! Если у вас бекап небольшого размера, до 1-10 Гб и хороший канал, может вам удобнее будет хранить локально. А вот надежнее ли? И райды разушаются…
                                  +1
                                  Деньги дома хранить надежнее или в банке? Зайдут домой через балкон ребята с утюгом и паяльником и сейф окажется бесполезным :-) Поэтому я считаю что хранить деньги в банке — надежнее. Аналогично с бэкапами — вы часто проверяете жесткие диски на бэды (т.е. считаются ли ваши бэкапы или вы только в это верите)? Амазон например делает проверку считываемости блоков дисков постоянно в фоне и заменяет битые блоки корректными также незаметно.

                                  А если у вас данных — терабайты, Вам будет сложно защитить их от катастрофы в одном ДЦ, а у облачного провайдера данные такого и больших объемов автоматически реплицируются в несколько ДЦ, разделенных территориально.

                                  А человеческий фактор — кто у вас сисадмин? Ему действительно можно доверять?? У облачного провайдера обычно жесткая система информационной безопасности с постоянными аудитами и т.п.

                                  Получается, что вопрос о том, где НАДЕЖНО хранить бэкапы далеко не простой в свете появления облачных провайдеров.
                                    0
                                    Аналогия с деньгами и банком не совсем корректна. В банке вклады — как минимум застрахованы. В Амазон попала молния, ваших данных нет, вам пишут письмо с извинениями и бросают на произвол судьбы. Приехали. Где пруф, что мои данные у них отреплицированы в несколько ДЦ? Что у них есть резервная копия на случай криворукого админа?

                                    Я лишь пытаюсь сказать, что доверять business-critical данные всецело кому-то одному — это гиблое дело. Одна ИХ ошибка и ВАШЕГО бизнеса больше нет. Всегда должна быть ещё одна копия. Желательно как можно ближе к себе.
                                      0
                                      За полтора года амазон периодически при попадании молнии грохал машинки и отключал жесткие диски, убивая рейды10, но данные в бэкапах в s3 — не повреждал. Был один раз инцидент что они повредили сами по глупости софтом несколько бэкапов, но у меня их много, поэтому ничего страшного не произошло.

                                      Ну как вы сделаете копию если данных терабайты? Вы ее будете делать год :-) Тут трейд-офф — изнасиловать возможности облака, 10 раз внутри облака все скопировать-перекопировать-передублицировать в s3, но подстраховаться на случай катастрофы.
                              +2
                              Вы не учли стоимость каналов и трафика…
                              Тот же Амазон хорош, но не всегда выгодный по цене…
                                +1
                                Статью только пролистал. Перечитаю позже. Очень актуальная тема.
                                  –5
                                  В амазоне стоимость трафика между S3 и машиной, с которой я лью в S3 (да, это должна быть машина в том же регионе амазона) — нулевая. Лей сколько хочешь бесплатно в бэкап по локалке размером регион и несколько связанных в нем ДЦ.

                                  По другим не скажу, но они развиваются вроде активно, Microsoft Azure в россии вообще поднимает свой.
                                    –2
                                    Не понимаю почему этот топик минусуется. Это правда — в амазоне локальный трафик ничего не стоит, и от машины в S3 тоже бесплатный. Я думаю они опомнятся и закроют эту лазейку, а пока можно пользоваться :-)
                                  +4
                                  насчет дизельных генераторов тонко однако, аплодирую ;)
                                    0
                                    Спасибо :-)
                                    +2
                                    топику быть в разделе «я пиарю всякую хурму и лью воду»
                                      –1
                                      А на хабре есть такой раздел? ;)
                                  • UFO just landed and posted this here
                                      0
                                      AlexSerbul, всё правильно пишете, только реальность «1С-Битрикс» такова, что из 2-х российских облаков, вы работаете только с Clodo, а более дешёвый Selectel пролетает из-за «деревянности» кода облачного модуля. Да и остальные OpenStack'и тоже под вопросом (сам не тестировал, не берусь утверждать). Тикет в ТП висит несколько месяцев.
                                        0
                                        Спасибо за информацию. Мы с интересом и надеждой смотрим в сторону российских облачных провайдеров и их сервисов и будем стараться их поддерживать.
                                        0
                                        Не уловил, где в статье решение для бакапов от логических (софтовых) ошибок?
                                        Если софт по ошибке удалил несколько терабайт данных — откуда взять их для восстановления?
                                          0
                                          Из бэкапа. Правда если софт очень умный, то он может удалить данные также и из бэкапов :-) Если серьезно, то:

                                          1) Мне представляется интересным решение Амазона по версионности файлов в бакетах S3. Вы удаляете файл, а его содержимое остается в истории. Так реализовано в DropBox, к примеру.
                                          2) Можно делать периодические копии (полные или наиболее ценных данных, если данных очень много) в отдельный раздел облачного хранилища провайдера. В этом случае вряд ли софт окажется насколько умным, чтобы удалить и данные и бэкап.
                                          3) Есть религиозная идея скачивать терабайты данных себе на диски и держать их в сейфе. Очень ценные данные, которых обычно мало, так можно сохранять, но в контексте экспоненциального роста объемов информации в сети, думаю, наиболее приемлемым вариантом окажется периодически копировать данные в другое облако, находящееся поближе.
                                          0
                                          Привет! Мы работаем над аналогичной проблемой. Не могли бы вы сообщить сухо в цифрах:

                                          * на каком количестве файлов и директорий столкнулись с проблемой,
                                          * какой это был объём
                                          * чем отдавали
                                          * как долго переезжали на новую архитектуру и перечень схваченных косяков?
                                          * сколько обходится в целом в месяц ощутимый кусок и названных массивов данных?
                                            0
                                            Скажите, а cloudflare, поставленный перед сайтом, чем хуже указанного модуля? Вопрос вот в чем — для существующего сайта автоматически перебросить нужные картинки на cdn, насколько понимаю, варианта особого нет, или я что-то путаю? А если нет, то cloudflare явно лучше отработает…
                                              0
                                              В ближайшей версии 1С-Битрикс, до релиза которой остались считанные дни, мы начинаем также поддерживать российских провайдеров CDN, с которыми не умеет работать CloudFlare! Т.е. ваш трафик будет отдаваться не с европейских серверов, а с ближайших российских. Также наш модуль смотрит на веб-проект «изнутри», т.к. работает внутри ядра платформы, а не снаружи — что добавляет несколько степеней свободы для эффективного использования облачных сервисов. Но технологически — решения похожи.

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

                                                0
                                                Алексей, спасибо за ответ! А что с автопереносим файлов на облачное хранилище? Спрашиваю, поскольку под рукой сайт на Битриксе (версия поднималась неоднократно, так что «наслоения» могут быть), в uploads которого, на глаз, много больше файлов, чем сайтом используется. Тупо копировать на CDN не хочется, хотелось бы перенести только реально нужное…
                                                  0
                                                  1) Подключаете одно из облачных хранилищ в админке сайта. Например бакет в s3. Можно сделать за 10 минут.
                                                  2) Настраиваете несколько правил в модуле облачных хранилищ и переносите выбранные файлы модулей; процесс идет в фоне. Я недавно перенес на нескольких проектах в облако несколько десятков гигабайт из upload, очень удобно. Если не будет получаться, пишите в личку, поможем.

                                                  В результате папка upload должна стать пустой. Для подстраховки, на критичных проектах, я настраиваю бэкап периодический бакета s3 на одну из машин в амазоне утилитой s3cmd.
                                                    0
                                                    Т.е. автоперенос произойдет? Отлично!

                                                    А ссылки на файлы в html-коде — их-то как проставлять? Если у меня сейчас прописан src="/upload/aa/bb/aabbhshdk.jpg", то кто его без затраты ресурсов при каждой отдаче исправит на src=«myid.cdn.доменпровайдераcdn»?

                                                    Скажите, а сложно ли организовать свое псевдо-облако? Мне было бы интересно сделать поддомен основного сайте (скажем, static.мойдомен.tld), или прикупить доп. домен (static-мойдомен.tld), и закинуть туда статику, а домен уже отдавать либо другим веб-сервером, либо даже тем же, но при этом появится возможность не пересылать куки, параметры авторизации и прочее — а это, на вид, неплохая мысль. Так понимаю, фековый плагин поддержки cdn (по сути, перекладывающий файлы в каталог того, нового домена, мне бы помог, есть ли возможность это сделать так, чтобы автообновление меня потом не «поправило»? Документации на эту тему нет?
                                                      0
                                                      Для апач говорят есть mod_cdn
                                                        0
                                                        Для nginx-а бы еще такой…

                                            Only users with full accounts can post comments. Log in, please.