Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
Думаю, они кончатся к 2012 году :).
К чёрту биткойн и криптовалюту, надо запретить IPv6 и использовать все айпи-адреса в качестве аналога золота.
wget albatross.ripe.net/delegated-extended/delegated-ripencc-extended-latest.bz2 -O - 2>/dev/null | bzip2 -dc | awk -F'|' '/available/{sum+=$5}END{print sum}'не заметил ipv4:
wget albatross.ripe.net/delegated-extended/delegated-ripencc-extended-latest.bz2 -O - 2>/dev/null | bzip2 -dc | awk -F'|' '/available/&&/ipv4/{sum+=$5}END{print sum}'
или использовать curl
И вывод подавить, ага:
curl -s albatross.ripe.net/delegated-extended/delegated-ripencc-extended-latest.bz2 | bunzip2 | awk -F'|' '/available/&&/ipv4/ {sum+=$5} END {print sum}'
curl -s albatross.ripe.net/delegated-extended/delegated-ripencc-extended-latest.bz2 | bunzip2 | awk -F'|' '/available/&&/ipv4/ {sum+=$5} END {print sum}'
man -P 'less -p -q' wget
Ну сколько можно мусолить эту тему. На моей памяти это уже четвертая или пятая статья.
Я вообще думал, что они давно уже закончились и реально подумывал на IPv6 переходить, значит не все так плохо. Интересный вопрос в тему IP адресов — допустим крупная контора перешла на IPv6, в этой конторе администратор использовал radmin для администрирования, как звонящим пользователям диктовать эти огромные цифры, что бы администратор смог достучаться до пользователя? Если даже IPv4 они с ошибками диктуют, да и вообще с помощью radmin'а можно будет комфортно работать или придется создавать список по отделам и т.п. Вопросов больше, чем ответов.
ярлычки соединений по надиктованным ящикам высылать
Лучше через политику ссылка в браузере. )
А по ссылке страница с 2-мя полями
примерно так:
А дальше на сервере поймать и ip адрес и все что нужно) И если мозгов хватит асилить phpMailer то еще и себе на почту тут-же отправить. Или на мабилку смс-кой.
Все равно если сеть не работает придется топать пешком…
А по ссылке страница с 2-мя полями
примерно так:
/>
У меня не работает:
/>
А дальше на сервере поймать и ip адрес и все что нужно) И если мозгов хватит асилить phpMailer то еще и себе на почту тут-же отправить. Или на мабилку смс-кой.
Все равно если сеть не работает придется топать пешком…
Да блин как код-то по человечески вставить?
/ > < br / >
У меня не работает: < br / >
/ >
Вот что я имел в виду в камменте выше!
/ > < br / >
У меня не работает: < br / >
/ >
Вот что я имел в виду в камменте выше!
Все равно не получилось хотя просмотр все показал, ну вобщем вы поняли что нужна примитивная веб страничка с полем для ввода имени и проблемы и кнопка отправить.
Сорри за «флуд» я не специально.
Сорри за «флуд» я не специально.
DNS вас спасет.
может использовать dns?
Вот именно такие НЕДО_АДМИНЫ и минусуют в карму тем, кто пишет про v6 и прочий бред (простите) вроде этого комментария. У НОРМАЛЬНОГО(тм) админа настроен DNS. Всегда. Даже на сетке в 10 машин. Одна из первостепенных задач администратора — это добится максимальной управляемости инфраструктуры, а какая-же тут управляемость если надо по телефону объяснять как посмотреть и продиктовать ip адрес? Пользователь должен назвать фамилию имя и в крайнем случае номер (и/или имя рабочей станции), остальное не его заботы.
P.S. прежде чем минусовать — посмотрите на свою сетку и попробуйте найти проблему в себе.
P.S. прежде чем минусовать — посмотрите на свою сетку и попробуйте найти проблему в себе.
Видимо слово — «допустим» никто не прочитал в моем комментарии. Печально!
Вот представьте, у вас есть кластер из нескольких тысяч одинаковых или почти одинаковых машин, постоянно выполняющих какую-то вычислительную задачу. Вы к ним будете обращаться по IP (например, 10.0.x.x) или будете вводить какие-то имена? Если имена — то можете объяснить, зачем? Если по IP — то тогда не стоит так категорично про «всегда» и «даже на сетке в 10 машин».
Интересная мысль)
Но я бы поступил хитрее)) я бы им выделил отдельную DNS зону, внутри настроил DHCP чтобы не геморроиться с «администрированием адресации» а им давал имена по порядку в шестнадцатиричной системе 1.mycluster.что-то 2.mycluster.что-то… A0.mycluster.что-то и так далее ;) и обращаться проще и этот номер можно приклеить на корпус чтоыб не искать какой системник вытаскивать ;)
Но я бы поступил хитрее)) я бы им выделил отдельную DNS зону, внутри настроил DHCP чтобы не геморроиться с «администрированием адресации» а им давал имена по порядку в шестнадцатиричной системе 1.mycluster.что-то 2.mycluster.что-то… A0.mycluster.что-то и так далее ;) и обращаться проще и этот номер можно приклеить на корпус чтоыб не искать какой системник вытаскивать ;)
Здорово, а что это дает, кроме лишней сущности, лишнего времени на настройку, лишней точки отказа и т.д.? Какая разница между тем, что писать — 10.0.0.3 или 3.mycluster.что-то?
Ну если вы глубоко знаете UNIX системы я не думаю что имеет смысл Вам объяснять почему вместо ssh root@10.0.0.3 можно написать ssh root@3 ) В случае использования DNS это довольно просто делается) это к вопросу о краткости…
Ну если уж говорить о ssh в unix, то куда удобнее прописать серваки в .ssh/config и писать вообще ssh server1 нежели ssh -p 3647 user@server1 -some_options.
Технически, кстати, написать ip-адрес «3» нельзя, по RFC это всегда четко обозначает IPv4 адрес 0.0.0.3, который, скорее всего, в обычной системе является Invalid argument при попытке connect(). Так что, да, если уж делать — то вероятнее всего там будет что-то типа «n3», с соответствующей настройкой ресолвера…
Основной вопрос — зачем это делать? Обычно на вычислительном кластере никто в нормальном режиме, тем более «обычные пользователи», не ходит по отдельным нодам — такое нужно в основном для задач администрирования.
Основной вопрос — зачем это делать? Обычно на вычислительном кластере никто в нормальном режиме, тем более «обычные пользователи», не ходит по отдельным нодам — такое нужно в основном для задач администрирования.
КЭП, я знаю это. Что ip адрес «3» написать нельзя. А вот доменное имя можно!
Поэтому вы уж меня извините за некотоый снобизм, но прежде чем доказывать преимущество теплых ламповых v4 адресов против бездушных DNS изучите хотя бы основные моменты «как это работает».
Без обид. Но это правда.
Поэтому вы уж меня извините за некотоый снобизм, но прежде чем доказывать преимущество теплых ламповых v4 адресов против бездушных DNS изучите хотя бы основные моменты «как это работает».
Без обид. Но это правда.
О, боги… Я говорю вообще-то прямо противоположное. IP-адрес «3» как раз существует и соответствует IPv4 адресу 0.0.0.3:
Доменное имя «3.cluster.example.com» завести можно, но куда бы вы его не прописали, до DNS в этом случае дело просто не дойдет. Даже если у вас заведена, условно, зона cluster.example.com, в которой проходит ресолвинг:
И есть в /etc/resolv.conf (или его аналоге) строчки типа таких:
При попытке сделать что-либо с хостнеймом «3», вместо ожидаемого обращения и ресолвинга «3.cluster.example.com» произойдет странное:
Т.е. де факто пользоваться тем решением, что вы предлагаете — нельзя. Поэтому если уж делают в таких случаях пачки записей в зонах — то хотя бы начинают их с буквы, в этом случае все работает:
Так что, пожалуйста, оставьте отеческий тон и, действительно, если уж хотите продолжать эту дискуссию, почитайте хотя бы базовые RFC про IPv4, про хостнеймы и ознакомьтесь с тем, что такое ресолвер, где он находится, какие они бывают, как они работают, какие плюсы и минусы они привносят в систему.
$ traceroute 3 traceroute to 3 (0.0.0.3), 30 hops max, 60 byte packets
Доменное имя «3.cluster.example.com» завести можно, но куда бы вы его не прописали, до DNS в этом случае дело просто не дойдет. Даже если у вас заведена, условно, зона cluster.example.com, в которой проходит ресолвинг:
$ host 3.cluster.example.com 3.cluster.example.com has address 10.0.0.3
И есть в /etc/resolv.conf (или его аналоге) строчки типа таких:
domain cluster.example.com search cluster.example.com
При попытке сделать что-либо с хостнеймом «3», вместо ожидаемого обращения и ресолвинга «3.cluster.example.com» произойдет странное:
$ ssh 3 ssh: connect to host 3 port 22: Invalid argument $ ping 3 connect: Invalid argument $ traceroute 3 traceroute to 3 (0.0.0.3), 30 hops max, 60 byte packets connect: Invalid argument
Т.е. де факто пользоваться тем решением, что вы предлагаете — нельзя. Поэтому если уж делают в таких случаях пачки записей в зонах — то хотя бы начинают их с буквы, в этом случае все работает:
$ ssh n3 Last login: Fri Aug 10 00:35:10 2011 from 10.0.0.1 [greycat@n3 ~]$
Так что, пожалуйста, оставьте отеческий тон и, действительно, если уж хотите продолжать эту дискуссию, почитайте хотя бы базовые RFC про IPv4, про хостнеймы и ознакомьтесь с тем, что такое ресолвер, где он находится, какие они бывают, как они работают, какие плюсы и минусы они привносят в систему.
Грамотно, не поспоришь
Все верно, здесь разбираны причины. Зависит от того, как утилита пытается разобрать адрес, если сразу стучиться в днс — то может 3 и сработать.
Есть еще RFC по DNS и полное имя домена будет выглядеть так: «3.»
$ traceroute 3. traceroute to localhost (127.0.0.1), 64 hops max, 52 byte packets 1 localhost (127.0.0.1) 0.269 ms 0.031 ms 0.027 ms
Прошу прощения, я Вас неправильно понял. Да, вы совершенно правы. Беру свои слова назад)
Но принципиально я с Вами все равно не согласен)
С DNS ИМХО работать удобнее чем с адресами.
Мне от прошлого одмине досталась сетка в которой 70 машин были размазаны на 170 адресов ибо выдавал он их по принципу
ping 192.168.1.90 — пакеты пошли, ок
ping 192.168.1.93 — пакеты не пошли? отлично его и выдадим.
Вот незадача-то была. Поэтому DHCP и только DHCP ДЛЯ ОДНОТИПНЫХ ПО ФУНКЦИОНАЛУ УЗЛОВ. Иначе, повторюсь, придется заниматься дополнительным администрированием адресного пространства, вести где-то журнал выданых адресов и т.д. и т.п. Зачем создавать себе работу?
Ну и выражаю Вам благодарность за этот комментарий, я не знал что цифры не будут правильно резолвится, а вообще именно это и имел в виду.
Ну и еще раз прошу прощения за недопонимание и как следствие не очень приятную ситуацию)
Но принципиально я с Вами все равно не согласен)
С DNS ИМХО работать удобнее чем с адресами.
Мне от прошлого одмине досталась сетка в которой 70 машин были размазаны на 170 адресов ибо выдавал он их по принципу
ping 192.168.1.90 — пакеты пошли, ок
ping 192.168.1.93 — пакеты не пошли? отлично его и выдадим.
Вот незадача-то была. Поэтому DHCP и только DHCP ДЛЯ ОДНОТИПНЫХ ПО ФУНКЦИОНАЛУ УЗЛОВ. Иначе, повторюсь, придется заниматься дополнительным администрированием адресного пространства, вести где-то журнал выданых адресов и т.д. и т.п. Зачем создавать себе работу?
Ну и выражаю Вам благодарность за этот комментарий, я не знал что цифры не будут правильно резолвится, а вообще именно это и имел в виду.
Ну и еще раз прошу прощения за недопонимание и как следствие не очень приятную ситуацию)
А какая разница писать в программ переменные $a,$b,$c или давать им осмысленные имена, отражающие их сущность?
видя доменное имя server1.cod5.moscow.megacluster можно сразу понять, что там за машина, а адрес вида 10.0.0.3 вообще в себе никакой инфы не несет.
видя доменное имя server1.cod5.moscow.megacluster можно сразу понять, что там за машина, а адрес вида 10.0.0.3 вообще в себе никакой инфы не несет.
Если у вас кластер из нескольких тысяч одинаковых машин, то вы не будете обращаться к отдельно взятой. Деплоймент автоматический, при выходе из строя — простая замена железки на аналогичную, имена и айпишники будут волновать в последнюю очередь.
кластер на 1к одинаковых машин очень часто встречается в работе сисадмина!
да даже и для такой задачи можно, например, ввести привязку к физическому месторасположению.
если в одном помещении — то ряд/строка, если несколько — то добавляем еще номер комнаты.
да даже и для такой задачи можно, например, ввести привязку к физическому месторасположению.
если в одном помещении — то ряд/строка, если несколько — то добавляем еще номер комнаты.
Все, что вы предлагаете пока — числа. Чем вам не нравится «10.комната.стойка.порядковый-номер-сервера-в-стойке»? Я к тому, что забивать зоны тучей бессмысленных мэппингов вида
s10 A 10.1.3.10
s10 A 10.1.3.10
s11 A 10.1.3.11
s12 A 10.1.3.12
…
и т.д. — именно что бессмысленно, т.к. для присвоения каких-то порядковых величин человечество придумало нумерацию и её одной более, чем достаточно…
(прошу прощения, Ctrl+Enter нажался неожиданно)
s12 A 10.1.3.12
…
и т.д. — именно что бессмысленно, т.к. для присвоения каких-то порядковых величин человечество придумало нумерацию и её одной более, чем достаточно…
(прошу прощения, Ctrl+Enter нажался неожиданно)
На нашем кластере (100+ машин) имена nXXX. Зачем? Для удобства пользователя.
$ ssh headnode.example.com
$ ssh n042Простите, во-первых, в чем удобство-то? Вы предлагаете делать двойной туннель (два раза делать ssh — с первой на вторую (headnode) и на третью машину (n042)) вместо того, чтобы прямо с терминала же сделать ssh 10.0.0.42 и всё.
Во-вторых, и в главных — зачем это нужно пользователям? Если это вычислительный кластер — то на нем обычно задача запускается где-то в районе какой-то центральной ноды (а то и совсем без нее — вбрасывается в ней распределенный пул), пользователи с отдельными физическими нодами не работают.
Во-вторых, и в главных — зачем это нужно пользователям? Если это вычислительный кластер — то на нем обычно задача запускается где-то в районе какой-то центральной ноды (а то и совсем без нее — вбрасывается в ней распределенный пул), пользователи с отдельными физическими нодами не работают.
По первому пункту: давайте, сделайте мне ssh 10.0.0.42 из интернета на наш кластер.
По второму: да, в 99% система запуска задач конечно же. Но а если задача падает на определённой ноде когда на остальных работает? А если надо отладчиком прицепиться? (И ещё куча вариантов)
По второму: да, в 99% система запуска задач конечно же. Но а если задача падает на определённой ноде когда на остальных работает? А если надо отладчиком прицепиться? (И ещё куча вариантов)
А у вас headnode.example.com имеет внешний IP? А зачем — только в качестве шелл-бокса? Обычно все-таки шелл-боксы в отдельных местах устраивают — зачем же рисковать главной нодой кластера?..
В случае, если речь не о работе из внутренней сети (что, вообще, достаточно логично — иметь для кластера отдельную внутреннюю сеть), то подразумевается, что человек сначала себе доступ во внутреннюю сеть обеспечивает (через какой-то VPN, как правило — хоть на базе того же ssh), а затем беспрепятственно этой сетью пользуется. VPN же зачастую (например, ssh-based VPN или те же pptp на маках, скажем) существующие системные настройки DNS никак не меняет и не дополняет. В итоге, подключившись к VPN и получив роутинг до 10.0.0.0/8, скажем, делать сразу после этого «ssh 10.0.0.42» можно, а вот чтобы сделать «ssh n042», придется еще как минимум лезть в /etc/resolv.conf, доступа к которому, вообще говоря, может и не быть.
Так что если используется внутренняя сеть и какой-либо VPN для доступа в нее — с этой точки зрения использование просто IP-адресов тоже на практике оказывается более простым и надежным.
В случае, если речь не о работе из внутренней сети (что, вообще, достаточно логично — иметь для кластера отдельную внутреннюю сеть), то подразумевается, что человек сначала себе доступ во внутреннюю сеть обеспечивает (через какой-то VPN, как правило — хоть на базе того же ssh), а затем беспрепятственно этой сетью пользуется. VPN же зачастую (например, ssh-based VPN или те же pptp на маках, скажем) существующие системные настройки DNS никак не меняет и не дополняет. В итоге, подключившись к VPN и получив роутинг до 10.0.0.0/8, скажем, делать сразу после этого «ssh 10.0.0.42» можно, а вот чтобы сделать «ssh n042», придется еще как минимум лезть в /etc/resolv.conf, доступа к которому, вообще говоря, может и не быть.
Так что если используется внутренняя сеть и какой-либо VPN для доступа в нее — с этой точки зрения использование просто IP-адресов тоже на практике оказывается более простым и надежным.
Объясните:
1. Шелл-бокс — это не что-то плохое. Во-первых, и так известна вся информация про каждого пользователя. И во-вторых, всё равно у пользователей есть шелл-доступ к сотне узлов кластера. Какая разница, пусть будет на один узел больше. Кроме того, головной узел имеет доступ к кластерной ФС и через него пользователи загружают/сгружают данные.
2. Какой профит будет при использовании VPN? Пока я вижу только недостатки: для админа — нужно объяснить пользователю как пользоваться VPN и обеспечить работу клиента на всех платформах, поддерживать работоспособность VPN сервиса (так у нас был только ssh критичен, а теперь ещё и VPN). Для пользователя — нужно стартовать VPN перед работой и нельзя делать ssh n042 (а какой смысл в том, что пользователь будет набирать эти символы «10.0.0.»? вместо них одна буква n и все счастливы).
3. Вдруг необходим renumbering. Всей сотне пользователей теперь объяснять, что у узлов другие адреса? Просто смешно.
> В случае, если речь не о работе из внутренней сети (что, вообще, достаточно логично — иметь для кластера отдельную внутреннюю сеть)
Игра слов. Давайте я скажу:
В случае, если речь не о работе из внутренней сети (что, вообще, достаточно логично — иметь для чтения habrahabr.ru отдельную внутреннюю сеть), необходимо читать хабр через VPN.
1. Шелл-бокс — это не что-то плохое. Во-первых, и так известна вся информация про каждого пользователя. И во-вторых, всё равно у пользователей есть шелл-доступ к сотне узлов кластера. Какая разница, пусть будет на один узел больше. Кроме того, головной узел имеет доступ к кластерной ФС и через него пользователи загружают/сгружают данные.
2. Какой профит будет при использовании VPN? Пока я вижу только недостатки: для админа — нужно объяснить пользователю как пользоваться VPN и обеспечить работу клиента на всех платформах, поддерживать работоспособность VPN сервиса (так у нас был только ssh критичен, а теперь ещё и VPN). Для пользователя — нужно стартовать VPN перед работой и нельзя делать ssh n042 (а какой смысл в том, что пользователь будет набирать эти символы «10.0.0.»? вместо них одна буква n и все счастливы).
3. Вдруг необходим renumbering. Всей сотне пользователей теперь объяснять, что у узлов другие адреса? Просто смешно.
> В случае, если речь не о работе из внутренней сети (что, вообще, достаточно логично — иметь для кластера отдельную внутреннюю сеть)
Игра слов. Давайте я скажу:
В случае, если речь не о работе из внутренней сети (что, вообще, достаточно логично — иметь для чтения habrahabr.ru отдельную внутреннюю сеть), необходимо читать хабр через VPN.
1. Шелл-бокс — это само по себе хорошо, но совмещать его с любой другой машиной — априори плохо. Базовый принцип безопасности, управляемости системы и т.д. — зачем смешивать разные сервисы на одной и той же машине?
2. Я вполне понимаю, что VPN и шелл-бокс — это плюс-минус одно и то же. Вся разница именно в этих плюсах и минусах. У VPN они одни (есть прямой доступ сразу ко всем машинам; нужно что-то скачать/закачать — scp прямо на целевую машину и всё), у шелл-бокса — другие (быстрый старт, легко использовать внутренний DNS, не нужно разбираться с VPN, две команды ssh и ты уже на месте).
3. Смешно, если в отдельно выделенной под кластер сети *внезапно* понадобился renumbering. Это, как минимум, намекает на то, что изначально принятые архитектурные решения были какими-то, видимо, неверными.
2. Я вполне понимаю, что VPN и шелл-бокс — это плюс-минус одно и то же. Вся разница именно в этих плюсах и минусах. У VPN они одни (есть прямой доступ сразу ко всем машинам; нужно что-то скачать/закачать — scp прямо на целевую машину и всё), у шелл-бокса — другие (быстрый старт, легко использовать внутренний DNS, не нужно разбираться с VPN, две команды ssh и ты уже на месте).
3. Смешно, если в отдельно выделенной под кластер сети *внезапно* понадобился renumbering. Это, как минимум, намекает на то, что изначально принятые архитектурные решения были какими-то, видимо, неверными.
1. Какие риски-то?
2. scp на конкретную машину не нужен, потому что используется кластерная ФС.
3. Институтский телеком скажет сделать ренамберинг, значит придётся делать. И тут вопрос не в наших решениях.
2. scp на конкретную машину не нужен, потому что используется кластерная ФС.
3. Институтский телеком скажет сделать ренамберинг, значит придётся делать. И тут вопрос не в наших решениях.
Ох, пожалуй, с этого и стоило начинать — т.е. отдельной сети нет, сетью вы не управляете, она дана свыше. Тогда, разумеется, это аргумент, который все остальное перечеркивает — тогда, разумеется, я всеми руками за DNS, а также, видимо, за организацию доступа к этой сети наиболее простым способом — т.е. через ssh.
Мне кажется, что дискуссия уже сильно начинает выходить за тематику этого поста — предлагаю, если есть желание обсудить вопросы безопасности и вообще best practices деплоймента и администрирования кластеров, продолжить ее приватно.
Мне кажется, что дискуссия уже сильно начинает выходить за тематику этого поста — предлагаю, если есть желание обсудить вопросы безопасности и вообще best practices деплоймента и администрирования кластеров, продолжить ее приватно.
Не всегда. Я уже писал, что в продакте я либо использую hosts либо вообще IP, т.к. сбой DNS сервера может быть слишком фатальным для некоторых структур.
Тогда нужен либо автодеплоер, который будет поддерживать все hosts, либо ещё какой-нибудь костыль для централизованного их обновления, т.к. ошибка ручного редактирования может быть слишком фатальной для некоторых структур.
В случае с DNS можно использовать дублирующие, на худой случай — HA решение (haproxy).
В случае с DNS можно использовать дублирующие, на худой случай — HA решение (haproxy).
Не совсем так. Когда я узел настраиваю — можно делать что угодно (и ошибаться как хочу). Как только узел настроен — никаких изменений с hosts/dns и IP там больше не производится. Если нужно что-то сделать — узел сначала выводится из эксплуатации, а потом уже мурыжится любым комфортным способом.
Топик называется — «Сколько свободных ipv4 осталось?» а обсуждения (комментарии) совсем по другой теме.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сколько свободных ipv4 осталось?