Лига Сисадминов

В связи с очень полезным начинанием пикабушницы @virrasha попробую в меру сил продолжить ликбез. Обдумывая с чего же начать, решил не мудрствовать и начать с истории, тем более, что похожие попытки популярно это объяснить довольно редки, известные мне - "В Internet через ethernet" на nag.ru.

Все нижеописанное это совсем непрофессиональная и, вероятно, не общепринятая, а очень частная точка зрения на сегодняшнее положение вещей в мире передачи информации в компьютерных сетях и как оно к этому пришло :). Поэтому комментарии и исправления ошибок и неточностей от знающих людей всячески приветствуются.

Начало электросвязи это телефония, которая почти век и была практически монопольной электросвязью в головах большинства человеков. Были еще конечно телеграфы и телетайпы и многое другое, но телефония, пожалуй, это более 90% передаваемой электронными каналами информации, по крайней мере измеряемой в конечных пользователях, в течение очень долгого, долгого времени.

В этом месте нужно сделать первое отступление о коммутации. Все я разбирать не буду, остановлюсь на 2х важных вариантах: 1й - коммутация каналов, 2й - коммутация пакетов.

Так вот, телефония изначально была коммутацией каналов, вспомните фразу "Девушка, Смольный!". Использование людей-операторов, кстати, для коммутации телефонных линий до сих пор практикуется, хотя технологии стремительно шли вперед и довольно быстро появились механические АТС, а за ними всякие квазиэлектронные и электронные.

Большинство событий в начале эпохи цифровой передачи данных были подчинены телефонии и парадигме коммутации каналов. Цифровая передача данных в начале при всем своем отличии от механических вариантов коммутации была заточена под то же самое. Первые технологии цифровой передачи данных PDH и SDH это 50е-80е годы XX века, это технологии коммутации каналов с мультиплексированием во времени. Каналы делились на таймслоты по 64 килобита/с и из них создавался результирующий канал определенной пропускной способности T1, E1, E2 и т.д. При, например, звонке от Васи к Пете для передачи голоса резервировалось нужное количество временных интервалов (таймслотов) для передачи голосового траффика в реальном времени. Эти таймслоты при неиспользовании или недогруженности информацией для других целей использовать в сети было уже нельзя.

Для передачи чистых цифровых данных (фоточек котиков сообщений электронной почты, например) SDH годился, но с соответствующими издержками коммутации каналов. Для развития чистой передачи цифровых данных в 70х-80х того же века был разработан ATM.

ATM в виде ISDN и DSL был довольно распространен и популярен до 2000х, он подразумевал коммутацию пакетов, возможности передачи поверх SDH/PDH, был все еще тесно связан с телефонией. Для передачи информации использовались цифровые ячейки (пакеты фиксированного размера по 53 байта с заголовком в 6 байт и с полезной нагрузкой в 48 байт) в которые могли инкапсулироваться самые разные данные от текстовых файлов до голосовых звонков в реальном времени, имелись механизмы управления качеством обслуживания, коммутация пакетов позволяла эффективнее использовать пропускную способность канала для передачи чистых цифровых данных в компьютерных сетях чем SDH/PDH. А заложенные изначально в оборудование и технологию развитые возможности для работы с конечными абонентами с корнями из телефонии позволяли операторам строить эффективные сети для продажи услуг цифровой связи.

У ATM было светлое долгое будущее, которое, однако не наступило... Поскольку рядом существовала и развивалась еще одна технология электросвязи - Ethernet. Это была технология создания локальных, а не глобальных компьютерных сетей, предназначенная исключительно для создания офисных, ну максимум кампусных сетей, но обгадившая однако телефонистам много малины. И продолжающая стабильно обгаживать дальше еще больше.

Продолжение следует...

Пока тема про собеседования свежа.

Мною было обещано выложить вопрос, который можно задать при собеседовании на сисадмина (скорее админа-сетевика) и больше не спрашивать ничего.

Вопрос звучит так:

«Вы открываете в своей любимой операционной системе свой любимый браузер и вводите в адресную строку адрес любимого сайта. Затем вы нажимаете «Enter» и через некоторое время у вас отображается этот сайт. Расскажите как можно подробнее, что произошло с того момента, как вы нажали «Enter» до того как начали читать pikabu у вас отобразился сайт.»

