Как же надоело читать про "собственные технологии виртуализации". Ну напишите уже прямо, взяли за основу фришный xen, proxmox или что-то подобное. Но нет, "используют окружность собственной разработки"!
Здесь вы доверяете выполнению GP, в статье - нет (и это одна из причин, почему вы от неё отказались, хотя есть ивент состояния применения политики - что мешает отслеживать?). Как отслеживание выполнение? По логам в шаре?
Конфликты гарантированно были, иначе не пришлось бы ничего биндить. Оборудование отвечало не "первее", а гарантированно по нужным портам тк flood с входящего аплинка был прибит. а пересылка внутри сегмента - только на один порт. Как видите, никаких чудес.
У меня так год стойка работала. С преднастроенными IP, биндом маков на портах коммутатора и мне было похрен на внешнюю адресацию ЗА пределами свитча. Единственное условие - уникальный IP шлюза во внешней сети. Видеосервер на него-таки должен был выходить.
Да, подзабыл уже малость. Спасибо что поправили, CAM-таблица. В которой мы прибиваем маки к портам. Сути не меняет. Работает железно в любой сети с идентичным IP адресами.
Вот интересно, наступит ли когда-нибудь эпоха, когда русские люди, говорящие на русском языке в своих постах на русском форуме перестанут ссылаться на зарубежные ресурсы? Понимаю, далеко не все обучение есть в ру-сегменте, но описаниеи диздока, это какое-то сокровенное знание, доступное только за рубежом?
Если через зад система создана, api документацию никто не пишет/читает, то так и появляются подобные опусы "заявка может теряться (?) на стыках". В иных случаях существуют коды возврата.
Никсы разных версий бывают. Иногда и руками приходиться поднимать. Чаще всего проблема сервиса внутри потока отдельного процесса ВМ связана с выделением ресурсов. При этом сервис остаётся формально в рабочем состоянии. Решает даже не мониторинг статуса, а периодический рестарт сервиса.
Выполнение кастомных скриптов требует некоторого понимания 'что и под кем', иначе возникнут проблемы другого уровня. Все это требует квалификации - откуда она возьмется в смол-сегменте?
В данной организации - ничего. Zabbix предполагает наличие оператора, который, хоть как-то реагирует на сообщения в даш/почту. Решения "сервер перегрелся я его включаю" принимаются после анализа ipmi и согласования с отделами.
Как же надоело читать про "собственные технологии виртуализации". Ну напишите уже прямо, взяли за основу фришный xen, proxmox или что-то подобное. Но нет, "используют окружность собственной разработки"!
Сразу видно, что у человека времени нет, такой Лонг накатать. Да ещё и "проблемы в индустрии" решать собрался.
Здесь вы доверяете выполнению GP, в статье - нет (и это одна из причин, почему вы от неё отказались, хотя есть ивент состояния применения политики - что мешает отслеживать?). Как отслеживание выполнение? По логам в шаре?
Так есть арпы в коммутаторах или нет? :-D Судя по списку DNS сейчас в управляемых L2/L3 - 120 к 60 примерно.
Чтобы случился "конфликт" конечное устройство должно получить арп.
Конфликты гарантированно были, иначе не пришлось бы ничего биндить. Оборудование отвечало не "первее", а гарантированно по нужным портам тк flood с входящего аплинка был прибит. а пересылка внутри сегмента - только на один порт. Как видите, никаких чудес.
У меня так год стойка работала. С преднастроенными IP, биндом маков на портах коммутатора и мне было похрен на внешнюю адресацию ЗА пределами свитча. Единственное условие - уникальный IP шлюза во внешней сети. Видеосервер на него-таки должен был выходить.
Да, подзабыл уже малость. Спасибо что поправили, CAM-таблица. В которой мы прибиваем маки к портам. Сути не меняет. Работает железно в любой сети с идентичным IP адресами.
-
Даже на самых простых управляемых есть таблица ARP. Этого достаточно, чтобы устройства в сегменте точно знали на каком порту каждый IP адрес.
Чтобы в стойке были доступны устройства при конфликте IP снаружи достаточно прибить арпы на управляемом коммутаторе.
Вот интересно, наступит ли когда-нибудь эпоха, когда русские люди, говорящие на русском языке в своих постах на русском форуме перестанут ссылаться на зарубежные ресурсы? Понимаю, далеко не все обучение есть в ру-сегменте, но описаниеи диздока, это какое-то сокровенное знание, доступное только за рубежом?
Прям череда откровений. А какой охват аудитории!
Как я понимаю, текст-ради-текста? Свежо.
Если через зад система создана, api документацию никто не пишет/читает, то так и появляются подобные опусы "заявка может теряться (?) на стыках". В иных случаях существуют коды возврата.
Разрядность шины - это как раз линейное увеличение псп. А частота - фейковое (маркетинговый ход).
Так платят же.
Никсы разных версий бывают. Иногда и руками приходиться поднимать. Чаще всего проблема сервиса внутри потока отдельного процесса ВМ связана с выделением ресурсов. При этом сервис остаётся формально в рабочем состоянии. Решает даже не мониторинг статуса, а периодический рестарт сервиса.
Выполнение кастомных скриптов требует некоторого понимания 'что и под кем', иначе возникнут проблемы другого уровня. Все это требует квалификации - откуда она возьмется в смол-сегменте?
В данной организации - ничего. Zabbix предполагает наличие оператора, который, хоть как-то реагирует на сообщения в даш/почту. Решения "сервер перегрелся я его включаю" принимаются после анализа ipmi и согласования с отделами.