дешевый с точки зрения BGP)

с точки зрения админов

отчасти - да, отчасти - нет

мало кто лезет в BGP настолько явно

для гугла - может что и крутят, явно

дря прочих - маловероятно, это плохая идея.

+ C Anycast'ом теряется практически любая возможность трафиком управлять

зависит от размера твоего аникаста.

зависит от размера твоего аникаста.

enlarge your anycast. FREE.

увы, это очень дорого :)

дря прочих - маловероятно, это плохая идея.

да ладно, все туда лезут.

не, не зависит - обычно чем больше anycast сеть, тем меньше каждая точка присутствия

каждая новая точка присутсвтия стоит денег :)

и как минимум несколько юнитов на колокацию

от компании зависит =)

если у тебя много трафика - то железо в попах нечего не стоит =)))

стоит только канал

ессно от компании зависит :)

но операторов эникаста, их мало

хз, мне кажется каждый первый пионер с более чем одним ДЦ уже давно как минимум подумал на эту тему, ели не потрогал руками

с более чем одним дц оно не имеет смысла как такового

ну разве что redundancy

наибольшая проблема с anycast сетью это то что когда у тебя одна из точек присутствия начинает перегреваться, то очень сложно с этим что-то сделать

и тебе нужно лишь иметь минимальное необходимое число точек

либо вообще забыть об этой затее

а число точек - зависит от твоего трафика и его гео првиязки

точки, где тебе надо иметь эникаст легко прогнозируются относительно простой математической моделью

НО если трафик глобален не стоит удтвляться если получится что-то в районе нескольких десятков "для старта".

о коль о трафике заговорили, а кто знает российский днс хостинг умеющий достаточно точное гео ?

Эникаст, как и всякий хайлоад, должен быть оправдан, когда по-другому нельзя) например когда есть CDN. или когда тебе нужна 100% отказоустойчивость

что-то аналогичное трафик директору от dyn.com

я не слышал о таких, признаться

о коль о трафике заговорили, а кто знает российский днс хостинг умеющий достаточно точное гео ?

мы делаем клиентам по запросу

DNS и российский - оч странная фраза

используется геоип или любой сервис по желанию

если DNS российский, то гугл будет очень не рад получить NXDOMAIN :)

DNS и российский - оч странная фраза

нормально так вбросил =)

Ngenix поидее должен такое уметь

DNS и российский - оч странная фраза

ты хостинг выкинул (

сложного там ничего, берем поверднс и вперед. Хоть стандартный бекенд, хоть кастомный

хахаха :)

(ну, там есть нюансы, решаются или опытом или деньгами)

простите, не удержался.

удачи!

особенно с гео локаций мобильного интернета

который со всей страны терминируетяс в паре-тройке городов)

ну я хочу завести запись в сервисе и недумать о проблемах

ТЫЩИ ГИГАБИТ ЕГО со всей страны с одного /24 )))

а что за задача, если не секрет?

ибо решение геоайпи - это плохое решение

крымских юзеров чз проксю отправить в гуглоклауд

имхо, тогда можно и свой личный днс завести

и просто забить префиксы Крыма

это обычный split horizon DNS

я так понимаю человек хочет заплатить и [забыть]

просто обслуживать это некому будет

ну крым - это такой сложный вопрос)

для себя я бы сделал так да )

а тут надо сделать клиенту и потом отдать ему

тогда сложно

я думаю кто-то есть, кто такое сможет просто сделать на базе своего днс

Amazon Route 53?

https://aws.amazon.com/route53/faqs/?sc_channel=PS&sc_campaign=acquisition_UK&sc_publisher=google&sc_medium=route_53_b&sc_content=sitelink&sc_detail=amazon%20route%2053&sc_category=route_53&sc_segment=route_53_faqs&sc_matchtype=e&sc_country=UK&s_kwcid=AL!4422!3!159757508541!e!!g!!amazon%20route%2053&ef_id=U@90agAABHuXj1fo:20170311120244:s

амазон также трафик с крыма к себе блочит если я правильно помню

мы можем один раз сделать и дальше оно будет работать. за деньги

ну, увы

нужна будет пара мелких вдс для .

ну или так ^^ да

