Comments 57
Правильно ли я понял, что все сводится к тому, чтобы всю статику хранить в CDN и отдавать ее оттуда?
Статику храним в облачном хранилище аля распределенная надежная файловая система, а отдаем через CDN.
Чем это отличается от того чтобы просто хранить файлы в Amazon S3 и раздавать их через CDN?
Ничем. Ну может еще можно хранить разные данные у разных провайдеров. Например грохнется амазон, а файлы у других провайдеров — останутся.
Я пытаюсь понять какой в этом смысл? Вы оценивали как-нибудь вероятность потери своих данных из одного из облачных компаний? Windows Azure/Amazon/Google/etc?
Насколько эта вероятность понижается, если хранить в двух местах?
Если исходная вероятность 0.1%, а итоговая 0.01% (перемножили вероятности что сгорят все ДЦ и того и того провайдера), то что?
Если исходная вероятность 0.01%, а итогвая 0.0001, то что?
Как эта вероятность соотносится с затратами?
Насколько эта вероятность понижается, если хранить в двух местах?
Если исходная вероятность 0.1%, а итоговая 0.01% (перемножили вероятности что сгорят все ДЦ и того и того провайдера), то что?
Если исходная вероятность 0.01%, а итогвая 0.0001, то что?
Как эта вероятность соотносится с затратами?
Возьмем амазон. Я убьюсь но не смогу хранить файлы с такой же надежностью в нескольких ДЦ как они: 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 центов за гиг в мес), а храню данные в супернадежной инфраструктуре без бэд-блоков, сгорающих дисков и т.п.
«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 центов за гиг в мес), а храню данные в супернадежной инфраструктуре без бэд-блоков, сгорающих дисков и т.п.
Все верно. Я лишь не понимаю зачем мне какой-то 1c-что-то-там для того чтобы хранить данные в s3.
p.s. 12 центов за гиг в мес — это 6000$ за 50TB/месяц. Я к тому, что в описанной вами ситуации, вы предлагаете хранить примерно те же объемы в нескольких ДЦ. Каждый из которых будет добавлять вам 180 000рублей / месяц к вашим затратам. Или чуть больше 2 млн рублей в год. Теперь вопрос: какой смысл все это дублировать? Какое соотношение риска эти данные потерять и цены за «спокойство»
p.s. 12 центов за гиг в мес — это 6000$ за 50TB/месяц. Я к тому, что в описанной вами ситуации, вы предлагаете хранить примерно те же объемы в нескольких ДЦ. Каждый из которых будет добавлять вам 180 000рублей / месяц к вашим затратам. Или чуть больше 2 млн рублей в год. Теперь вопрос: какой смысл все это дублировать? Какое соотношение риска эти данные потерять и цены за «спокойство»
" 1c-что-то-там" — вам точно не нужен :-) А вот менеджеру проекта которому нужно быстро стартовать проект с кучей контента и чтобы качали все беспрерывно — возможно не помешает.
Не. Не нужно в нескольких ДЦ. Когда я храню данные в S3, амазон сам парится на эту тему и размазывает диски по своим датацентрам, выдерживая отказ сразу двух устройств (т.е. у них видимо в кавычках рейд1 на 3 дисках между датацентрами). Я продолжаю платить свои 12 центов за гигабайт, незаметно для меня размазанный по N датацентрам региона амазона.
Не. Не нужно в нескольких ДЦ. Когда я храню данные в S3, амазон сам парится на эту тему и размазывает диски по своим датацентрам, выдерживая отказ сразу двух устройств (т.е. у них видимо в кавычках рейд1 на 3 дисках между датацентрами). Я продолжаю платить свои 12 центов за гигабайт, незаметно для меня размазанный по N датацентрам региона амазона.
Я именно такой менеджер. И я не понимаю зачем мне какая-то приблуда между моим проектом и S3. А так как я целевая аудитория этого проекта, то я не понимаю какая была логика. Вот и все.
>Я продолжаю платить свои 12 центов за гигабайт, незаметно для меня размазанный по N датацентрам региона амазона.
Я про дублирование файлов с амазона на какой-нибудь google cloud или обратно.
>Я продолжаю платить свои 12 центов за гигабайт, незаметно для меня размазанный по N датацентрам региона амазона.
Я про дублирование файлов с амазона на какой-нибудь google cloud или обратно.
Если у вас проект изначально не на битриксе, то приблуда конечно не нужна, можно использовать s3fs свободно и попробовать аналогичные FUSE-инструменты для других хранилищ.
Мы в продукте, в веб-кластерной редакции, предлагаем просто из коробки эту приблуду + приблуды для мастер-слейв репликации, синхронизации и т.п. Манагер запускает проект на битриксе и не парится больше о нагрузках и объеме файлов.
Мы в продукте, в веб-кластерной редакции, предлагаем просто из коробки эту приблуду + приблуды для мастер-слейв репликации, синхронизации и т.п. Манагер запускает проект на битриксе и не парится больше о нагрузках и объеме файлов.
Приблуда может потребоваться в процессе роста проекта, когда потребуется то переносить все в облако, то поменять его на другое. Можно все делать вручную или воспользоваться тем, что уже есть в системе.
SLA Амазона EC 99.95% — 4.38 часов простоя в год. ~ лежал 58 часов. что уже равно 99.5%
Store data with up to 99.999999999%
Так вот, потеряют они Ваш файл и предложат компенсацию. Облачный сервис не панацея.
Не верьте всему, что на заборе написано.
Store data with up to 99.999999999%
Так вот, потеряют они Ваш файл и предложат компенсацию. Облачный сервис не панацея.
Не верьте всему, что на заборе написано.
Корректно мыслите, меня умиляют совещания, на которых люди с серьезной мордой лица мусолят нули после запятых рисков потери не таких уж критичных данных на амазоне, основываясь на 1-2 прецендентах, совершенно не осознавая какое место такие риски занимают в общей структури рисков.
Статья о бэкапах этого громного вороха файлов или нет? Если о бэкапах — то решение вида «хранить свои файлы у третьих лиц» мало меняет картину…
Ну так что это за третьи лица…
1) У них есть, например в амазоне, возможность версионности файлов. Т.е. если я по дури удалю файлы клиента или он сам клиент это сделает и начнет утром просить поднять — их можно будет достать из истории, как в DropBox.
2) Можно через АПИ амазона выполнить рекурсивное копирование объектов из одной части хранилища в другое, и только измененных (из одного бакета в другой). Т.е. бэкапом занимается сам провайдер, а не я.
Да вообще, они файлы сами и бэкапят и проверяют диски на чексумы чтобы битые файлы заменять актуальными. Т.е. остается один недостаток — нам нужно бэкапить файлы от удаления приложением или хакером либо в само облако, либо себе, либо… что в Битриксе встроено, можно бэкапиить из одного облака в другое.
1) У них есть, например в амазоне, возможность версионности файлов. Т.е. если я по дури удалю файлы клиента или он сам клиент это сделает и начнет утром просить поднять — их можно будет достать из истории, как в DropBox.
2) Можно через АПИ амазона выполнить рекурсивное копирование объектов из одной части хранилища в другое, и только измененных (из одного бакета в другой). Т.е. бэкапом занимается сам провайдер, а не я.
Да вообще, они файлы сами и бэкапят и проверяют диски на чексумы чтобы битые файлы заменять актуальными. Т.е. остается один недостаток — нам нужно бэкапить файлы от удаления приложением или хакером либо в само облако, либо себе, либо… что в Битриксе встроено, можно бэкапиить из одного облака в другое.
У всех бывают факапы. Кто знает, действительно ли у этих сторонних компаний работа с моими данными организована так, как вы предположили. И как быстро они поднимутся в случае аппаратного сбоя.
Держать свои данные неизвестно где, когда между вами сотни километров проводов — ну, я бы не стал спокойно спать. Рекурсивные копирования, перемещения и т.д. — это обычное блабла, которое призвано отвлечь моё внимание от самого важного: бэкапы. Используя описанное выше решение, время на резервное копирование всех данных ну вообще не уменьшается. И в случае беды — всё-равно мы имеем те же устаревшие данные и недели на их перезаливку на сайт.
Держать свои данные неизвестно где, когда между вами сотни километров проводов — ну, я бы не стал спокойно спать. Рекурсивные копирования, перемещения и т.д. — это обычное блабла, которое призвано отвлечь моё внимание от самого важного: бэкапы. Используя описанное выше решение, время на резервное копирование всех данных ну вообще не уменьшается. И в случае беды — всё-равно мы имеем те же устаревшие данные и недели на их перезаливку на сайт.
Насколько я знаю, амазон вообще не терял данные в s3, во всяком случае в сети не находил. На EBS-дисках, да, факапы регулярные.
Я периодически удаляю случайно файлы в друпбоксе, который на самом деле лежит в S3. Благодаря версионности — файлы легко восстановить, вот и инкрементальный бэкап — быстрый и незаметный. А рекурсивное копирование… да, небыстрое, зато мне не нужно кучу дисков и серверов своих этим насиловать — дышать легче.
Я периодически удаляю случайно файлы в друпбоксе, который на самом деле лежит в S3. Благодаря версионности — файлы легко восстановить, вот и инкрементальный бэкап — быстрый и незаметный. А рекурсивное копирование… да, небыстрое, зато мне не нужно кучу дисков и серверов своих этим насиловать — дышать легче.
Да, меня всю статью не оставляла мысль о том, что как же бэкапить-то!..
После всей статьи и этого вашего комментария захотелось хранить данные кроме основного еще в запасном облаке (от другого провайдера), да так, чтобы основной сервис можно было переключить на запасное облако без долгой «заливки» в основное.
В целом подумалось что бэкап должен быть активным, а не лежать мертвым грузом, требующим перезаливки. Или же допускать быструю активизацию (пусть и по более высокой цене) на время «настоящей» перезаливки.
Интересно, существуют ли решения с такими свойствами?..
После всей статьи и этого вашего комментария захотелось хранить данные кроме основного еще в запасном облаке (от другого провайдера), да так, чтобы основной сервис можно было переключить на запасное облако без долгой «заливки» в основное.
В целом подумалось что бэкап должен быть активным, а не лежать мертвым грузом, требующим перезаливки. Или же допускать быструю активизацию (пусть и по более высокой цене) на время «настоящей» перезаливки.
Интересно, существуют ли решения с такими свойствами?..
а, тут выше это обсуждается.
Блин, как отучиться думать о технологиях ради технологий, и абстрактных девяток :)
Хорошо об этом 37signals писали: не парьтесь по поводу супермега-availability, тока денег вбухаете. Лучше хорошо относитесь к своим клиентам, будьте открыты, не замалчивайте, а признавайтесь в проблемах — и тогда они вас обязательно поймут и не уйдут косяками из-за какого-нибудь даунтайма, который хотя и портит картину девяток.
Блин, как отучиться думать о технологиях ради технологий, и абстрактных девяток :)
Хорошо об этом 37signals писали: не парьтесь по поводу супермега-availability, тока денег вбухаете. Лучше хорошо относитесь к своим клиентам, будьте открыты, не замалчивайте, а признавайтесь в проблемах — и тогда они вас обязательно поймут и не уйдут косяками из-за какого-нибудь даунтайма, который хотя и портит картину девяток.
С такими рассуждениями (если в чистом виде) то можно сразу идти на govnohost.info
PS. 37signals уважаю
PS. 37signals уважаю
Я к тому написал статью, чтобы мы по максимуму заюзали новые технологии, сбросив с себя геморой ответственности на плечи облачных провайдеров и креативили сервисы для клиентов :-)
Я бы для начала все бекапил в несколько разделов одного облака. А вот особо важные данные, конечно, бэкапил в другое. Всегда есть данные очень важные и не очень :-)
Если это секьюрные файлы, их можно перед загрузкой в облако шифровать. А если обычные — так пусть их смотрит персонал амазона, чего бояться.
Фактически, это аутсорсинг у одной из лучших компаний в отрасли. Можете лучше (надежнее и дешевле)? Это является вашей основной сферой деятельности? Тогда — вперед, вам это не нужно. Но для большинства проектов хостинг, канал и нагрузка — головная боль. И хорошо, что есть такое решение.
До появления облаков считалось, что повышение надежности на один знак после запятой увеличивает стоимость на порядок.
До появления облаков считалось, что повышение надежности на один знак после запятой увеличивает стоимость на порядок.
Какая из перечисленный компаний — одна из лучших компаний в отрасли?
Какой системный администратор считает, что бэкапы на удалённом хранилище — это надёжно? Мне жалко его проекты. Надеюсь, вы не являетесь одним из них.
Какой системный администратор считает, что бэкапы на удалённом хранилище — это надёжно? Мне жалко его проекты. Надеюсь, вы не являетесь одним из них.
Я имел в виду Амазон, конечно. Да, про трафик — не учел, но если сайт тоже в облаке, то вроде трафик с S3 будет бесплатный — ниже Александр написал
Упс… Я- один из них. Я считаю, что хранить бекапы в облаке — надежно. Выше уже поясняли, почему вы, скорее всего, не сможете создать инфраструктуру такой же надежности, как крупные облачные провайдеры — слишком дорого. А если учесть скорость развертывания бекапа (тоже очень немаловажный фактор)…
Но! Если у вас бекап небольшого размера, до 1-10 Гб и хороший канал, может вам удобнее будет хранить локально. А вот надежнее ли? И райды разушаются…
Какой системный администратор считает, что бэкапы на удалённом хранилище — это надёжно? Мне жалко его проекты. Надеюсь, вы не являетесь одним из них. Упс… Я- один из них. Я считаю, что хранить бекапы в облаке — надежно. Выше уже поясняли, почему вы, скорее всего, не сможете создать инфраструктуру такой же надежности, как крупные облачные провайдеры — слишком дорого. А если учесть скорость развертывания бекапа (тоже очень немаловажный фактор)…
Но! Если у вас бекап небольшого размера, до 1-10 Гб и хороший канал, может вам удобнее будет хранить локально. А вот надежнее ли? И райды разушаются…
Деньги дома хранить надежнее или в банке? Зайдут домой через балкон ребята с утюгом и паяльником и сейф окажется бесполезным :-) Поэтому я считаю что хранить деньги в банке — надежнее. Аналогично с бэкапами — вы часто проверяете жесткие диски на бэды (т.е. считаются ли ваши бэкапы или вы только в это верите)? Амазон например делает проверку считываемости блоков дисков постоянно в фоне и заменяет битые блоки корректными также незаметно.
А если у вас данных — терабайты, Вам будет сложно защитить их от катастрофы в одном ДЦ, а у облачного провайдера данные такого и больших объемов автоматически реплицируются в несколько ДЦ, разделенных территориально.
А человеческий фактор — кто у вас сисадмин? Ему действительно можно доверять?? У облачного провайдера обычно жесткая система информационной безопасности с постоянными аудитами и т.п.
Получается, что вопрос о том, где НАДЕЖНО хранить бэкапы далеко не простой в свете появления облачных провайдеров.
А если у вас данных — терабайты, Вам будет сложно защитить их от катастрофы в одном ДЦ, а у облачного провайдера данные такого и больших объемов автоматически реплицируются в несколько ДЦ, разделенных территориально.
А человеческий фактор — кто у вас сисадмин? Ему действительно можно доверять?? У облачного провайдера обычно жесткая система информационной безопасности с постоянными аудитами и т.п.
Получается, что вопрос о том, где НАДЕЖНО хранить бэкапы далеко не простой в свете появления облачных провайдеров.
Аналогия с деньгами и банком не совсем корректна. В банке вклады — как минимум застрахованы. В Амазон попала молния, ваших данных нет, вам пишут письмо с извинениями и бросают на произвол судьбы. Приехали. Где пруф, что мои данные у них отреплицированы в несколько ДЦ? Что у них есть резервная копия на случай криворукого админа?
Я лишь пытаюсь сказать, что доверять business-critical данные всецело кому-то одному — это гиблое дело. Одна ИХ ошибка и ВАШЕГО бизнеса больше нет. Всегда должна быть ещё одна копия. Желательно как можно ближе к себе.
Я лишь пытаюсь сказать, что доверять business-critical данные всецело кому-то одному — это гиблое дело. Одна ИХ ошибка и ВАШЕГО бизнеса больше нет. Всегда должна быть ещё одна копия. Желательно как можно ближе к себе.
За полтора года амазон периодически при попадании молнии грохал машинки и отключал жесткие диски, убивая рейды10, но данные в бэкапах в s3 — не повреждал. Был один раз инцидент что они повредили сами по глупости софтом несколько бэкапов, но у меня их много, поэтому ничего страшного не произошло.
Ну как вы сделаете копию если данных терабайты? Вы ее будете делать год :-) Тут трейд-офф — изнасиловать возможности облака, 10 раз внутри облака все скопировать-перекопировать-передублицировать в s3, но подстраховаться на случай катастрофы.
Ну как вы сделаете копию если данных терабайты? Вы ее будете делать год :-) Тут трейд-офф — изнасиловать возможности облака, 10 раз внутри облака все скопировать-перекопировать-передублицировать в s3, но подстраховаться на случай катастрофы.
Вы не учли стоимость каналов и трафика…
Тот же Амазон хорош, но не всегда выгодный по цене…
Тот же Амазон хорош, но не всегда выгодный по цене…
Статью только пролистал. Перечитаю позже. Очень актуальная тема.
В амазоне стоимость трафика между S3 и машиной, с которой я лью в S3 (да, это должна быть машина в том же регионе амазона) — нулевая. Лей сколько хочешь бесплатно в бэкап по локалке размером регион и несколько связанных в нем ДЦ.
По другим не скажу, но они развиваются вроде активно, Microsoft Azure в россии вообще поднимает свой.
По другим не скажу, но они развиваются вроде активно, Microsoft Azure в россии вообще поднимает свой.
насчет дизельных генераторов тонко однако, аплодирую ;)
топику быть в разделе «я пиарю всякую хурму и лью воду»
UFO just landed and posted this here
AlexSerbul, всё правильно пишете, только реальность «1С-Битрикс» такова, что из 2-х российских облаков, вы работаете только с Clodo, а более дешёвый Selectel пролетает из-за «деревянности» кода облачного модуля. Да и остальные OpenStack'и тоже под вопросом (сам не тестировал, не берусь утверждать). Тикет в ТП висит несколько месяцев.
Не уловил, где в статье решение для бакапов от логических (софтовых) ошибок?
Если софт по ошибке удалил несколько терабайт данных — откуда взять их для восстановления?
Если софт по ошибке удалил несколько терабайт данных — откуда взять их для восстановления?
Из бэкапа. Правда если софт очень умный, то он может удалить данные также и из бэкапов :-) Если серьезно, то:
1) Мне представляется интересным решение Амазона по версионности файлов в бакетах S3. Вы удаляете файл, а его содержимое остается в истории. Так реализовано в DropBox, к примеру.
2) Можно делать периодические копии (полные или наиболее ценных данных, если данных очень много) в отдельный раздел облачного хранилища провайдера. В этом случае вряд ли софт окажется насколько умным, чтобы удалить и данные и бэкап.
3) Есть религиозная идея скачивать терабайты данных себе на диски и держать их в сейфе. Очень ценные данные, которых обычно мало, так можно сохранять, но в контексте экспоненциального роста объемов информации в сети, думаю, наиболее приемлемым вариантом окажется периодически копировать данные в другое облако, находящееся поближе.
1) Мне представляется интересным решение Амазона по версионности файлов в бакетах S3. Вы удаляете файл, а его содержимое остается в истории. Так реализовано в DropBox, к примеру.
2) Можно делать периодические копии (полные или наиболее ценных данных, если данных очень много) в отдельный раздел облачного хранилища провайдера. В этом случае вряд ли софт окажется насколько умным, чтобы удалить и данные и бэкап.
3) Есть религиозная идея скачивать терабайты данных себе на диски и держать их в сейфе. Очень ценные данные, которых обычно мало, так можно сохранять, но в контексте экспоненциального роста объемов информации в сети, думаю, наиболее приемлемым вариантом окажется периодически копировать данные в другое облако, находящееся поближе.
Привет! Мы работаем над аналогичной проблемой. Не могли бы вы сообщить сухо в цифрах:
* на каком количестве файлов и директорий столкнулись с проблемой,
* какой это был объём
* чем отдавали
* как долго переезжали на новую архитектуру и перечень схваченных косяков?
* сколько обходится в целом в месяц ощутимый кусок и названных массивов данных?
* на каком количестве файлов и директорий столкнулись с проблемой,
* какой это был объём
* чем отдавали
* как долго переезжали на новую архитектуру и перечень схваченных косяков?
* сколько обходится в целом в месяц ощутимый кусок и названных массивов данных?
Скажите, а cloudflare, поставленный перед сайтом, чем хуже указанного модуля? Вопрос вот в чем — для существующего сайта автоматически перебросить нужные картинки на cdn, насколько понимаю, варианта особого нет, или я что-то путаю? А если нет, то cloudflare явно лучше отработает…
В ближайшей версии 1С-Битрикс, до релиза которой остались считанные дни, мы начинаем также поддерживать российских провайдеров CDN, с которыми не умеет работать CloudFlare! Т.е. ваш трафик будет отдаваться не с европейских серверов, а с ближайших российских. Также наш модуль смотрит на веб-проект «изнутри», т.к. работает внутри ядра платформы, а не снаружи — что добавляет несколько степеней свободы для эффективного использования облачных сервисов. Но технологически — решения похожи.
Насколько хорошо CloudFlare интегрирован с облачными хранилищами, какие их типы их поддерживает? Важно, чтобы CDN был тесно интегрирован с «облачным» диском, откуда он берет файлы для раздачи, а не просто осуществлял обратное проксирование от CDN до источника файлов.
Насколько хорошо CloudFlare интегрирован с облачными хранилищами, какие их типы их поддерживает? Важно, чтобы CDN был тесно интегрирован с «облачным» диском, откуда он берет файлы для раздачи, а не просто осуществлял обратное проксирование от CDN до источника файлов.
Алексей, спасибо за ответ! А что с автопереносим файлов на облачное хранилище? Спрашиваю, поскольку под рукой сайт на Битриксе (версия поднималась неоднократно, так что «наслоения» могут быть), в uploads которого, на глаз, много больше файлов, чем сайтом используется. Тупо копировать на CDN не хочется, хотелось бы перенести только реально нужное…
1) Подключаете одно из облачных хранилищ в админке сайта. Например бакет в s3. Можно сделать за 10 минут.
2) Настраиваете несколько правил в модуле облачных хранилищ и переносите выбранные файлы модулей; процесс идет в фоне. Я недавно перенес на нескольких проектах в облако несколько десятков гигабайт из upload, очень удобно. Если не будет получаться, пишите в личку, поможем.
В результате папка upload должна стать пустой. Для подстраховки, на критичных проектах, я настраиваю бэкап периодический бакета s3 на одну из машин в амазоне утилитой s3cmd.
2) Настраиваете несколько правил в модуле облачных хранилищ и переносите выбранные файлы модулей; процесс идет в фоне. Я недавно перенес на нескольких проектах в облако несколько десятков гигабайт из upload, очень удобно. Если не будет получаться, пишите в личку, поможем.
В результате папка upload должна стать пустой. Для подстраховки, на критичных проектах, я настраиваю бэкап периодический бакета s3 на одну из машин в амазоне утилитой s3cmd.
Т.е. автоперенос произойдет? Отлично!
А ссылки на файлы в html-коде — их-то как проставлять? Если у меня сейчас прописан src="/upload/aa/bb/aabbhshdk.jpg", то кто его без затраты ресурсов при каждой отдаче исправит на src=«myid.cdn.доменпровайдераcdn»?
Скажите, а сложно ли организовать свое псевдо-облако? Мне было бы интересно сделать поддомен основного сайте (скажем, static.мойдомен.tld), или прикупить доп. домен (static-мойдомен.tld), и закинуть туда статику, а домен уже отдавать либо другим веб-сервером, либо даже тем же, но при этом появится возможность не пересылать куки, параметры авторизации и прочее — а это, на вид, неплохая мысль. Так понимаю, фековый плагин поддержки cdn (по сути, перекладывающий файлы в каталог того, нового домена, мне бы помог, есть ли возможность это сделать так, чтобы автообновление меня потом не «поправило»? Документации на эту тему нет?
А ссылки на файлы в html-коде — их-то как проставлять? Если у меня сейчас прописан src="/upload/aa/bb/aabbhshdk.jpg", то кто его без затраты ресурсов при каждой отдаче исправит на src=«myid.cdn.доменпровайдераcdn»?
Скажите, а сложно ли организовать свое псевдо-облако? Мне было бы интересно сделать поддомен основного сайте (скажем, static.мойдомен.tld), или прикупить доп. домен (static-мойдомен.tld), и закинуть туда статику, а домен уже отдавать либо другим веб-сервером, либо даже тем же, но при этом появится возможность не пересылать куки, параметры авторизации и прочее — а это, на вид, неплохая мысль. Так понимаю, фековый плагин поддержки cdn (по сути, перекладывающий файлы в каталог того, нового домена, мне бы помог, есть ли возможность это сделать так, чтобы автообновление меня потом не «поправило»? Документации на эту тему нет?
Sign up to leave a comment.
Терабайты файлов веб-проекта — храним и раздаем