Тот, кто первый раз задал мне этот вопрос, сказал, что у него ответ без углубления в детали занимает 3 семестра лекций в университете (и это не учитывая область web-программирования, которую также можно при желании затронуть – смотря, на кого собеседование). Здесь можно рассказывать всё – от того, каким образом у вас на компе оказались какие-то сетевые настройки до полного пересказа главы из Олиферов про физическое кодирование двоичных данных (шутка). DNS, proxy, firewall, VLAN, NAT, статическая и динамическая маршрутизация, пиление потока данных на пакеты, тройное рукопожатие и т.д. – всё, что вспомните.

Бонус - тот же вопрос можно задавать web-программисту, просто ответ будет затрагивать другие области.

Как и обещала, выкладываю первую часть.

Некоторое введение: статьи о базовых понятиях я писала еще в универе по лекциям, затем их вычитывал мой научный руководитель (aka nixleader), поэтому тега «моё» не будет. Статьи не претендуют на оригинальность, есть множество других. Они, также, вероятно, могут встретится в сети (распространялись в универе и свободно висят в справочной системе на работе). Я постараюсь указывать места, где будет встречаться копипаста с других ресурсов (далее такое будет). Помимо простых вещей, попробую привести в литературную форму некоторые сложные маны, которые писала чисто для себя, и выложу их отдельно.

Администрирование#01. Адресация в IP сетях

В семействе протоколов TCP/IP используются три типа адресов: локальные (физические, аппаратные), IP-адреса и символьные (доменные) имена. Рассмотрим первые два типа адресов.

Основные термины:

Хост (Host) – устройство, работающее в сети на сетевом уровне модели OSI (компьютер, маршрутизатор и т.п.). Часто понятие путают с IP-адресом.

MAC-адрес — физический адрес компьютера (если точнее - сетевой карты или другого сетевого устройства). Размер адреса – 6 байт. Этот адрес должен быть уникальным для каждого устройства в локальной сети, и используется всеми устройствами для передачи данных внутри неё. (Как говорил мой преподаватель: «Вы еще не видели китайских сетевых карт: в одной серии карт может быть много повторяющихся MAC-адресов»).

IP-адрес

IP-адрес — это 32 бита (4 байта), 4 октета, представляющие собой «логический» адрес хоста в сети (сетевой адрес). Нужно понимать, что у одного хоста может быть много IP-адресов.

IP-адреса обычно записываются в десятичной системе счисления виде четырёх октетов X1.X2.X3.X4, где X1 – старший байт адреса.

Есть консорциум IANA, который раздает IP-адреса по 5 организациям (ARIN, RIPE, APNIC, AfriNIC, LACNIC). Им выдаются сети класса А. Далее эти организации распределяют адреса по заявкам от организаций со статусом LIR (Local Internet Resource) подсетями /22 или крупнее, а в случае выделения провайдеро-независимого блока - /24 (класс C) и крупнее.

Маска подсети — указывает, какая часть IP-адреса приходится на адрес сети, а какая — на адрес хоста в ней. Без адреса сети или IP-адреса используется только в обсуждении количества используемых/необходимых адресов.

Маска - это последовательность скольких-то единичек в начале, а потом - нулей, составляющих в итоге 32 бита. Бит равный единице означает, что на его месте в IP-адресе бит будет входить в адрес сети. Нулевые биты в маске определяют позиции бит адреса хоста в IP-адресе.

Маска записывается через “/” после IP-адреса и может записываться как IP (например, 192.168.1.100/255.255.255.0; Здесь маска 255.255.255.0 — это 24 единички и 8 нулей (в двоичной системе), первые 24 символа будут адресом сети, оставшиеся 8 — адресом хоста), или как число от 0 до 32 (192.168.1.100/24 — здесь «/24» — это маска, то есть 24 единички в начале, остальные — нули).

Адрес сети – зарезервированный IP адрес, используемый для обозначения всей сети (совместно с указанием маски сети). В адресе сети на месте адреса хоста все биты выставляются в нули.

Широковещательный запрос — отправка пакета всем устройствам в сети. Для реализации такой рассылки назначается специальный широковещательный адрес: в IP-адрес после адреса сети (вместо адреса хоста) все биты выставляются в единицы.

Соответственно, максимально возможное количество хостов в сети вычисляется по формуле 2^(32-маска)-2. (Так как, когда вместо адреса хоста все нули — это адрес сети, а когда все единички — это широковещательный запрос, соответственно, теряем два адреса из всех вариантов)

Дополнительные сведения:

Маска /32 — указывает, что написан адрес одного и ровно 1 (одного) хоста

Маска /31 — используется для маршрутизации для соединения точка-точка, или если два адреса на один комп (это делается для экономии адресов и для сокращения количества записей о маршрутизации соответственно).

0.0.0.0/0 — весь интернет.

