HeroFromEarth: на соответствующем хосте, в конфиге заббикс-агента на котором есть такая строчка, добавляется параметр, где в поле key нужно указать то самое name из конфига. Соответственно, значение для этого key будет получаться как результат выполнения вашей command. Графики -- ну как обычно, для любого другого параметра в заббикс.
HeroFromEarth: Н-да, про винду -- это я где-то в другом месте прочитал, видимо :-) Ну в любом случае, ответ про userparameters и zabbix_trapper остаются актуальными независимо от операционки. Мы вот так считаем число пользовательских сессий на BRAS'ах, например (строчка из конфига заббикс-агента):
azsx: блин, ну вам самому не смешно? "данные и конфиги". Как вы это будете сохранять? У вас кластер на 3 хостах из MS SQL, ещё один кластер -- MySQL, и ещё два хоста с Oracle. Вы планируете каждому индивидуально выпиливать скрипт, который будет бэкапить "конфиги и данные"? ОК, допустим. А если у вас хостов в разных конфигурациях -- десятки? А если они ещё и добавляются/удаляются периодически, как в девелоперских проектах? Вам больше ни на что времени не хватит, кроме как на написание "скриптиков на баш" :-)
Ну и чтобы окончательно добить вопрос -- теперь представьте, что вам нужно бэкапить виндовое окружение :-) Контроллеры домена, Exchange, Sharepoint. Что будет делать "скриптик на баш" в этом случае? Какие конфиги и какие данные сохранять?
azsx: а вы знаете какие-то более лучшие способы бэкапа виртуалок в промышленных количествах, кроме "снапшота всей ВМ"? Поделитесь с общественность, а то мы тут не в курсе.
БД -- это только один из примеров. А если это сервер приложений? А если это сборщик логов со всей инфраструктуры? А почтовый сервер с миллионом сообщений на диске и с потоком в сотни новых писем в сутки? Что в этом случае будет делать ваш "скриптик на баш"?
azsx: товарищ, снапшоты, с которых потом делается бэкап и которые после бэкапа удаляются -- это главный сценарий резервного копирования виртуалок в текущий исторический момент. Вы не думали, что выключать банковскую базу, чтобы её сбэкапить путём "копирования файлика в mc" -- это трэш и угар. А теперь представьте, что таких "баз" у вас десятки. А теперь представьте, что их -- сотни :-)
А что делал бы ваш скрипт на баш? Выключал виртуалку, и копировал файл её виртуального диска? А если диск -- на терабайт, и вам нужно хранить историю бэкапов за месяц? На сколько копий хватит вашего бэкапного хранилища, чтобы всё это уложить?
На VMware и Hyper-V производительность виртуалки на снапшоте, разумеется, снижается, но не в разы, а на проценты. Если на KVM оно реально снижается в разы, то... Учитывая всё-таки популярность KVM, наверное, следует сделать вывод, что вы его просто что-то не так делаете :-)
Hyper-V Server -- бесплатный. От слова "совсем". Это специальная редакция Win server, в core-режиме и с одной только ролью -- Hyper-V. Хотя кое-какой виндовый софт на ней крутить можно, по крайней мере, BOINC я там запускал :-)
alnabi: если у вас в сети нет интернета, то допустимо указать эту Win7 в качестве шлюза по умолчанию. А если интернет есть, и его нужно доставлять до рабочих станций, и при этом интернет раздаётся не с этой самой win7, про которую вы спрашиваете, то шлюзом по умолчанию нужно ставить то устройство, которое раздаёт интернет, а на клиентах либо прописывать статику, как я выше написал, либо на интернет-устройстве решать задачу маршрутизации не только интернет-трафика, но и между вашими подсетями, путём прописывания соответствующих маршрутов на нём.
neals: Сервачок -- любой, который потянет ваш бюджет :-) На шасси SuperMicro сервера делает STSS (мы просто с ними работаем, поэтому я в курсе их оборудования). В принципе, можно поискать то же самое среди других отечественных сборщиков -- уже перечисленных Aquarius, Kraftway. При желании заморочиться -- можно собрать всё самостоятельно, но это много возни и никакой гарантии/тех-поддержки на всё устройство целиком, только на отдельные компоненты.
Вот тут можете попробовать повыбирать: stss.ru/products/servers/S-series.html Там нормальный конфигуратор, и сразу можно цену получить. Понятно, что грамотно торгуясь с менеджером, эту цену потом можно несколько снизить :-)
Ну и многое будет зависеть от дисковых объёмов, которые вам нужны, и нагрузок на них. Если нагрузка велика -- стоит взять диски объёмом поменьше, но количеством побольше, и собирать из них длинный RAID10 (из 4-8 пар дисков). Если нужны объёмы -- тогда диски бОльшего объёма, но меньшим количеством, и в RAID5/RAIDZ/RAID50. Если нужно и то и другое -- возможно, стоит рассмотреть вариант двух серверов с корзинками поменьше. Либо один сервак с корзинкой побольше, но нужно учитывать такой тонкий момент -- в корзине крайне желательно ставить одинаковые диски. Массивы из них вы можете собирать как угодно и в каком нужно количестве, но сами физические диски желательно должны быть одинаковые. Связано это с тем, что диски разных типов (и особенно разных скоростей вращения) вибрируют по-разному, и взаимные биения в корпусе могут значительно просадить производительность дисковой подсистемы, так как на позиционирование головок будет уходить заметно больше времени. Вот тут прикольное видео на эту тему, как даже громкий звук может негативно влиять на работу дисковых полок: https://www.youtube.com/watch?v=tDacjrSCeq4 :-)
Также рассчитывайте дублирование сети, для multipath'a и отказоустойчивости. Т. е. это как минимум 4-х портовые сетевухи в гипервизорах (по два порта на сеть и на storage-трафик), и 2 порта в storage-сервере, ну и два коммутатора.
FreeNAS в своей базе имеет ту же самую FreeBSD + ZFS, но я работаю только с фрёй, поэтому не знаю, насколько реализуем iSCSI multipath на FreeNAS'е, я просто фринасом не пользовался никогда.
Дмитрий: конечно, есть. впишите туда что-нибудь отличное от 1000 -- вот вам и не default :-)
Вообще же, чисто по логике, не должно быть совсем никакой разницы, 1 там IOPS, 1000 или 10000. Каналы обычно симметричные в таких случаях, и мне лично непонятно вообще, почему это так влияет на производительность.
Ну точнее, в случае хранилок всё понятно. Там вообще RoundRobin использовать не рекомендуется, по логике работы системы с двумя контроллерами. Но в случае самосбора или Nexenta Community Edition (без кластеризации хранилища) производительность вообще меняться не должна в зависимости от канала.
Дмитрий: А "свои" значения -- это какие? Многие вендоры в своих методичках рекомендуют ставить в Round-Robin не 1000, а 1 IOPS на канал. По крайней мере, я такое читал у HP и у IBM в руководствах к хранилкам. Но там никакого объяснения нет, почему это нужно делать. По этому поводу Дункан Эппинг однажды написал статью ( www.yellow-bricks.com/2010/03/30/whats-the-point-o... ), где заявлял, что "не вижу решительно ни одной причины, почему нужно дефолтное значение в 1000 IOPS на один path менять на что-то другое". Он там результаты тестов приводит, что ничего особо не меняется, если 1000 поменять на 1. Но дело было давно, статья 2010 года.
На практике же получается, что с дефолтным значением производительность страдает. По крайней мере, в некоторых сценариях.
Иван: Ну, можете на меня посмотреть :-) Я работал и с виндой, и с фрёй одновременно. Сейчас больше фря, конечно, но это специфика конкретного места работы. Буду работать в другом месте -- возможно, там винды будет гораздо больше юниксов :-)
А инфраструктура должна быть на том, что лучше подходит для конкретных задач.
Кстати, Storage Spaces и Scale-Out File server -- это виндовые технологии, и тоже вполне ничего себе штуки. Единственный косяк -- ESXi не сможет ими пользоваться в полном объёме :-) Если бы у вас гипервизоры были на Hyper-V, тогда да -- там можно виртуалки складывать на SMB3-шарах, и получать все прелести как Storage Spaces, так и SOFS. А на ESXi-ах -- только Storage Spaces по NFS-шарам.
Иван: Вот заодно и разберётесь :-) Логика у фри куда как более прозрачная, чем у линуксов.
На самом деле, каких-то системно-специфичных вещей при решении вашей задачи там не будет. Нужно будет немножко почитать про ZFS, про типы дисковых пулов (mirror, raidz/raidz2/raidz3) и ZVOL'ы.
iSCSI-target на фре реализуется с помощью утилиты ctld. Конфиг ctld -- около 15 строчек, большинство из них можно брать прямо из примера в FreeBSD handbook.
СХД, кстати (если под СХД понимать именно СХД, а не те базовые девайсы, которые предлагает QNAP/Synology/D-link) -- штука ни фига не проще FreeBSD. Все эти вещи -- компрессия на лету, дедупликация, снапшоты, зеркалирование на уровне томов, зеркалирование на уровне отдельных СХД, volume virtualization -- чтобы всё это вкурить, нужно тоже потратить порядком времени. Ситуация усугубляется тем, что документацию ещё придётся поискать, так как, например, у IBM по хранилке v7000 чуть ли не с десяток довольно толстых книг (порядка 500-600 страниц), и какая из них начинает объяснений всей этой фигни с азов -- можно выяснить только ознакомившись с большинством из них :-)
И маркетингового трэша там вагоны, когда одни и те же вещи, которые имеют, в общем-то, устоявшиеся названия, в документации к разным СХД называются по-разному. У одного вендора, например, слово volume означает одно, у другого производителя это же слово будет означать совсем другое. И только после вдумчивого курения документации от железок разных вендоров можно, например, понять, что то, что IBM называет "flashcopy", а Хуавей -- "hypersnap" -- это одно и тоже, это технология снапшотов.
Так что какое бы решение вы не приняли -- покупать СХД или делать всё самому на базе FreeBSD+ZFS -- на ознакомление с технологией придётся потратить порядочно времени.
Если у вас три хоста с ESX, и в каждом уже есть диски -- рассмотрите варианты использования софтверных СХД для построения конвергентного решения -- т.е. когда у вас хосты являются и гипервизорами и одновременно распределённым хранилищем с резервированием информации. Как вариант -- EMC ScaleIO, оно представляет собой набор виртуальных машин (по одной на каждый хост) и специальный драйвер для ESXi, который умеет работать с хранилищем ScaleIO. После его установки ESXi начинает видеть хранилище как FC LUN. Но там есть косячок -- по сути, суммарный объём хранилища в вашем случае надо делить на три :-) Т. е. если у вас 3 сервера, и на каждом дисков в сумме на 1 Тб (т.е. всего 3 Тб), то в ScaleIO вы получите всего 1Тб пространства. Но зато это будет реально надёжное хранилище, и при выходе из строя одного хоста данные не будут потеряны, и это будет ОБЩЕЕ хранилище, т.е. все хосты будут видеть все виртуальные машины.
Karmashkin: история команд -- это комплекс шагов, которые привели сервер к его текущему состоянию. Т.е. тому, к которому злоумышленник уже получил доступ. Зачем ему история? Знаете какие-либо реальные сценарии, когда история команд помогла с развитием взлома? К тому же, чтобы полную историю команд вести -- это надо специфично настраивать сервак, а просто включенный аудит показывает только исполняемые файлы.
Karmashkin: То, что они трутся -- это не проблема, если у вас настроено централизованное логирование на отдельный syslog-сервер :-) А то, что их можно анализировать... Если злодей уже получил доступ к серверу -- что ему с тех логов?
