Так, а вот это уже интереснее. Отвечу только на то что знаю, не залезая за ответами в документацию к оборудованию и в теорию в интернете - вы их с таким же успехом можете найти сами. Также учтите, что я могу ошибаться.
Отвечаю на ваши вопросы также по пунктам.
Шторм - это не петля. И петля - это не шторм. Петля - это катализатор шторма. И дело не в каком-то там шторме, а в самом количестве рассылаемых пакетов. Если их становится слишком много, и коммутаторы не успевают их обрабатывать - это шторм. Проблему можно решить при помощи ARP Proxy, но это тупая затея т.к. у нас появляется точка отказа, больше проблем, чем пользы.
Как раз то, о чем мы говорили. При использовании DHCP Snooping коммутатор проверяет каждый ARP-пакет. Узким местом может стать как сама таблица коммутации, так и CPU коммутатора (извините, выше ошибся, у сетевых портов же нет отдельных CPU, я имел ввиду их буферы).
2.1.-2.4. Я не понял, что именно вы хотели спросить. В любом случае лучше изучите вопрос сами. Вернемся к пунктам 1 и 2: вам ничего не поможет, если коммутаторам уже по 10-15 лет. Никакая технология не поможет вам нивелировать недостаток аппаратных мощностей. И это везде так, во всём. А теперь посмотрите на наше производство где L2/L3 коммутаторов суммарно свыше 120 единиц, из которых 8 ядер как раз на 326, потому что больше в магазинах ничего нормального под 40 Gb/s нет. Какая производительность у остальных, L2, говорить не приходится. Это как раз ответ на ваши вопросы: почему так? К чему такая спецоперация по удушению трафика? Потому что оборудования нового нет, вот почему. В машиностроении денег нет, это вам не офис газпрома. Большинству подобные проблемы не осознать, они не оперируют такими понятиями как кол-во портов на юнит или кол-во розеток по рабочей площади здания. Объём разный просто.
Да, это огромная проблема. Когда у вас количество узлов (сетевых карт) перевалит за 500, это станет заметно. ARP необходим для работы IPv4, его полностью убрать или сократить невозможно. Дело не в объёме трафика, он копеечный, дело в нагрузке на CPU сетевых портов коммутаторов и конечных устройств.
R(STP) это защита от петель, а не от широковещательного трафика, переход на IPv6 проблему на 90% решает, но использовать только его не представляется возможным, поэтому в случае IPv4 способ защиты только один - разделить сеть. Любой нормальный системный администратор это знает (хотя, честно признаюсь, мне тоже очень хотелось бы, чтобы вся сетевая инфраструктура была в одной сети, без VLAN, так её проще администрировать). У нас (не хочу присваивать себе работу других людей) она разбита по корпусам/зданиям, выше в статье описывал, по факту в каждом сегменте не более 1000 узлов. Есть ещё уникумы, которые хотели (начали делать, я это заметил, и их остановил) разделить по этажам или даже отделам, но это излишне, техника редко выходит за пределы своего здания, а вот между этажами прыгает только так. Вы можете документацию любого производителя сетевого оборудования почитать - практически все против того, чтобы в одном VLAN было более 500-1000 узлов (для IPv4), вне зависимости от типа устройства.
Те ваши специфичные устройства - это видимо хабы, их практически нигде не осталось. Ничего другого вспомнить не могу.
Защита от самозваного DHCP-сервера это уже другая проблема, и там их много на самом деле, всё зависит от размера сети, оборудования и применяемых технологий.
У Samba обновления выходят каждые полгода, версию 4.22 можно вполне считать полноценной. То, что когда-то давно были какие-то проблемы - может быть, не знаю. В Samba необходимо использовать утилиту samba-tool, dcdiag предназначен в первую очередь для DC на WS. К тому же, утилиты эти вам ничем не помогут, если вы не знаете теорию. Ошибаться и затем ругать утилиту за то, что она не может простыми словами объяснить вам ваши же косяки - я считаю, глупо. Знаю, потому что сам перестал пользоваться, т.к. люди совершают одни и те же ошибки. Давайте приведу два самых частых (с которыми сталкиваюсь я) примера.
Первый. При миграции забыли переназначить авторитетный DNS-сервер.
Второй. Я называю его "Остров дураков". Часто возникает при спонтанном добавлении ещё одного DC.
Большинства проблем можно заранее избежать, если просто читать теорию.
Я правильно понимаю, что вы отключили IPv6 на всех коммутаторах и маршрутизаторах? Как тогда узлы будут общаться по IPv6 между VLAN? По сути дела связи нет. И вот как раз приведу вам примеры. Тот же DA без IPv6 не работал, но я перевёл всё на AOVPN и эта проблема решилась сама собой. Samba DC не работает без IPv4. Помню ещё случай, когда на одних DC IPv6 был отключен, а на других - нет, это привело к полной остановке репликации. И на DNS записи AAAA при отключении IPv6 надо будет чистить.
Проверку на внимательность вы прошли, изучили вопрос, а не просто повторили. IPv4/IPv6 отключать нельзя, но можно выставить приоритет, ветка реестра та же. На некоторых предприятиях, к слову, служба безопасности принуждает отключать IPv6, и ещё smb 1-2 и т.д. Ну и ещё есть у нас категория специалистов, которые считают, что переход на IPv6 разом решит все проблемы и о них можно навсегда забыть (широковещательный трафик, нагрузка на сеть и CPU узлов и т.д.).
И вот ради этого оперативная память так подорожала? Нашли на что ресурсы и время тратить. Пусть тогда он вам статьи пишет, раз подобные комментарии вам больше нравятся.
Если вы про тот огромный комментарий выше, который человек написал в припадке - то да, только наоборот. Вы, кстати, уже второй человек, который посчитал, что он мой руководитель.
Я вас правильно понимаю, что начальники это добрые и нисколько не подлые люди, которые обязательно возьмут в случае полного П всю ответственность на себя? И они ни в коем случае не станут уничтожать свои же письменные приказы и переписки? Пока гром не грянет, мужик не перекрестится. Попробуйте начальника заставить своими руками тот же SQL Server развернуть, под видеозапись, и посмотрите какая будет реакция.
Автоматизировать абсолютно всё невозможно. Я только основные моменты указал, которые будут полезны всем. Надо им оно на практике и смогут ли они подобное внедрить - уже не моя проблема.
А у вас GPO и скрипты не бэкапятся разве? Есть ещё гей-нии, которые в sysvol хранят установщики. Проблема массовая, в книгах всё есть, но читать их никто не хочет.
Своя почта это не так просто, как многим кажется. Особенно учитывая средний уровень подготовки системных администраторов. В статье забыл отметить, что обращались организации с не более чем 200 ПЯ.
Два лица, в два раза больше проблем. Да и где гарантии, что письмо не будет удалено до того, как будет произведён бэкап.
Кто имеет доступ к локальному хранилищу и к облаку - опять вопрос.
Да, не мешает. Это к вопросу уровня квалификации штатных макак.
Есть проблемы, а есть затраты. Да, помогут, не спорю. Сам с таким работаю. Но у тамошних людей, как правило, нет ни малейшего представления обо всех "сюрпризах", которые ждут их, скажем, на более-менее крупных (в рамках города) заводах. А вот другой человек, который проработал ИТ-шником, скажем, лет 20-30, обо всех этих подводных камнях и особенностях знает. Но в целом для меня это просто перекладывание ответственности, всё что угодно придумают лишь бы штатным сотрудникам не платить.
С одной стороны согласен, а с другой - нет. Касательно теоретических вопросов. Достаточно лишь придумать задачу и спросить у человека, как бы он подошел к решению вопроса, и сразу станет понятно, человек инженер (то есть как минимум закрыл несколько нерешаемых задач, которые больше никто не осилил, с нуля, сам не имея никакого представления о них) или просто очередная макака-гуглилка.
Молодой конь (как меня поправил товарищ в комментарии выше - молодой олень) - это не приговор, это промежуточный этап. Вопрос в том, когда вы его преодолеете. Глупых вопросов не бывает, есть плохо сформулированные.
З.п. мне платит предприятие, а не начальник отдела из своего кармана. Начальнику отдела, к слову, тоже платит предприятие.
Я не королева, аз есмь Царь, и мне даже психиатр не поможет.
А то есть вы считаете, что опытный специалист должен просто взять и выдать все свои наработки за бесплатно чужим людям? Да, вы описали меня (отчасти, только с возрастом ошиблись). Да, я отсылаю людей читать документацию, вне зависимости от того, техник передо мной или начальник. Но только тех, кто её до этого не читал в принципе. No pain - no gain. И да, на физику мне плевать, это не моя зона ответственности, равно как и АРМ с пользователями, и много чего ещё. А в чём причина "недощелков"? Ваши кривые руки? Самые дешевые китайские кримперы и коннекторы? Вот сами пусть идут и исправляют. Не хотите слушать - ваше право. Каждому своё.
Про 4 года - как показывает практика, всё происходит в точности до наоборот. Я уже описывал это в предыдущей статье. Приходит грамотный спец, делает всё так как надо (не буквально всё, а какой-то набор сервисов), и оно так и остаётся на 10 лет, никто их не обновляет, не проверяет и даже не пытается разобраться, как оно работает и почему было организовано именно так. Все ваши идеи и опыт без преемственности будут забыты и пущены под нож, потому что начальнику так больше нравится, "удобнее" или просто из-за зависти. Остальное комментировать не буду.
Местное ИТ мне никогда возгласить не предлагали и не предложат, делаю что могу. Решения нет, человека не изменить. По поводу всего остального, что вы про меня думаете - это ваше мнение, которое я не разделяю. Каждому своё.
А где сахар? Нефть-газ и 1С? Сахар только там, где есть блат или невероятно высокие требования к образованию и опыту. Что в системном администрировании, что в разработке, что в проектировании, что в машиностроении - везде одно и то же. Как по мне ИТ-отрасль никогда не была сахаром и не будет.
С учетом того, что у нас на некоторых предприятиях руководителями отдела ИТ становятся 35-ти летние мальчики (со всеми вытекающими), - согласен.
Если руководитель проводит собеседование по типу "викторины" и спрашивает теорию - то это говорит только об очень низком уровне подготовки самого руководителя. Всё знать невозможно. Дело не в ответе, а в том, как человек отвечает и как подходит к решению вопроса.
Надо не только найти, но и сохранить, зафиксировать найденное решение где-либо у себя в базе знаний (почти у всех это Obsidian, GitLab и т.п., но лично у меня это просто файлы в облаке). Если брать мой случай - я не могу найти сходу ответ в интернете даже на половину вопросов, задачи гораздо более комплексные. У специалистов тех. поддержки или системных администраторов - наоборот, они сидят не закрывая вкладки с нейросетями. Честно, я пробовал. И если для них это готовый ответ, то для меня - лишь отправная точка в примерном направлении, и я всё равно прихожу к тому, что надо читать книги, документацию и смотреть всё на практике.
В голове хранить как раз-таки ничего не надо, это ошибка многих начинающих специалистов.
Про десятки тысяч часов вы явно загнули. Если спец грамотный, за 5 лет (как раз 10.000 часов) можно вылизать всю ИТ-инфраструктуру. Возможно, в разработке действительно так, а вот в системном администрировании - нет.
Про компромат - речь про карьеру начальника, а не личное. Как правило, действительно опасные люди никак себя не компрометируют, а вот всякие тявкающие тупорылые подстилашки - ещё как. И, собрав на них компромат, бояться их не надо. Если человеку не хватает ума понять границу, что следует фиксировать, а что нет - то пусть потом не жалуется.
Так, а вот это уже интереснее. Отвечу только на то что знаю, не залезая за ответами в документацию к оборудованию и в теорию в интернете - вы их с таким же успехом можете найти сами. Также учтите, что я могу ошибаться.
Отвечаю на ваши вопросы также по пунктам.
Шторм - это не петля. И петля - это не шторм. Петля - это катализатор шторма. И дело не в каком-то там шторме, а в самом количестве рассылаемых пакетов. Если их становится слишком много, и коммутаторы не успевают их обрабатывать - это шторм. Проблему можно решить при помощи ARP Proxy, но это тупая затея т.к. у нас появляется точка отказа, больше проблем, чем пользы.
Как раз то, о чем мы говорили. При использовании DHCP Snooping коммутатор проверяет каждый ARP-пакет. Узким местом может стать как сама таблица коммутации, так и CPU коммутатора (извините, выше ошибся, у сетевых портов же нет отдельных CPU, я имел ввиду их буферы).
2.1.-2.4. Я не понял, что именно вы хотели спросить. В любом случае лучше изучите вопрос сами. Вернемся к пунктам 1 и 2: вам ничего не поможет, если коммутаторам уже по 10-15 лет. Никакая технология не поможет вам нивелировать недостаток аппаратных мощностей. И это везде так, во всём. А теперь посмотрите на наше производство где L2/L3 коммутаторов суммарно свыше 120 единиц, из которых 8 ядер как раз на 326, потому что больше в магазинах ничего нормального под 40 Gb/s нет. Какая производительность у остальных, L2, говорить не приходится. Это как раз ответ на ваши вопросы: почему так? К чему такая спецоперация по удушению трафика? Потому что оборудования нового нет, вот почему. В машиностроении денег нет, это вам не офис газпрома. Большинству подобные проблемы не осознать, они не оперируют такими понятиями как кол-во портов на юнит или кол-во розеток по рабочей площади здания. Объём разный просто.
Спасибо за пояснение.
Да, это огромная проблема. Когда у вас количество узлов (сетевых карт) перевалит за 500, это станет заметно. ARP необходим для работы IPv4, его полностью убрать или сократить невозможно. Дело не в объёме трафика, он копеечный, дело в нагрузке на CPU сетевых портов коммутаторов и конечных устройств.
R(STP) это защита от петель, а не от широковещательного трафика, переход на IPv6 проблему на 90% решает, но использовать только его не представляется возможным, поэтому в случае IPv4 способ защиты только один - разделить сеть. Любой нормальный системный администратор это знает (хотя, честно признаюсь, мне тоже очень хотелось бы, чтобы вся сетевая инфраструктура была в одной сети, без VLAN, так её проще администрировать). У нас (не хочу присваивать себе работу других людей) она разбита по корпусам/зданиям, выше в статье описывал, по факту в каждом сегменте не более 1000 узлов. Есть ещё уникумы, которые хотели (начали делать, я это заметил, и их остановил) разделить по этажам или даже отделам, но это излишне, техника редко выходит за пределы своего здания, а вот между этажами прыгает только так. Вы можете документацию любого производителя сетевого оборудования почитать - практически все против того, чтобы в одном VLAN было более 500-1000 узлов (для IPv4), вне зависимости от типа устройства.
Те ваши специфичные устройства - это видимо хабы, их практически нигде не осталось. Ничего другого вспомнить не могу.
Защита от самозваного DHCP-сервера это уже другая проблема, и там их много на самом деле, всё зависит от размера сети, оборудования и применяемых технологий.
Спасибо за комментарий.
У Samba обновления выходят каждые полгода, версию 4.22 можно вполне считать полноценной. То, что когда-то давно были какие-то проблемы - может быть, не знаю. В Samba необходимо использовать утилиту samba-tool, dcdiag предназначен в первую очередь для DC на WS. К тому же, утилиты эти вам ничем не помогут, если вы не знаете теорию. Ошибаться и затем ругать утилиту за то, что она не может простыми словами объяснить вам ваши же косяки - я считаю, глупо. Знаю, потому что сам перестал пользоваться, т.к. люди совершают одни и те же ошибки. Давайте приведу два самых частых (с которыми сталкиваюсь я) примера.
Первый. При миграции забыли переназначить авторитетный DNS-сервер.
Второй. Я называю его "Остров дураков". Часто возникает при спонтанном добавлении ещё одного DC.
Большинства проблем можно заранее избежать, если просто читать теорию.
Я правильно понимаю, что вы отключили IPv6 на всех коммутаторах и маршрутизаторах? Как тогда узлы будут общаться по IPv6 между VLAN? По сути дела связи нет. И вот как раз приведу вам примеры. Тот же DA без IPv6 не работал, но я перевёл всё на AOVPN и эта проблема решилась сама собой. Samba DC не работает без IPv4. Помню ещё случай, когда на одних DC IPv6 был отключен, а на других - нет, это привело к полной остановке репликации. И на DNS записи AAAA при отключении IPv6 надо будет чистить.
Проверку на внимательность вы прошли, изучили вопрос, а не просто повторили. IPv4/IPv6 отключать нельзя, но можно выставить приоритет, ветка реестра та же. На некоторых предприятиях, к слову, служба безопасности принуждает отключать IPv6, и ещё smb 1-2 и т.д. Ну и ещё есть у нас категория специалистов, которые считают, что переход на IPv6 разом решит все проблемы и о них можно навсегда забыть (широковещательный трафик, нагрузка на сеть и CPU узлов и т.д.).
И вот ради этого оперативная память так подорожала? Нашли на что ресурсы и время тратить. Пусть тогда он вам статьи пишет, раз подобные комментарии вам больше нравятся.
Если вы про тот огромный комментарий выше, который человек написал в припадке - то да, только наоборот. Вы, кстати, уже второй человек, который посчитал, что он мой руководитель.
Да, в одном, к сожалению.
Я вас правильно понимаю, что начальники это добрые и нисколько не подлые люди, которые обязательно возьмут в случае полного П всю ответственность на себя? И они ни в коем случае не станут уничтожать свои же письменные приказы и переписки? Пока гром не грянет, мужик не перекрестится. Попробуйте начальника заставить своими руками тот же SQL Server развернуть, под видеозапись, и посмотрите какая будет реакция.
Автоматизировать абсолютно всё невозможно. Я только основные моменты указал, которые будут полезны всем. Надо им оно на практике и смогут ли они подобное внедрить - уже не моя проблема.
А у вас GPO и скрипты не бэкапятся разве? Есть ещё гей-нии, которые в sysvol хранят установщики. Проблема массовая, в книгах всё есть, но читать их никто не хочет.
Своя почта это не так просто, как многим кажется. Особенно учитывая средний уровень подготовки системных администраторов. В статье забыл отметить, что обращались организации с не более чем 200 ПЯ.
Два лица, в два раза больше проблем. Да и где гарантии, что письмо не будет удалено до того, как будет произведён бэкап.
Кто имеет доступ к локальному хранилищу и к облаку - опять вопрос.
Да, не мешает. Это к вопросу уровня квалификации штатных макак.
Есть проблемы, а есть затраты. Да, помогут, не спорю. Сам с таким работаю. Но у тамошних людей, как правило, нет ни малейшего представления обо всех "сюрпризах", которые ждут их, скажем, на более-менее крупных (в рамках города) заводах. А вот другой человек, который проработал ИТ-шником, скажем, лет 20-30, обо всех этих подводных камнях и особенностях знает. Но в целом для меня это просто перекладывание ответственности, всё что угодно придумают лишь бы штатным сотрудникам не платить.
С одной стороны согласен, а с другой - нет. Касательно теоретических вопросов. Достаточно лишь придумать задачу и спросить у человека, как бы он подошел к решению вопроса, и сразу станет понятно, человек инженер (то есть как минимум закрыл несколько нерешаемых задач, которые больше никто не осилил, с нуля, сам не имея никакого представления о них) или просто очередная макака-гуглилка.
Молодой конь (как меня поправил товарищ в комментарии выше - молодой олень) - это не приговор, это промежуточный этап. Вопрос в том, когда вы его преодолеете. Глупых вопросов не бывает, есть плохо сформулированные.
З.п. мне платит предприятие, а не начальник отдела из своего кармана. Начальнику отдела, к слову, тоже платит предприятие.
Я не королева, аз есмь Царь, и мне даже психиатр не поможет.
Не читайте. Уверен, есть много других статей, которые вам понравятся.
Спасибо за ваш комментарий. Какие темы на ваш взгляд являются сомнительными?
А то есть вы считаете, что опытный специалист должен просто взять и выдать все свои наработки за бесплатно чужим людям? Да, вы описали меня (отчасти, только с возрастом ошиблись). Да, я отсылаю людей читать документацию, вне зависимости от того, техник передо мной или начальник. Но только тех, кто её до этого не читал в принципе. No pain - no gain. И да, на физику мне плевать, это не моя зона ответственности, равно как и АРМ с пользователями, и много чего ещё. А в чём причина "недощелков"? Ваши кривые руки? Самые дешевые китайские кримперы и коннекторы? Вот сами пусть идут и исправляют. Не хотите слушать - ваше право. Каждому своё.
Про 4 года - как показывает практика, всё происходит в точности до наоборот. Я уже описывал это в предыдущей статье. Приходит грамотный спец, делает всё так как надо (не буквально всё, а какой-то набор сервисов), и оно так и остаётся на 10 лет, никто их не обновляет, не проверяет и даже не пытается разобраться, как оно работает и почему было организовано именно так. Все ваши идеи и опыт без преемственности будут забыты и пущены под нож, потому что начальнику так больше нравится, "удобнее" или просто из-за зависти. Остальное комментировать не буду.
Местное ИТ мне никогда возгласить не предлагали и не предложат, делаю что могу. Решения нет, человека не изменить. По поводу всего остального, что вы про меня думаете - это ваше мнение, которое я не разделяю. Каждому своё.
А где сахар? Нефть-газ и 1С? Сахар только там, где есть блат или невероятно высокие требования к образованию и опыту. Что в системном администрировании, что в разработке, что в проектировании, что в машиностроении - везде одно и то же. Как по мне ИТ-отрасль никогда не была сахаром и не будет.
С учетом того, что у нас на некоторых предприятиях руководителями отдела ИТ становятся 35-ти летние мальчики (со всеми вытекающими), - согласен.
Если руководитель проводит собеседование по типу "викторины" и спрашивает теорию - то это говорит только об очень низком уровне подготовки самого руководителя. Всё знать невозможно. Дело не в ответе, а в том, как человек отвечает и как подходит к решению вопроса.
Надо не только найти, но и сохранить, зафиксировать найденное решение где-либо у себя в базе знаний (почти у всех это Obsidian, GitLab и т.п., но лично у меня это просто файлы в облаке). Если брать мой случай - я не могу найти сходу ответ в интернете даже на половину вопросов, задачи гораздо более комплексные. У специалистов тех. поддержки или системных администраторов - наоборот, они сидят не закрывая вкладки с нейросетями. Честно, я пробовал. И если для них это готовый ответ, то для меня - лишь отправная точка в примерном направлении, и я всё равно прихожу к тому, что надо читать книги, документацию и смотреть всё на практике.
В голове хранить как раз-таки ничего не надо, это ошибка многих начинающих специалистов.
Не верьте ему.
Про десятки тысяч часов вы явно загнули. Если спец грамотный, за 5 лет (как раз 10.000 часов) можно вылизать всю ИТ-инфраструктуру. Возможно, в разработке действительно так, а вот в системном администрировании - нет.
Про компромат - речь про карьеру начальника, а не личное. Как правило, действительно опасные люди никак себя не компрометируют, а вот всякие тявкающие тупорылые подстилашки - ещё как. И, собрав на них компромат, бояться их не надо. Если человеку не хватает ума понять границу, что следует фиксировать, а что нет - то пусть потом не жалуется.