255.255.255.255 — широковещательный запрос всем в локальной сети. Используется обычно в случаях, когда хосту неизвестны настройки локальной сети.

Адреса, которые запрещены в сети интернет, или же «локальные» адреса, которые можно использовать для себя без ограничений (так называемые, «серые» адреса):

Для собственных локальных сетей:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

и

127.0.0.0/8 – loopback – адреса которые доступны только внутри одного хоста

Классификация сетей

A: 0-127/8

B: 128-191/16

C: 192-223/24

D: 224-239

В сети класса А 2^24-2 хостов в одной сети, в B - 2^16-2, в C – 256 -2=254 хоста.

Адреса класса D используются для многоадресной (multicast) передачи.

Остальные адреса на данный момент зарезервированы и не используются.

Стоит отметить, что ранее классы использовались для маршрутизации. Теперь же вся маршрутизация «бесклассовая» и классы сетей указываются только для указания размера сети (например, “сеть класса C” обозначает сеть с 256 адресами (с маской /24) (любую, даже 10.2.4.0/24!!))

Работаю в ИТ, периодически специалисты в филиалах уходят и требуется подобрать новых сисадминов. Подозреваю, что нас кроют последними словами те, кого мы собеседуем, вот хочется прояснить немного свою позицию.

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

Если вы не можете сказать, зачем нужна маска подсети, что такое «шлюз по умолчанию» и первый раз слышишь о таблице маршрутизации, то, честное слово, вы не справитесь. Вам ни о чем не скажут слова «у вас сеть такая_то/16 на филиал, по допофисам рулите сами», вы не поймете, почему нет доступа куда-то именно с этого компа и т.д.

Можно ли поднять в одной локальной сети 2 DHCP-сервера, обоснуйте ответ. Опять, «ну это теория, так то я подниму». Да-да, пройти мастер и нажать три раза «далее» и обезьяна сможет, не спорю. Но у тех, кто не может ответить на этот вопрос нет понимания, как работает DHCP. Именно у них идут конфликты IP-адресов, именно они не могут всем массово поменять DNS-сервер. Для них откровение, что можно передать ЕЩЁ какие-то настройки. А если, внезапно, нужно поднять DHCP не на винде и там нет мастера, который заботливо задаст вам все вопросы, то всё – тушите свет.

Обжим кабеля по цветам наизусть. Мы всё понимаем, век мобильного интернета и доступности информации (особенно, в отдаленном пункте на Ямале/Чукотке и т.д. *sarcasm*), но у вас в резюме «монтаж ЛВС/СКС» и опыт 2 года. Вы, извините, по листочку два года обжимали? 20 патчиков и вы никогда этого не забудете, проверено.

Камень преткновения. Хаб и свич. К сожалению, не догадались сразу записывать, а то бы можно было издать юмористический сборник «Отличие хаба от свича. 50 укуренных мыслей». Основной аргумент, что хаб – устаревшее оборудование и им никто не пользуется, потому и знать о нём не надо. И всё бы так, если бы кто-то из тех, кто приводит этот аргумент смог бы сформулировать, чем же всё-таки занимается свич (то есть, что он делает, как именно и нафига вообще нужен). Зачем?

- Я заблокировал ресурс А на роутере, а на него всё равно все мои пользователи попадают.

- Ресурс А находится в той же локальной сети, что и пользователи?

- Да

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

- Ну они ж по IP заходят

И начинаешь рассказывать человеку, как свич работает, что такое ARP-таблица и прочую «теорию».

Мы всё понимаем, любую информацию можно нагуглить. Но как человек предполагает этим заниматься, если не понимает, о чем идет речь? Гуглить «курс по сетям для чайников»? А почему почему бы не сделать это до собеседования? А я знаю, что будут делать в итоге – звонить мне и говорить «сломалось/настройте/не понимаю, сделайте». И никто так и не выяснит, нафига же айпишнику нужна маска…

Раньше у нас были лайтовые собеседования – вопросы из разряда «Знаешь это? –Знаю». и никакой конкретики, никакой «теории». Регулярные звонки из филиалов с элементарными вопросами. Админ даже локализовать проблему не может. И если вы думаете, что не было инструкций и лекций, то вы ошибаетесь. Есть и «мануал начинающего админа» и «трактат о сетях для самых начинающих». Просто их никто не читал (ё-моё, 15 страниц с картинками, где ж тут успеть!). Года два назад мы стали практиковать «жесткие» собеседования и сейчас стало натурально лучше. Народ может решить проблемы самостоятельно, иногда лучше/быстрее нас. И ещё одна закономерность: те, кто смог ответить на «теоретические» вопросы, читает мануалы и инструкции. Совпадение? Не думаю.

