athacker

Поддерживаю ораторов выше -- бодаться и доказывать бесполезно. Клиент собрался кинуть на деньги, его тут ничего не остановит.

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

В принципе, заявлений про "90-е" -- уже вполне достаточно, чтобы лично моя совесть отвернулась в сторонку на время совершения описанных выше мероприятий.

Нескромный вопрос -- а вы логи читать пробовали? :-) Там ведь все этапы прохождения письма по инстанциям отражаются. Вот и смотрите, где что тупит.

Ну, сами подумайте, что бы вы ответили человеку, который заявляет: хочу промышленную СХД с обвязкой (коммутаторы) и дисками собрать на коленке, бюджет на всё в миллион рублей (~17000$).

Тут уж, дорогой друг, либо коленки, либо промышленная СХД (особенно учитывая хотелки в виде тиринга, дедупликации, снапшотов и прочего).

1) SATA-диски под большой нагрузкой будут грешить silent errors (т.е. искажениями данных, которые никто не заметит, пока не будет поздно (например, при ребилде массива). Поэтому софт должен будет уметь эти ошибки выявлять в оффлайне (как scrub в ZFS или background device scanner у ScaleIO).

2) Цены на "деревянные" (что бы это не означало) СХД в интернетах таки есть. Например, тут: stss.ru/products.html

3) Если собираетесь покупать ScaleIO, то там адекватных денег не ждите. Запрашивали несколько месяцев назад цены -- 44k$ за 50 Тб СЫРОЙ ёмкости. Когда соберёте массив на 4-х нодах, получите меньше 20 Тб реальной ёмкости. ScaleIO можно юзать и за так, но про поддержку забудьте. Если у вас реально суровый прод, то без поддержки -- это искать прилючения на свои нижне-задне-спинные мышцы.

4) Дедупликация-то вам нахрена? Учитывая массив данных, который вы собираетесь там хранить (документы/фотки/видео), профит от дедупликации будет чуть меньше, чем никакого, а вот нагрузка на память и потенциальные глюки будут ого-го.

Сдаётся мне, что во всём виноват SMB3. Очевидно, что все клиентские винды (7,8,10) могут являться SMB3-клиентами. Возможно, 10-ка умеет быть и SMB3-сервером. А SMB3 включает в себя и такую фичу как:

Multichannel - aggregation of network bandwidth and fault tolerance if multiple paths are available between client and server

Возможно, когда линков несколько и они разные по скорости, то возникают какие-то трудности синхронизации этих нескольких потоков передачи, и соответственно, скорость падает до скорости самого медленного из каналов.

Никак. Вы можете выгрузить только список компьютеров, которые имеют учётки в AD. При этом статус этих компов (особенно "выключен") не сможете определить никак. Как вы себе представляете? Комп выключен, но при этом каким-то чудом сигнализирует в сеть: "чуваки, я выключен, меня не будить!"? :-)

В сети могут быть компы, не входящие в домен. Могут быть компы, где пинги закрыты файрволом. IP-адрес по дефолту микрософтовским DHCP выдаётся на 8 дней. Человек придёт из отпуска, включит комп, и комп получит уже другой IP.

zamboga: копии БД бинарные или текстовые? Если бинарные -- дельту изменений вы видеть там не будете. Если текстовые -- то есть шанс. Но надо понимать, что дамп БД, даже в текстовом виде -- это не конфиги и не исходники, и даже не текстовый документ, так что при определёных условиях у любых системы контроля версий может ехать крыша (например, почему-то поменяется порядок сортировки таблиц при выгрузке в дамп), и тогда дельты тоже не будет. Точнее, технически она будет, конечно, но будет абсолютно бесполезна.

А комментарии к версии, конечно, работать при этом будут.

В кавычки текст с пробелами заключить?

www.etronik.ru/scalemp-arxitektura-vsmp

man на предмет командлета Get-EventLog, Люк. Вот, например, статейка, как работать с виндовыми логами из powershell: windowsitpro.com/powershell/access-security-event-...

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

