Антон Уланов: динамическая раздача IP-адресов на серверах и всём, что с ними (серверами) связано -- это вообще плохая практика. Исключением являются только большие системы, в которых необходимо быстро горизонтально масштабироваться (путём добавления новых узлов в кластер (виртуализация/storage/computing/что-нибудь-ещё)).
Похоже, что конкретно эта хранилка -- только с FC-портами, ethernet-портов для storage-трафика там нет. Так что в Ethernet её втыкать нет смысла. Чтобы задействовать эту хранилку, вам нужны FiberChannel-адаптеры в хостах. В теории, их можно напрямую подключить к портам хранилки. И разумеется, нужны будут не ethernet, а FC модули SFP+.
Посмотрите в документации на хранилку, поддерживает ли она прямое подключение хостов к FC-адаптерам (90% вероятности, что таки да, но бывают и такие варианты хранилок, что подключить можно только в FC-коммутатор).
Ну и тогда нужно будет хосты укомплековать FC-адаптерами, воткнуть везде FC SFP+ модули и соединить их соответствующими оптическими патч-кордами ;-)
John Smith: Оно при определённых файловых операциях диалог открывает. Например, синхронизация базы в KeePass, или импорт ключа в puttygen. Так что там не в папке дело, оно реагирует на определённые вызовы API.
Андрей Ермаченок: разные подсети -- это логично и правильно. Сегментация сети позволяет более точно разграничивать доступ и уменьшать периметр атаки при компрометации отдельного сегмента.
Не потянут они сервак, даже от супермикро. Ты ж посмотри, какие вопросы человек задаёт. Там чихнёт любой компонент -- и они встрянут с заменой. Есть саппорт, конечно, но 56 тыс. рублей даже супермикру не купить. Только если Б/У, а кому она нужна без саппорта?
SyavaSyava: А в чём проблема-то? Заббикс умеет напрямую с SNMP работать. На винде ставишь SNMP service, и/или какой-нибудь пак от вендора сервера, и получаешь всю красоту.
Есть чудо-программка OIDVIEW, которую можно натравить на сервер, и посмотреть, что он в итоге отдаёт. Выбрать нужные OID'ы, и зарядить в Zabbix.
А как быть с 66 подсетями? Нужно на обоих серверах задать одинаковую конфигурацию, в которой указывать в качестве адреса шлюза - общий адрес, поддерживаемый CARP?
Вопрос не понял. У вас статическая маршрутизация на 66 сетей?
У вас CARP IP должен только клиентам отдаваться, в качестве шлюза по умолчанию. А если у вас там где-то ещё маршрутизаторы в другие сети, то с ними лучше по протоколам динамической маршрутизации работать. И для этой цели ваши сервера должны иметь разные IP.
А что такое "работа CARP по VLAN"? :-) Я в приведённом вами конфиге VLAN-интерфейса не вижу :-)
Алексей Белый: В том, что файловая система вносит свой оверхэд в работу свопа. А ещё в том, что не на всякие файловые системы может быть записан аварийный дамп.
Adamos: Я в курсе, чем чревато залезание в своп :-) Похоже, у вас просто нагрузок больших нет, поэтому вы можете обойтись без свопа.
Своп нужен для двух вещей -- компенсировать внезапный рост потребления памяти сервисами, и для заливки туда аварийных дампов, если ядро вдруг запаникует. Если у вас нет свопа -- ваш сервер встанет при неожиданном всплеске нагрузке, так как OOM killer чикаться с сервисами не будет. Ну и в случае паники ядра придётся ходить длинным путём -- сначала ДЕЛАТЬ СВОП :-), а потом пытаться повторить ситуацию с паникой. Ну, или ждать, пока она повторится. Так нафиг это надо, если можно сразу заложиться на своп?
alexander sm1ly: Ну значит, у вас просто нагрузок никаких приличных нет. А я вот периодически вижу, как один из кластеров виртуализации упирается в полку по памяти. И тогда гипервизору ничего не остаётся, кроме как сбрасывать машины в свой. Да, они тупят. Но они работают.
xmoonlight: Типа, в юниксах не бывает уязвимостей. В одном только OpenSSH за последние годы кучу критический уязвимостей нашли. Которые там сидели много лет до обнаружения. Это к вопросу, что "в открытом ПО проще искать баги".
xmoonlight: юникс ещё не готов к внедрению в крупные корпоративные сети. И неизвестно, будет ли готов. Некоторые инфраструктурные сервисы на нём можно делать, но не все (AD, Exchange -- заменителей полнофункциональных им нет). А для рабочих станций линух сотоварищи ещё меньше подходят. Так что, по большому счёту, выбора нет -- надо патчить винды :-)
xmoonlight: да этим прохладным историям уже столько же лет, сколько существует опенсорс :-) Но что-то взрывного роста использования опенсорсных продуктов не наблюдается :-) Какую-то долю рынка они заняли, конечно, но проприетарное ПО никуда не делось.
И вместо массового перехода на линукс после того же wannacry народ просто стал патчить винды :-)