И да, мы не задираем планку там, где зарплата меньше средней в ИТ по региону. Но хоть немного ориентироваться в теме необходимо, чтобы мы не летали в этот регион в командировки каждые пару месяцев и не висели на телефоне с одними вами весь день. Просто десяток-полтора статей по теме можно же было прочитать за 5-10 лет админства, которые указаны у вас в резюме. Для ответа на 7 из 10 вопросов этого хватит, а 7 – это очень крутой показатель.

Надеюсь, что кому-то это прояснит ситуацию, кого-то сподвигнет прочитать тот самый десяток статей.

P.S.: пост по теме ИТ первый, будет ли еще – не знаю. Подозреваю, что сильный интерес тема не вызовет.

Нужно было сегодня протянуть навый патчкорд на объекте. Вот что мы увидели в распределительном шкафе.

Всего ужаса это фото не передает. Пилот, два двойника, пак РОЕ-инжекторов смотанных скотчем, куча коаксиалки и витаху торчащая во всех углах. А держится все это чуда на проводках и хамутах.

Иногда нужно настроить мониторинг каких-либо объектов на серверах, которые могут изменятся, например IIS сайты\пулы, размеры файлов, размеры кластерных дисков, базы данных и прочее. Для получения самих значений можно использовать встроннее метрики, например Performance Monitor в Windows Server, либо же скрипты\запросы, которые их получают.

Трудности доставляют сами изменяющиеся объекты, которые могут добавлятся\убираться, и каждый раз ручками конфигурировать итемы на хостах как-то не хочется. Вот тут нам поможет Low-level discovery (LLD).

К примеру у вас есть сервер, на котором крутятся сайты, которые ваши разработчки с некой переодичностью добавляют\удаляют. Задача мониторить количество коннекций к сайту, количество get/head/post запросов, статус апликейшн пулов (запущен или нет).

Поскольку я Виндовый админ, то будем использовать PowerShell, но по такому же принципу можно написать на любом языке.

И так для создания нового LLD нужен скрипт,а даже 2, которые будет получать список сайтов и список пулов, конвертировать его в JSON формат и предоставлять Заббиксу.

Выглядит готовый JSON так:

{

"data":[

{ "{#SITE}" : "site1" },

{ "{#SITE}" : "site2" },

{ "{#SITE}" : "site3" }

]

}

А потом уже заббикс для каждого из объектов будет получать данные параметров, для сайтов используя запоросы в Performance Monitor, для пулов - скрипт.

Получать список объектов можно любым скриптом, главное что бы заббикс агент его смог запустить.

И так создаём фаил с названием get-sites.ps1

Получаем список сайтов на сервере:

Import-Module WebAdministration

$sites = Get-ChildItem -Path IIS:\Sites -Name

Если вы тестите то для вывода результата введите $sites

Теперь весь список нужно представить в JSON формате, особенностью является то что в конце последнего значения объекта, не должна стоять запятая.

По этому вводим переменную $idx по которой мы будем проверять последний это объект или нет.

$idx = 1

Далее делаем шапку JSON:

write-host "{"

write-host " `"data`":[`n"

Далее будем каждый объект полученный ранее проверят последний он или нет.

Сверку будем проводить путем увеличения переменной $idx на 1, после создания каждого JSON объекта.

Если нет, то создаём JSON объект с запятой, если да, то создаём без запятой.

foreach ($currentsite in $sites) #каждый сайт из списка будет получать переменную $currentsite