#borg Кстати ещё о borg. Если вы повелись на @schors , @demeliorator и @knutov . 1. borg mount ... очень медленный, предпочтительно использовать borg extract 2. Дедупликация не "бесплатная". Если хотите крутую дедупликацию - сливайте как можно больше в одну репу - будет больше данных для анализа. Чем больше сливаете в одну репу, тем больше кэш чанков и файлов, который на каждую заливку архива borg синхронизирует и тем больше время поиска в этом индексе. На больших объёмах это заметно. Где-то на 0.5Tb время заливки повторных бэкапов 300-ми архивами каждый в свою репу и 300-ми архивами в одну репу различается в 10 раз. Это конечно происходит в основном из-за цифры "300", потому что кэш все время ребилдится и получается нету "коротких" по времени бэкапов. А если не "300", то вы остаетесь на несколько часов без возможности обратиться к бэкапу, что не всегда приемлемо. 3. В любом случае borg делает по скорости rsync хоть с —link-dest, хоть без, хоть со сжатием, хоть без 4. Сжатие даже lz жрёт CPU. Это может быть узким местом 5. borg create --list ... высирает листинг в STDERR (OMG!!!) 6. Надо учесть, что borg _ВСЕГДА_ досылает файл(ы) с самым поздним mtime. Это не влияет на дедупликацию, но вдлияет на то, что он будет его перечитывать. Это сделано для того, чтобы избежать ситуации, когда вы восстанавливали из бэкапа что-то, а в это время уже ожидал процесс следующего бэкапа - и между ними что-то успело бы изменить файл, пометив его тем же mtime, что и восстановление. Без описанного поведения borg, возможны ситуации, когда у вас будет "битый" файл в бэкапе и всебудут думать, что ок. Хотя, надо заметить, ситуация немного вырожденная P.S. Это не минусы. Это просто сразу грабли

согласен

#borg 1 - это мы сейчас решаем и, возможно, решим 2 - но есть нюанс - с дефолтными параметрами чанков, которые задаются один раз при создании репы, получается лимит на 8 гигабайт метадаты. При превышении - вроде бы тыква. 3 - если бекапить с SSD на рейд зеркало на обычных дисках по гигабитному линку поверх sshfs с rc4, то tar | pigz c 12 потоками ровно в два раза быстрее, чем borg create —compression lz4 (это при создании первого снапшота, при повторных снапшотах 50 гигабайт с миллионом файлов снапшотится за 3 минуты) 4 - lz4 жрет менее всех проц. Из-за размера чанка параллелить сжатие - нельзя. В версии 1.2 сделают параллельную обработку файлов и будет счастье (в 1.2 вообще много вкусняшек планируется) 6 - помоему в реальной жизни от этого проблемы нет и вообще оно никак не заметно. Хинт если правильно помню из доков - сделать тач какого-нибудь файла перед созданием снапшота.

#borg Еще немного про пути 1. В borg нет rsync style ситаксиса exclude. Но есть аж четыре других варианта. Они описаны в доке в разделе Using->Misc. Наиболее похожий на rsync - "sh:блаблабла". exclude не позиционный, потому что отсутствует include 2. В borg все пути прямо как в файловой системе. Но при create он уже в архиве режет первый слеш, если он есть. Т.е. при exctract надо учитывать, что ведущего слеша нет и убирать его из exclude, если они заданы полными путями 3. В дополнение к (2) - он как путь указали "что", так он его в архив и положит, а не как rsync только последнюю часть. 4. extract всегда в ${PWD}. Но при extract можно отрезать часть пути из архива по количеству слешей 5. borg не умеет делать как rsync --delete при extract - это вы уже сами 6. ВАЖНО, забыл. borg надо задавать переменную окружения LANG. Иначе он вам фарш в файлах с неASCII именами устроит. Или вообще с ошибкой вывалится. До версии 1.1.x borg не умеет вываливать список файлов с \0 на конце и все нестандартные имена идут фаршем

#borg 1 - это мы сейчас решаем и, возможно, решим 2 - но есть нюанс - с дефолтными параметрами чанков, которые задаются один раз при создании репы, получается лимит на 8 гигабайт метадаты. При превышении - вроде бы тыква. 3 - если бекапить с SSD на рейд зеркало на обычных дисках по гигабитному линку поверх sshfs с rc4, то tar | pigz c 12 потоками ровно в два раза быстрее, чем borg create —compression lz4 (это при создании первого снапшота, при повторных снапшотах 50 гигабайт с миллионом файлов снапшотится за 3 минуты) 4 - lz4 жрет менее всех проц. Из-за размера чанка параллелить сжатие - нельзя. В версии 1.2 сделают параллельную обработку файлов и будет счастье (в 1.2 вообще много вкусняшек планируется) 6 - помоему в реальной жизни от этого проблемы нет и вообще оно никак не заметно. Хинт если правильно помню из доков - сделать тач какого-нибудь файла перед созданием снапшота.

(6) в реальной жизни я полтора часа убил пытаясь понять, почему у меня тестовый сет файлов всегда бэкапится :)

дак ведь не весь сет, а только файл с максимальным мтайм должен бекапиться

(6) в реальной жизни я полтора часа убил пытаясь понять, почему у меня тестовый сет файлов всегда бэкапится :)

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

или у тебя у всех был одинаковый мтайм?

Ну это был touch 1.txt 2.txt 3.txt ;)))

На самом деле это был пустой аккаунт хостинга. Но там шаблонные файлы одим моментом создаются :)))

массовый приход хостеров %)

Ну дык Фил канал прорекламил ненавязчиво)