coolwebsearcher, я вот с вашей ссылкой ознакомился , оттуда цитирую:
Тут в более понятной форме описано то, что я описал в посте /ru/forum/comment/9830566, постараюсь перевести максимально дословно то, что написано тут:
Второй абзац сами :D
А ТС-у судя по его вопросу, надо в >> уже существующей зоне << добавить ns3/ns4 раз он так хочет и сопоставить эти IP адреса в СВОЕЙ зоне.... ему не надо модифицировать $domain в котором он ns-ы то добавляет :D Че вы прицепились то к этому ?:) ТС будет добавлять в cPanel домены на сервере #2 а там будут прописаны ns3/ns4.существующий-работающий-основной-домен-тс-а.com :D Зачем для етого регистратор, тут в зону две записи вкинуть и go go go ;) Это если он допустим для своего "существующий-работающий-основной-домен-тс-а.com" захочет NS поменять у регистратора с двух на 4 тогда само собой вступит правило описанное вами и называемое Glue record, в этом случае вполне может быть надо будет контактировать регистратора.
Ну а какова тогда пропускная у FS фактическая, я привел вам показатели glusterFS , которая при 20-30MB/s записи на FS давала 100Mb/s в сети .... я конечно понимаю что форум мало вероятно даст 20Mb/s к ФС, но все таки, есть же и более высоко нагруженные проекты чем форумы...
Не сомневаюсь и с удовольствием бы поработал с вами над аналогичным решением совместно, но ввиду того что это мало вероятно, я все же то что мне надо сделаю сам :D Но спасибо за предложение в любом случае, меня техническая сторона интересует, концепция давно ясна и думаю не только вам с нами, хочется понять грубо говоря до каких пор будет достаточно решения master<->master к примеру, и при какой интенсивности работы FS умрет конектящий её линк :D
Народ , есть кто еще живой, проясните мне о чем coolwebsearcher, то о чем я говорю даже glue records перестало называться :D Может я перекурил или все таки coolwebsearcher что-то не так понимает? :) Или может какие-то регистраторы стали требовать предварительной регистрации DNS серверов ? WTF граждане ?:)
Насчет приваси понимаю, вопросов не имею, я имел ввиду несколько другое, меня интересовали технологии которые были использованы а не конкретные сайты которые на них работают , я в силах оценить степень нужности софта сам :D Насчет демонстрации живой - весьма интересно, с удовольствием, только не совсем понимаю, что именно вы хотите продемонстрировать?
Базы и файлы: В базах есть собственные реализации, я уже упоминал простейшие из них выше, типа ndb cluster или репликации Master<->Master в случае SQL.... Сетевые FS тоже есть и я их тоже разбирал и изучал..... с этим так же вопросов не имею, самый основной вопрос, через какие каналы передавать эти данные? Если схема стоит в 1м шкафу я так же вопросов не имею )))) Меня интересуют распределенные решения которые реально можно распределить на 5-10 датацентров в мире и при этом не придется прокладывать 100 км кабелей между этими точками, что бы моя FS при записи 20Mb/s на нее выдавала мне 100Mb/s в сеть .... вот где вопрос основной, если есть соображения или тем более наработки - я полон внимания и готов молча внимать :D
А адаптация сайтов и софта, это само собой мое дело (дело клиента)..... тут никто и спорить не будет :D :D :D стандартные приложения мало вероятно рассчитаны даже на работу с двумя базами одновременно не говоря про что-то более сложное :D Хотя вы знаете в opensource встречал... например radius, в его конфигурации например можно указать что accounting будет храниться в базе #1, А вот session-logs (radacct) в базе номер #2, т.е простейшая балансировка уже реализована в самом демоне, он уже умеет понимать что будет >1 базы данных :D при этом все честно , разные ИП , разные базы, разные сервера физические, проверял лично ... К этому надо стремиться софтоводам IMHO ;) Наверняка в любом движке и в любом сайте 20-30% актуального контента, а остальные 70-80% это архив.... который требуется раз в 100 лет.... когда кто-то что-то из гугла там нарыл старое или просто забрел, вот разложи его на 2 базы, уже легче станет :D
Это называется Glue Records, для этого мне надо:
1. Настроить на своей стороне ns1.test.com / ns2.test.com на двух ДНС серверах (ну или может быть на одном, как вы пишите).
2. Прописать у регистратора эти ДНС сервера в панели управления моим доменов. В целом это называется RIPE-049 кажется. (modify)
Если пункт 2 и есть то о чем вы говорите, то для ns3/ns4 мне аналогичных записей делать уже не надо будет (я имею ввиду случай когда ns3/4 будет отвечать за зоны моих клиентов , а не за саму зону test.com) :D Данный пример действует только в том случае если вы хотите указать NameServers из того же домена который сейчас и регистрируете\модифицируете (т.е желаемых к указанию NS серверов еще не может существовать). На сколько я понимаю ТС поставл второй сервер и на нем будут клиенты но он не понимает как туда прикрутить DNS сервера, так вот если у него там cPanel например или любая другая панель, будем считать что named У него настроен и все остальное. В зоне на ns1/ns2 он указывает что
ns3 IN A x.x.x.xns4 IN A y.y.y.y
после чего, смело регистрирует любой понравившийся ему домен на DNS сервера ns3,ns4.domain.com и даже в панель к регистратору топать не придется, не говоря уже о том, что что-то там РЕГИСТРИРОВАТЬ. (надо будет только панели управления рассказать, что все новые домены на этом сервере имеют записи ns3/ns4, что бы файл зоны верно создавался согласно серверу и его ДНС инфраструктуре ;) Все приведенные мною примеры актуальны только для варианта когда ДНС у клиента, а не у регистратора (как ошибочно любят делать многие :D ).
Глупость, никогда за исключением (glue records) не прописывал IP для DNS у регистратора доменов, года с 2005го в теме :D Как правило использование последних более редкость нежели регулярность , обычно если это хостеры, то у них уже есть domain.com и они предоставляют всем клиентам пользоваться их ns1/ns2 для этого никаких ИП адресов у регистратора писать не надо, достаточно будет прописать ns1.domain.com , резолв произойдет без вашего участия :D Представьте себе , что у вас 10.000 доменов, ну вот случилось так, и вы для каждого каждого прописали ИП адрес у 100 регистраторов у которых брали эти все 10.000 доменов, а вчера вам сказали что у регистраторов поменялся пул IP адресов.... вы хотите сказать что прилипли на 10.000 монотонных операций :D Увольте, глупо... :)
Сюда рекомендую включать кеширование прозрачное, например на базе SQUID. Если будете кешировать то 1 бекенд можно будет убрать. (это я про статику)---------- Post added at 18:52 ---------- Previous post was at 18:52 ----------
Само-реализовано или где-то пруфчик есть?:)---------- Post added at 18:54 ---------- Previous post was at 18:52 ----------
Не стоит, пробовал. как-то дико :D Лучше балансировать , если вы там пишите про разумно неограниченные бюджеты рассмотрите железку типа Foundry ServerIron 400 или 400 XL, она ответит на много вопросов в одной точке, причем как по кешированию, так и отдаче\приему трафика.
Меня именно смущает слово "создавать" я до сих пор не понимаю, может мы об одном и том же, у регистратора надо >> прописать << DNS сервера которые будут отвечать за зону этого домена, как я показал пример с доменом onyx.net.ua я сейчас полезу к регистратору в панель и пропишу там еще дополнительно ns3 & ns4.register.org.ua , но мне придется сделать аналогичные изменения в файлах зон на первых двух серверах , а так же как и следствие на третьем и четвертом.
По этому если "регистрировать у регистратора DNS" = "прописать свои ДНС у регистратора" то мы об одном и том же, а если вы подаете какие-то доп данные именно по регистрации самих ДНС серверов у регистратора, то вы или ошибаетесь или таки какими-то мутными регистраторами пользуетесь. Но в одном я уверен точно, создавать ДНС я могу без кого либо, не важно регистратор он или нет :D И если мне действительно понадобится ns3/ns4 для клиентов (для их доменов), то мне вовсе не обязательно будет писать что либо регистратору я просто в зону у себя на ДНС добавлю две записи и все остальные смогут пользоваться ns3/ns4
Вроде полностью цитировал, ну вот "создали" вы там 2 NS сервера, а потом топаете прописываете туда третий, если вы при этом не измените содержание зон то нифига у вас работать не будет, точнее будет но коряво, будут 3 ДНС сервера отвечать 2 NS записи (если вы третий с общей массой синхронизируете). По этому если вы "пропишите" что бы появилось тут (http://www.internic.net/whois.html) хоть 10 NameServer-ов, это вовсе не значит что они начнут ссылаться на какие-то IP :) (это только в том случае может быть , если вы будете держать ДНС у регистратора, но тогда там и "прописано" будет то, что говорит регистратор :D)
Так я же написал, паритетный линк.... у меня было 4 сервера кажется собрано в кучу, в каждом по 2 NIC, одна сторона смотрела только в синхронизацию FS, вторая во все остальное, проблем с доступностью машин не было :D Была полочка ... :)) 90Mb/s
Ай да молодца!!!! :D :D Вот сразу же видно наш человек :D Сказали .... сделал... что уж там.
+100500
Попробую натолкнуть, комьюнити рассудит: Я лично не сталкивался с масштабами в 300 и более сайтов но видел достаточно много распределенных систем отдачи и скорее всего, мне кажется, что синхронизация 300 сайтов (что я думаю мало само по себе, реально то на любом хостинг сервере может быть 3000 сайтов...) это процесс который растягивать через интернет вообще не имеет смысла, такие решения могут базироваться на том же rrDNS, но уже с более серьезной отдачей в каждой из точек, так сказать развитие "изнутри", мне кажется что развитие с "наружи" с точки зрения маршрута мир->ваш сайт, заканчивается на DNS... :) когда вы 1й A записи выдали 20 IP адресов... вы уже не кисло распределили. Почему например Google не вкидывает по 20 серверов в каждый ДЦ в стране, а строит 1 свой (грубо говоря)... вот на этот участок "их схемы" будет 1 ip овтернут в rDNS :D а реально там 100.000 тазиков будут запросы поисковика обслуживать :D---------- Post added at 21:39 ---------- Previous post was at 21:33 ----------
Мне вот становится не ясно, почему вы в контексте rrDNS упоминаете drbd, если я все правильно помню, то при использовании кажется hearthbeat или как-то так мы получаем точно такую-же машинку, она даже IP адрес основной на себя перехватывает... зачем тут rrDNS. В моем понимании rrDNS это например:
Когда за один домен отвечает несколько серверов, а DRBD по моему такой возможности не дает, они работают заменяя друг друга в случае падения мастера.. хотя тут могу ошибаться, работал ОЧЕНЬ давно с DRBD :)---------- Post added at 21:42 ---------- Previous post was at 21:39 ----------
А что бы ты предложил с точки зрения кластерных FS если у меня например стоит 5-10 серверов в 5-10 странах мира, ну и как бы хотелось бы адекватную скорость ответа FS в точке её монтирования.... Я понял для себя пока, что всякие glusterfs, lustrefs хороши только в тех случаях когда у вас винты оптикой друг в друга включены :D а если они на расстоянии витой пары, то тот-же glusterfs уничтожил паритетные 100Mb/s для работы FS при нагрузке кажется в 30-40Mb/s на винты (write to FS)---------- Post added at 21:43 ---------- Previous post was at 21:42 ----------
Поддерживаю, я думаю нужно некое подобие RAID-5 с точки зрения MYSQL (nmbd, replication), то есть 3 тазика с подменой, и на FS нужно что-то подобное... это в одной точке даст мало мальски но устойчивость, если разнести это за пределы ДЦ - думаю равно самоубийству :D
