Ну сколько можно писать статьи о Bash и упорно лепить sh-совместимые команды?!
Bash гораздо функциональнее чем описанные здесь примеры.
Я уже не говорю о том, что вы пишите ужасный код, и некоторые привычки могут рано или поздно вылиться Вам боком, например использование [, вместо [[, или использование `$a', вместо `a' внутри $(( )). Конечно всё это рабочие варианты, если помнить о разных нюансах, но тогда не надо статью озаглавливать как «Bash-скрипты».
Я рассказываю по факту того что имею.
Я не знаю одну ли они физику используют под IPv6 и IPv4 или всё же в каких-то узлах трафик разведён.
Ну и да, малейшие косяки в хождение нашего v6 трафика мне сразу видны, т.к. мы по нему гоняем служебный траф между ДЦ. Перестроение отдельных v4 маршрутов мне менее заметно, да и проблемы с какой-нить одинокой удалённой /22 сеткой мы вообще можем не заметить.
Да ладно!
Печально всё со стабильностью IPv6 даже у Tier-I операторов и peer'инговых сетей. То связность рвётся, то потери дикие. Я уж не говорю про то, что поддержкой и восстановлением работоспособности IPv6 сетей занимаются значительно более лениво.
Думается мне что эта ошибка родилась намеренно и превратилась в бессознательное употребление. Оно явно же пошло от «login name», которое со временем сократили до «login», особенно при транслитерации на русский.
Странное желание скрыть номер телефона в IM, который по сути использует номер телефон как основу для составления списка контактов. Более того он делает это и на основе адресной книги телефона (хотя это отключаемо).
В общем, мне не понятна Ваша паранойя. В чём тайна Вашего номера мобильного телефона? Боитесь — держите три симки под разные нужды (звонки+sms / банки и прочее / IM, соцсети и т.п.).
Под подомную идею использовали OpenVPN туннели без шифрования (не помню уже почему GRE не прижился, кажется с MTU были проблемы) и внутри туннеля гулял OSPF для отказоустойчивости (конечные узлы имели ECMP маршруты до удалённых сетей).
Вообще мы пришли к мысли, что везде где можно обойтись динамической маршрутизацией, лучше обойтись ею вместо VRRP/Pacemacker/uCARP и прочих keepalived.
Это как это сделать что бы 2 сервера отвечали один адресом и только по очереди? С другой стороны должен быть виден только один ресурс в один момент времени, а не получать там ECMP.
Или Вы предлагает ради такой задачи нагородить там BGP с priority?
Явно попахивает извращением, но могу предположить, что такой схемой можно добиться HA какого-либо ресурса удалённого офиса с двумя независимыми туннелями к каждому из инстансов.
упс, это ответ на комент выше про память.
Есть рекомендации считать что чисто на DDT уйдёт 20Гб памяти на хранилище в 1PB, я склонен рассчитывать на 40Гб, но всё зависит от того на сколько хорошо у Вас работает дедупликация. Не в плане абстрактного качества её работы, а в плане повторяемости записываемых данных.
Так же можно использовать L2ARC на SSD.
Потому что основной ЦПУ в этот момент занят другими делами и нечего его загружать расчётом графики, НО я Вам ещё раз втолковываю и не только уже я — в СХД ЦПУ делать нечего кроме как расчёта контрольных сумм, дедупликации (если она есть) и обработки SCSI команд. Итого, если с него снять ещё и дедупликацию, то он просто будет простаивать!
А ещё можно RAID поставить аппаратный со своим контроллером для подсчёта сумм, тогда вообще можно СХД на пеньке 4-ом замутить…
Переходим по указанной мною ссылке и, опачки, что мы видим...
ZFS deduplication works at the block level, not on an individual file basis, so it is possible that «mostly the same» files can enjoy benefits of deduplication and reduced disk space consumption. Imagine even a single user working with a series of medical image files from CAT scans, or different versions of an animated film. The different files might be almost identical in contents, and potentially the majority of disk blocks could be the same — and stored only once instead of storing the same contents multiple times.
Фраза «Этого пока ни кто не умеет делать» очень опрометчива. Маркетологи вы наши…
Далее. Узкоспециализированные действительно лучше заточены на конкретные задачи, ради которых их создавали, НО когда в это тычат пальцем, забывают уточнить что обещанная производительность появилась в том числе за счёт освобождения ресурсов ЦПУ, НО если ЦПУ и так справлялся со всеми описанными задачами, то на кой хрен тратится на доп. железо?
Представьте: идет боевой ввод-вывод, а 3PAR в онлайне дедуплицирует эту информацию! Этого пока никто не умеет делать, только 3PAR.
Шёл 2009 год.... И не надо оправдываться, что в HP это сделано «аппаратно», а в ZFS программно. Современных ЦПУ вполне хватает что бы выполнять всю работу возложенную на хранилище. Если пичкать туда аппаратные чипы ускорители, то ЦПУ там просто простаивает.
Bash гораздо функциональнее чем описанные здесь примеры.
Я уже не говорю о том, что вы пишите ужасный код, и некоторые привычки могут рано или поздно вылиться Вам боком, например использование [, вместо [[, или использование `$a', вместо `a' внутри $(( )). Конечно всё это рабочие варианты, если помнить о разных нюансах, но тогда не надо статью озаглавливать как «Bash-скрипты».
Не место форточкам на web-сервере.
Я не знаю одну ли они физику используют под IPv6 и IPv4 или всё же в каких-то узлах трафик разведён.
Ну и да, малейшие косяки в хождение нашего v6 трафика мне сразу видны, т.к. мы по нему гоняем служебный траф между ДЦ. Перестроение отдельных v4 маршрутов мне менее заметно, да и проблемы с какой-нить одинокой удалённой /22 сеткой мы вообще можем не заметить.
Печально всё со стабильностью IPv6 даже у Tier-I операторов и peer'инговых сетей. То связность рвётся, то потери дикие. Я уж не говорю про то, что поддержкой и восстановлением работоспособности IPv6 сетей занимаются значительно более лениво.
В общем, мне не понятна Ваша паранойя. В чём тайна Вашего номера мобильного телефона? Боитесь — держите три симки под разные нужды (звонки+sms / банки и прочее / IM, соцсети и т.п.).
Google тут вообще не при делах, ни в общем случае, ни как пример для статьи. Особенно для заголовка.
Вообще мы пришли к мысли, что везде где можно обойтись динамической маршрутизацией, лучше обойтись ею вместо VRRP/Pacemacker/uCARP и прочих keepalived.
Или Вы предлагает ради такой задачи нагородить там BGP с priority?
Есть рекомендации считать что чисто на DDT уйдёт 20Гб памяти на хранилище в 1PB, я склонен рассчитывать на 40Гб, но всё зависит от того на сколько хорошо у Вас работает дедупликация. Не в плане абстрактного качества её работы, а в плане повторяемости записываемых данных.
Так же можно использовать L2ARC на SSD.
А ещё можно RAID поставить аппаратный со своим контроллером для подсчёта сумм, тогда вообще можно СХД на пеньке 4-ом замутить…
Далее. Узкоспециализированные действительно лучше заточены на конкретные задачи, ради которых их создавали, НО когда в это тычат пальцем, забывают уточнить что обещанная производительность появилась в том числе за счёт освобождения ресурсов ЦПУ, НО если ЦПУ и так справлялся со всеми описанными задачами, то на кой хрен тратится на доп. железо?