А по-моему, молодец человек. Наверняка не все «секреты цеха раскрыл». А по результатам: кто-то сможет грамотнее свои ресурсы прикрыть и возможно узнать что-то новое, а кто-то примет это как инструкцию к действию и… будет соврешенно безобиден, потому как кому надо уже всё у себя прикрыл. То есть как и любая публикация уязвимости порождает сначала набеги «script kiddies», но в конечном итоге повышает уровень безопасности, так и тут, мне видится, количество спама должно хоть и немного, но уменьшиться.
Прошу прощения, если я ошибаюсь. Во время прочтения несколько раз появлялось ощущение, что это машинный перевод, или русский — не родной язык автора. Если перевод — было бы интересно узнать кто автор.
ИМХО очень субьективно. Мне, например, было интересно. Сам пару лет назад натыкался на странное поведение деструктора в PHP, но забил и решил задачу иначе, не было времени копать. Теперь стало понятнее.
У нас в LV один раз была ситуация, когда один админ (хороший кстати админ, но все иногда ошибаются) анонсировал по BGP на точку куда подключены все местные провайдеры сеть 0.0.0.0/0 и все сетки которые знает его роутер, при чём с AS-path = его AS. В результате вся страна попыталась рутить весь трафик через их 2MBit линк. После этого случая местные провайдеры стали очень аккуратно настраивать peerinq, с жёсткими acl-ами, ибо пол дня вся страна была без инета.
Чёй-то я не понял, а почему надпись с номером телефона плавает влево-вправо. Она ж вроде на стенку наклеена, а камера жёстко фиксирована. Чую какое-то… не честно. Надеюсь я ошибаюсь?
Я вспомнил, но пока вспоминал название, пока искал линк на описание, пока проверял, что напишу не боян — вы меня опередили. От себя замечу, если в простых конфигурациях что-то и отправит на свалку STP, то ИМХО как раз решения типа EAPS, ибо почти то же самое, в плане стабильности, делают на порядок проще и быстрее.
Если у кого после апгрейда начисто пропоало воспроизведение аудио — у меня это вылечилось посредством apt-get remove pulseaudio и перезагрузкой, после чего всё само пошло через уже имеющийся в системе alsa (дефаултная инсталляция 11.04, специально не устанавливал). Правда у меня KUbuntu, может там какие отличия.
ИМХО, часто людям не хватает именно веры. В первую очередь в то, что проблема решаема. Получая веру в то что некие внешние силы могут её решить они снимают внутренний блок на решение проблемы, после чего успешно решают её сами, приписывая успех внешним силам, тем самым закрепляя схему. Ну да и пусть, какая разница, главное работает.
Хочется акцентировать внимание ещё на нескольких моментах:
1. gearman ещё и неплохое средство failover'a: ничто не мешает клинтской части ходить на несколько gearman серверов, ничто не мешает каждому воркеру зарегистрироваться на нескольких серверах. Ничто не мешает одни и те же воркеры запускать сразу на нескольких машинах. Ничто не мешает воркеру «браться за работу» только если есть ресурсы (воркер должен «забрать задачу», сервер только посылает уведомления о наличии задачи). И всё это вместе чудесно работает. Таким образом «с полпинка» реализуется отказоустойчивость всех используемых компонентов с довольно гибким распределением нагрузки — отказ или повышенная загрузка любого одного узла никак не влияет на работу системы в целом.
2. Данные, которые передаются воркеру (и обратно) — это по сути дела одна огромная JSON-encoded строка (успешно передавал ~100MB данных, прекрасно пропускает). Что в свою очередь накладывает некий overhead.
3. Для синхронных задач — это далеко не самое лучшее средство. Всё происходит всё-таки довольно неспешно. Задачи, где критично время отклика я бы рекомендавал распределять как-то иначе. Всю свою прелесть оно проявляет на задачах где надо «отдать кому-нибудь и пусть оно где-то отработает, где есть кому это сделать, а мы пока дальше пойдём».
4. Великолепная на мой взгляд фича (хоть и не для всех задач) на синхронных задачах (частично упоминалось выше): если два клиента пришлют одинаковый запрос — он будет выполнен только один раз, НО результат получат оба, что при определённых условиях может сэкономить море ресурсов.
Хотя, возможно, существуют Round-robin DNS решения и лишённые этих недостатков. Если кто-то встречал такие — дайте ссылочку, пожалуйста — очень хочется пощупать.
Ну если быть точнее — я взял его за основу и убрал основные недостатки:
1. Время ответа: вместо обращения к библиотеке nss_files, чтения /etc/hosts, потом обращения к nss_dns, чтения /etc/resolv.conf и потом обращения к DNS serveram по списку (и обработки ответов, таймаутов, если кто-то из DNS упал) делается обращение к библиотеке nss_xxx которая отдаёт уже готовый ответ из shared memory, что, по идее, значительно быстрее.
2. При внесении изменений в DNS они вступят в силу на slave-dns серверах самое раннее через секунду (из-за TTL). Репликация зоны между DNS серверами — тоже не самое быстрое действие.
3. Нет необходимости в настройке Failover-DNS'a.
4. Если первый в списке resolv.conf DNS помер — второй будет использован только после таймаута (мин. 1 сек), и так далее по списку. При списке в 3 сервера это всё может залипнуть аж на 3 секунды.
5. Если одна из нод хочет сказать «притормозите, мне и так плохо» — через DNS это весьма нетривиальная задачка.
Всё это вместе делает использование обычного round-robin DNS'a для, например, обращения к mysql порядка 5 000 раз в секунду мягко говоря пороховой бочкой. Не дай бог первый в списке DNS тормознёт на несколько секунд…
Далее:
5. Общаться с УДАЛЁННЫМ bind'ом через rndc, менять зону скриптами и перезапускать dns-server с каждой ноды, так чтоб все это сразу подхватили — имхо куда сложнее чем тупо писать в файл (named-socket) команду типа 'delete host somename' или 'add host somename ip priority'
7. Настраивать всю это конструкцие со slave-dns на каждой ноде и возможностью быстро менять состояние зоны с каждой ноды — то ещё удовольствие.
А это не подпадает под недавно шумевшие законодательные нововведения, типа того, что скрытая видеосъёмка без соответствующей санкции властей — это нарушение закона и могут поинаказать?
[irony]Я был IT-шником лет за 20 до того как первый раз увидел хабр (в 10 лет сел за компьютер, в 12 лет уже писал на ассемблере). И (о ужас!) я узнал о Хабре по линку в одной локальной социалной сети, по сути своей близкой к Вконтакту, тока местячковой. Я наверное зря сюда пришёл, я сюда не подхожу? [/irony]
Это только мне стало казаться, что ~50% статей в последнее время — это прямой PR, доска объявлений о своих продуктах, при чём как правило не в рубрике «Я пиарюсь». Конкретно эта статья, лично мне, кажется больше похожей на рекламную компанию нового продукта, нежели на ценную информацию для сообщества. Или я отстал от жизни?
Думаю, если приспичило бы — многие догадались бы, но если ни разу ни нафиг не надо было — то идея в голову могла и не придти. Автору спасибо! Всё банально, но пока не прочёл — в голову не приходило. (:
1. gearman ещё и неплохое средство failover'a: ничто не мешает клинтской части ходить на несколько gearman серверов, ничто не мешает каждому воркеру зарегистрироваться на нескольких серверах. Ничто не мешает одни и те же воркеры запускать сразу на нескольких машинах. Ничто не мешает воркеру «браться за работу» только если есть ресурсы (воркер должен «забрать задачу», сервер только посылает уведомления о наличии задачи). И всё это вместе чудесно работает. Таким образом «с полпинка» реализуется отказоустойчивость всех используемых компонентов с довольно гибким распределением нагрузки — отказ или повышенная загрузка любого одного узла никак не влияет на работу системы в целом.
2. Данные, которые передаются воркеру (и обратно) — это по сути дела одна огромная JSON-encoded строка (успешно передавал ~100MB данных, прекрасно пропускает). Что в свою очередь накладывает некий overhead.
3. Для синхронных задач — это далеко не самое лучшее средство. Всё происходит всё-таки довольно неспешно. Задачи, где критично время отклика я бы рекомендавал распределять как-то иначе. Всю свою прелесть оно проявляет на задачах где надо «отдать кому-нибудь и пусть оно где-то отработает, где есть кому это сделать, а мы пока дальше пойдём».
4. Великолепная на мой взгляд фича (хоть и не для всех задач) на синхронных задачах (частично упоминалось выше): если два клиента пришлют одинаковый запрос — он будет выполнен только один раз, НО результат получат оба, что при определённых условиях может сэкономить море ресурсов.
1. Время ответа: вместо обращения к библиотеке nss_files, чтения /etc/hosts, потом обращения к nss_dns, чтения /etc/resolv.conf и потом обращения к DNS serveram по списку (и обработки ответов, таймаутов, если кто-то из DNS упал) делается обращение к библиотеке nss_xxx которая отдаёт уже готовый ответ из shared memory, что, по идее, значительно быстрее.
2. При внесении изменений в DNS они вступят в силу на slave-dns серверах самое раннее через секунду (из-за TTL). Репликация зоны между DNS серверами — тоже не самое быстрое действие.
3. Нет необходимости в настройке Failover-DNS'a.
4. Если первый в списке resolv.conf DNS помер — второй будет использован только после таймаута (мин. 1 сек), и так далее по списку. При списке в 3 сервера это всё может залипнуть аж на 3 секунды.
5. Если одна из нод хочет сказать «притормозите, мне и так плохо» — через DNS это весьма нетривиальная задачка.
Всё это вместе делает использование обычного round-robin DNS'a для, например, обращения к mysql порядка 5 000 раз в секунду мягко говоря пороховой бочкой. Не дай бог первый в списке DNS тормознёт на несколько секунд…
Далее:
5. Общаться с УДАЛЁННЫМ bind'ом через rndc, менять зону скриптами и перезапускать dns-server с каждой ноды, так чтоб все это сразу подхватили — имхо куда сложнее чем тупо писать в файл (named-socket) команду типа 'delete host somename' или 'add host somename ip priority'
7. Настраивать всю это конструкцие со slave-dns на каждой ноде и возможностью быстро менять состояние зоны с каждой ноды — то ещё удовольствие.
Ну а в остальном — да, согласен, довольно близко.
поинаказать?