"man vpn, Luke!" Читайте, что такое VPN вообще, и конкретные её реализации, в частности (например, протоколы IPSec, OpenVPN, L2TP). Почитайте про чудо-железки чудо-производителя Mikrotik -- они поддерживают все перечисленные, и ещё много разных других полезных протоколов.

У вас один HBA с двумя портами? В любом случае, это резервирует отказ на уровне порта/кабеля в любом из каналов.

В момент возникновения проблемы запустите tcpdump на убунте и посмотрите, как пакеты ходят.

1) Сервера могут быть какого угодно вендора, но вот модели и поколения процессоров у них должны совпадать. В вашем случае же этого не наблюдается. У VMware есть технология EVC, которая позволяет уравнять наборы команд процессоров разного поколения по самому старому из них. Насколько я помню, у Hyper-V такого ничего нет. Поэтому если у вас в кластере будут процы разного поколения и моделей -- как бы не огрести проблем, так что покурите этот вопрос.

2) Если уж гулять на полную высокую доступность, то коммутаторов должно быть минимум два, а какие конкретно -- это от нагрузок зависит. Может, хватит 1G, а может и InfiniBand потребуется какой-нибудь :-) Два коммутатора, в каждый из которых подключено по одному интерфейсу от каждого сервера и каждого NAS-а. Чтобы при выходе из строя любого из компонентов -- сетевушки, патчкорда, порта на коммутаторе, коммутатора целиком, связь не прерывалась. Но для этого потребуется, разумеется, iSCSI multipath и/или бондинг интерфейсов.

3) В вашем случае лучше сразу подключать оба хранилища к хостам. А бэкапы хранить где-то ещё. Для уменьшения времени простоя на восстановление виртуалок из бэкапов можно воспользоваться механизмом репликации с одного хранилища на другое. Например, Veeam это умеет. Акронис, я полагаю, тоже, да и встроенные средства какие-то в винде есть на этот счёт, нужно только поразбираться. Тогда время даунтайма будет минимально, и потери данных незначительны.

А как вы через IPMI собрались загрузку CPU и LAN мониторить? :-)

Вообще, в 3-ем Z, по-моему, оно даже не смотрит на IP сервака. И если все проверки активные, то при смене IP данные всё равно продолжают собираться. Главное, чтобы в конфигах совпадал hostname с тем, который указан в настройках хоста на сервере Z.

Товарищ, вам же сказали -- нужен дополнительный IP для вашей виртуалки. Тот IP-шник, что выдаётся вашему серверу -- уходит на интерфейс управления ESXi'ом. Использовать его где-либо ещё вам не удастся.

Хотя я не понимаю. вы утверждаете, что собираетесь всего одну виртуалку с виндой там создавать. На кой хрен вам тогда вообще ESXi -- ставьте сразу Win7, и этот IP-шник будет отдан ей.

Либо ставьте на хост линух, в нём какой-нибудь KVM или виртуалбокс, и настраивайте NAT между хостовой и гостевой системами. Тогда выданный хостовой системе IP можно будет использовать для выхода виртуалки в интернет. А на ESXi это не прокатит.

Да, падает хост. Протестите железо всё на стабильность, и обновите Варю.

На циске есть недокументированная утиля ttcp. Во фре есть в портах аналогичная утиля: /usr/ports/benchmarks/ttcp. По идее, должны работать вместе :-) Но оно там по дефолту всего 16 Мб для теста перегоняет, канал может не успеть раскачаться на полную. Есть сведения, что можно с параметром rcvwndsize поиграться, чтобы трафика больше прокачивало, но я с этим не работал, поэтому подтвердить не могу.

Не очень понятно, что вас смущает. Вы своё пространство зарезервировали под ZVOLы. Сейчас у вас занято 6.09 Тб, и ещё 5.96 доступно в сумме на датасетах:

hdd1/ESXi 4.06T 4.39T 389G -
hdd1/ESXi1 1.02T 1.57T 158G -

(вторая колонка -- available space). Что в сумме нам даёт 12.05 Тб. Плюс 728 Гб доступных на коревом датасете. В сумме получается ~12.8 Тб. Плюс-минус, с учётом метаданных, вот он ваш объём, нет?