NastyaSaharok, на авито полно нормальных дисков по дешёвке :-)
Если контроллер работает в режиме эмуляции IDE, то можно попробовать поменять режим с DMA на PIO, если биос такое позволяет. На старых компах позволял. На новых -- не всегда. Если же выбран режим AHCI, то тогда по-простому никак, наверное. Есть программы типа "process lasso", она вроде умеет контролировать приоритет IO для конкретных процессов. Но в отсутствии других нагрузок (чтения/записи) от других процессов это мало поможет. В общем, как говорится, "всё сложно" :-)
sim3x, речь про то, что он резко негативно и не стесняясь в выражениях высказывается по ряду вопросов, и в частности, по вопросам изменений ядра для повышения безопасности. "Производители" здесь -- это один случай из многих. Я вот там ссылочку привёл, почитайте.
Microsoft DNS Server, очевидно. Ставите серверную версию винды, устанавливаете там роли DNS и DHCP-сервера (я так понимаю, камера настройки по DHCP получает), конфигурируете DHCP, чтобы он выдал камере IP-адрес и настройки DNS, а в DNS-сервере создаёте нужную зону и в ней А-запись, соответствующую нужному имени хоста, который вы фидлером обнаружили, и в А-записи прописываете IP-адрес вашего web-сервера с прошивкой.
Максим Гришин, ну вопрос-то был "как это сделать из vSphere". То, что из управлялки это можно сделать -- понятно. Но не все сервера даже из управлялвки это умеют. Супермикры, например, нет. Я поэтому и спрашивал, какие сервера. Но автор вопроса так и не ответил.
В теории, под ESXi есть разные варианты CIM, которые могут позволять управлять такими вещами. Но зависит от бренда сервера и его желания предоставлять соответствующий софт под ESXi.
Есть другой вариант -- на ESXi можно скопировать статически скомпилированную (со всеми либами внутри) утилиту ipmitool, и попробовать через неё. Опять-таки, для этого нужно, чтобы сервер имел поддержку IPMI.
Ну и если ничего из этого нет, то как я уже сказал выше -- находим порт коммутатора по MAC-адресу интерфейса управления сервером, и идём по проводу.
Stalker_RED, про какие суды вы говорите? Про якобы отказ Apple участвовать в расшифровке данных с айфона по запросу ФБР? Вы правда считаете, что коммерсы прям настолько честные, что у них запрос поделиться данными "в интересах следствия" вызывает праведный гнев? Может, вы ещё и деда Мороза верите?
Коммерческим компаниям нет никакого резона нет бодаться с компетентныими органами. По той простой причине, что у последних гораздо больше возможностей прищемить хвост первым. А если по-тихому отдать имеющиеся данные, то все довольны.
Разумеется, это не носит массовый характер, т. е. данные сливаются далеко не все, запросы будут достаточно узкие, касающиеся определённой группы лиц. Но то, что это имеет место быть -- к бабке не ходи.
Interface, спецслужбы, например. Правда, я не думаю, что они покупать будут. Просто придут и скажут: "Ребята, тут такое дело..." И данным им отдадут за так, причём сами ещё и привезут. Более того, я уверен, что данные им и так отгружают регулярно.
Там куча данных собирается, и произвольным решением разработчика набор этих данных может измениться. Например, клавиатурный ввод могут начать собирать. Весь. Включая пароли, номера карт, телефонов и т. п.
Артем, не стоит нагружать кучу функций на один хост, физический или виртуальный -- неважно. Лучше по максимуму (ну, в рамках разумного, конечно) разделить функционал. Иначе при останове хоста для обслуживания перестанет функционировать куча служб. Виртуалки тут -- большое подспорье. Останавливая для обновления сервер мониторинга, вы не затрагиваете другие службы, которые используются пользователями.
20-30 Тб -- это большой объём, виртуальные диски такие делать не стоит -- такими виртуалками очень тяжело маневрировать (перемещать, бэкапить и т. п.). Поэтому этот объём лучше раздавать напрямую с какой-то железки -- сервер с кучей дисков или СХД, презентуя по NFS или SMB.
VPN, файрвол, мониторинг, контроллеры доменов -- это виртуалки, реализуется без проблем. Собственно, как раз функции входного файрвола и VPN можно реализовать на одной виртуалке.
Сергей,
Не очень понятно, почему вы поднимаете вопрос мощностей, когда о мощности вопрос даже не стоял. Я думал, это саммочевидно, что вместо одного прокачанного сервера достаточно взять три сервера попроще. Например, HPE Microserver Gen8/9 -- это отличные штуки, и стоят недорого. Но если это не очевидно, то могу проговорить это открытым текстом: нет смысла брать мощные сервера, достаточно трёх серверов с конфигурацией попроще. Один сокет, по 32/64 гига оперативы, 2-4 диска в RAID1/10, всё такое.
Количество пользователей в конторе -- это вообще не показатель и не рекомендация. У нас сейчас 80 человек в организации, и при этом парк физических серверов в несколько десятков. Про виртуальные я вообще молчу, там счёт на сотни. При этом мы не хостер и не провайдер - все сервера обеспечивают исключительно наши внутренние задачи.
Сергей, насколько я понимаю, у вас рабочий опыт состоит из аутсорса.
Мой рабочий опыт включает и аутсорс, и управление большими инфраструктурами, с десятками физических и сотнями виртуальных серверов. Поэтому ваши рассуждения с точки зрения аутсорса -- имеют право на существование. Но когда речь заходит о надёжности, то ваши рекомендации надёждность обеспечить не смогут. Один сервер, один порт на гигабит, один порт на 10G -- это всё ни о чём. Потому что любой чих в этой цепочке выводит сервер из эксплуатации и оставляет всех без работы.
Два сервера не смогут обеспечить надёжность, по той простой причине, что любая SDS строится минимум на трёх узлах. Независимо от того, что это будет -- Ceph, ScaleIO, vSAN.
Два сервера могут обеспечить отказоустойчивость, при условии, что у них есть общее надёжное хранилище. СХД, например, или DAS. Но во-первых, это всё равно ТРИ железки, а во-вторых -- СХД стоит не меньше, а часто даже и больше сервака. DAS тоже не дёшевы. Не как СХД, но всё равно, с сервером вполне сравнимо. Поэтому за эти же деньги лучше взять систему, которая сможет обеспечить не только storage, но и компьютинг.
Ваши рассуждения насчёт отсутствия необходимости в helpdesk и того, что "веб-интерфейса" к гипервизору достаточно показывает, что вы никогда не обеспечивали работу средних или крупных офисов. Хелпдеск не нужен, когда пользователей 5 человек. Ну, если 10 -- тоже можно обойтись. Начиная с 15 и больше -- уже нужно как-то решать вопрос приёма и обработки заявок. Система ведения заявок решает сразу несколько проблем:
Единый канал поступления заявок. Когда вам заявки поступают по телефону, почте, телеграму, лично и ещё парочке каналов -- голова от этого немного пухнет. И с этим связана проблема -- заявки начинают теряться.
А система хелпдеска делает так, что заявки не теряются. И остаются. И их можно приоритизировать.
Заявки из тикет-системы можно раздавать разным исполнителям. При этом по истории заявок другим исполнителям будет ясно, кто и что делал. И когда. И сразу снимается проблема: "блин, это делал Вася, а он в отпуске, надо ему звонить, спрашивать". А Вася недоступен, либо доступен в диком роуминге, поэтому объясняет 15 секунд и бросает трубку. А так -- либо поиском по заявками, либо Вася говорит: "была заявка номер такой-то, посмотри там подробности". И всё, человек идёт и читает, в чём было дело и как решали проблемы
И для отчётов тикет-система тоже очень полезна. Приходит к вам начальник такой 31-го декабря и говорит -- "Сергей, у нас есть бюджет на премию. А накидай-ка мне быстренько, что ты в течение последнего месяца/квартала/года сделал героического, а я тебе премию дам". И вот тут начинаются мучительные воспоминания, а чем же вы в означенный период занимались. На практике даже за неделю вспомнить не удаётся весь список проделанных дел, а уж за месяц или тем более квартал и тем более. А так -- открыл свои заявки, прошерстил и составил красивый отчёт, и премию потом за геройство получил.
А ещё есть такой понятие, как SLA. Который вот так на пальцах ни отследить, ни обеспечить невозможно. Например, клиенты у вас постоянно недовольны, что часто факапятся сроки по их заявкам.
Но поскольку никакой статистики нет, то они так и останутся недовольными, а вы не будете даже знать --
действительно ли сроки проваливаются регулярно, или это пользователи склочные попались. А если сроки нарушаются, то почему? Может быть, нужно ещё человека в штат брать? Или просто кое-кто из коллектива халявит, обрабатывая заметно меньше заявок, чем его коллеги, и ему пора вставить клизьму на пол-ведра скипидара? А то и вовсе уволить, и найти кого порасторопнее/компетентнее.
Так что в коллективе, где 70 пользователей, хелпдеск-система должна быть, и в этом стремление автора вопроса я целиком и полностью поддерживаю.
А что касается "специализированных" NAS'ов, то я бы не стал эти устройства за пределами дома использовать. Бэкапы разве что хранить, а в остальном это очень ненадёжные устройства.
Сергей, учитывая реалии нашей страны, "VMware" и "деньги" не всегда ходят рядом :-)
Что касается трёх серверов -- я там вполне прозрачно объяснил, зачем. Отказоустойчивость плюс возможность в любой момент выводить любой из серверов для обслуживания.
Если контроллер работает в режиме эмуляции IDE, то можно попробовать поменять режим с DMA на PIO, если биос такое позволяет. На старых компах позволял. На новых -- не всегда. Если же выбран режим AHCI, то тогда по-простому никак, наверное. Есть программы типа "process lasso", она вроде умеет контролировать приоритет IO для конкретных процессов. Но в отсутствии других нагрузок (чтения/записи) от других процессов это мало поможет. В общем, как говорится, "всё сложно" :-)