{

if ($idx -lt $sites.count) #сравниваем $idx с количеством сайтов. -lt - меньше чем. Если получаем True то создаём строчку с запятой, если нет то двигаемся дальше.

{

$line= "{ `"{#SITE}`" : `"" + $currentsite + "`" }," # создание строчки с запятой

write-host $line

}

elseif ($idx -ge $site.count) # здесь опять сравниваем $idx с количеством с сайтов. -ge - больше или равно чем. Если True то создаём строчку без запятой

{

$line= "{ `"{#SITE}`" : `"" + $currentsite + "`" }" #строчка без запятой

write-host $line

}

$idx++; #В конце каждого прохода увеличиваем $idx на 1.

}

Ну и закрываем JSON.

write-host

write-host " ]"

write-host "}"

Логика проста: Получаем список сайтов, например 3 сайта. Значит нужно 3 прохода для создания 3 строчек для JSON.

Первый проход первый сайт. $idx=1. 1<3? Да. Создаём с запятой. Увеличиваем $idx на 1.

Второй проход второй сайт. $idx=2 . 2<3? Да. Создаём с запятой. Увеличиваем $idx на 1.

Третий проход третий сайт. $idx=3. 3<3? Нет. Идем дальше. 3>=3? Да. Создаём без запятой.

Таким же образом создаём скрипт get-apppool.ps1 для получения списка пулов:

Import-Module WebAdministration

$apppool = Get-ChildItem -Path IIS:\Apppools -Name

$idx = 1

write-host "{"

write-host " `"data`":[`n"

foreach ($currentapppool in $apppool)

{

if ($idx -lt $apppool.count)

{

$line= "{ `"{#APPPOOL}`" : `"" + $currentapppool + "`" },"

write-host $line

}

elseif ($idx -ge $apppool.count)

{

$line= "{ `"{#APPPOOL}`" : `"" + $currentapppool + "`" }"

write-host $line

}

$idx++;

}

write-host

write-host " ]"

write-host "}"

Далее оба скрипта кладем на сервер, например туда где стоит заббикс агент и в конфиг агента добавляем 2 юзер параметра:

UserParameter=apppool.discovery,powershell -NoProfile -ExecutionPolicy Bypass -File "C:\Program Files\Zabbix_agent\scripts\get-apppool.ps1"

UserParameter=site.discovery,powershell -NoProfile -ExecutionPolicy Bypass -File "C:\Program Files\Zabbix_agent\scripts\get_sites.ps1"

(Если честно, то не помню, нужно ли включать ActiveChecks и EnableRemoteCommands в конфиге. У меня везде включено.)

apppool.discovery и site.discovery - будут использиваться как ключи при создании LLD для запуска соответсвующих скриптов.

Далее в Заббиксе нашего сервера создаём новый дискавери:

Name: IIS Site #Название дискавери

Type: Zabbix agent #то чем будем делать дискавери

Key: site.discovery #ключ для вызова скрипта с получем списка сайтов. Мы его указали в UserParameter в конфиге агента на сервере

Host interface: айпишка и порт агент на сервере

Update interval (in sec): 3600 #как часто будем вызывать скрипт и получать список сайтов

Keep lost resources period (in days):3 #через сколько удалять сайтов, которых больше нет.

В фильтрах можно указать какие сайты исключить из списка.

Label Macro {#SITE} Regular expression @IIS

Сам список IIS создаётся в Administration > general > Regular Expresssions.

Например можно исключить Default Web Site для этого создаём список IIS и добавляем Expression type: Result is False; Expression: Default Web Site

Далее создаём прототипы айтемов в дискавери. Они практически ничем не будут отличаться от создания обычных айтемов. Только для объявления сайта используем {#SITE}

Например количество коннекций к IIS сайту. Данные получаем с Performance monitor:

Name: {#SITE}: Current connections

Type: Zabbix agent

Key: perf_counter[\Web Service({#SITE})\Current Connections]

Type of information: Numeric (unsigned)

Прежде чем создавать дискавеи для пулов, нужно создать скрипт, который будет получать статус пула.

Создаём PowerShell скрипт get-apppoolstate.ps1

param ([string] $name = 0)

Import-Module WebAdministration

$apppoolState = Get-WebAppPoolState -name "$name"

Write-Output ($apppoolState.value)

Сохраняем и кладем к агенту, туда куда и прошлые скрипты. Добавляем UserParameter в конфиг:

UserParameter=apppool.state[*],powershell -NoProfile -ExecutionPolicy Bypass -File "C:\Program Files\Zabbix_agent\scripts\get_apppoolstate.ps1" "$1"

apppool.state - ключ для вызова скрипта.

[*] - параметр который мы будем передавать вместе с ключем, в нашем случае имя пула

$1 означает что мы будем передавать имя пула в скрипт, внутри скрипта имя пула пойдет в параметр $name

Теперь создаём дискавери для мониторинга апликейшн пулов создаём новый дискавери.

Name: IIS AppPool

Type: Zabbix agent

Key: apppool.discovery

Остальное как для сайта.

Создаём прототип айтема:

Name:IIS AppPool {#APPPOOL} state

Type:Zabbix agent

Key:apppool.state[{#APPPOOL}]

Type of information: Text

Ну и все, дальше можно настроить триггеры для обоих дискавери.

Например что пул не запущен:

Name: IIS AppPool {#APPPOOL} is down

Severity: Disaster

Expression: {MyWebServer:apppool.state[{#APPPOOL}].str(Stopped)}<>0