Обновить
2
Бешков Андрей@abeshkov

Пользователь

22
Подписчики
Отправить сообщение
Для создания безопасных систем есть групповые политики и настройки локальной системы позволяющие так закрутить гайки на Windows что даже Пентагон и множество других организаций обрабатывающих информацию деликатного характера использует Windows без каких либо проблем.
Изготовление абсолютно защищенной системы экономически не окупится. Ей просто пользоваться будет невозможно. Поэтому делают системы которые способны обеспечить защищенность такого уровня чтобы взламывать их стало экономически не выгодно.
Это был сознательный выбор для обеспечения беспроблемной работы наибольшего количества унаследованного ПО.

Любое повышение безопасности ОС ломает стороннее ПО, потому что реальная система это всегда компромис между безопасностью и удобством. Кто в результате крайний? Конечно же MS.

Как вы убедились в комментариях коллеги paz к этой статье сторонние разработчики не хотят писать безопасный код. Они хотят писать код без труда. Это естественно для людей поэтому любые изменения в системе безопасности ОС Windows делаются постепенно.
Все продукты развиваются эволюционно и приоритеты зависят от того что хотят пользователи.

Или вы хотите сказать что у других производителей и сообществ все с первого раза совершенно выходит?
То есть по вашему теперь и делать уже не нужно?
Последние два предложения в статье так же не согласованы. Видимо писались в большой спешке.
В первый раз прочитал и не понял о чем речь «трехмерная ФИГУ принцессы ».

Может стоит граматику текстовым редактором проверять?
Там SCO Open Server
К сожалению zfs не пробовал, не знал что ее уже можно применять в реальных системах.

Впрочем добавить виртуальных VHD дисков во FreeBSD не проблема.
Малый бизнес обычно даже на D-link не раскошелится.
Два надежных + одно хранилище это уже Failover cluster. При наличии Live migration отказ одного из серверов не приведет к остановке сервиса.

А вот с десятком обычных серверов оставка в любом случае будет.

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

В дешевых самосборных серверах скорее всего будет зоопарк устройств.

В случае смерти сервера надо производить переконфигурирование под новое железо.

В случае виртуализации просто скопировать вирт. машину на хост и запустить ее там.
А с динамическими VHD проблем не было?
Например для консолидации систем. Иметь два надежных сервера лучше чем десяток самосборных.

Чем больше элементов тем выше вероятность отказа.

Такие системы легче тиражировать на новые филиалы. Заменять их так же гораздо проще ибо мы отвязаны от физического оборудования.

Прочие полезности вроде резервного копирования, экономии электричества, экономии места в ЦОД тоже вполне применимы.
Я пробовал проводить установку с динамически расширяемыми VHD. Наткнулся на описываемуб вами ошибку один раз. Ошибка появлялась если во время инсталяции выбрать опцию с установкой портов и пакетов.

Если ставить порты после первой перезагрузки ОС то все работает нормально даже с очень большими динамическими дисками. Или если добавить второй динамический VHD диск уже после установки ОС.
С фиксированными дисками удалось попробовать VHD размером в 127 ГБ.

Надо будет попробовать с помощью dd создать какой либо огромный файл.

Предполагаю что для большинства систем диска в 127 ГБ может хватить.
Многие так же запускают FreeNAS под Hyper-V.

Как я понимаб pfSense у вас работает хорошо?

При установке или в процессе экспулатации какие либо неудобства или проблемы были?
Добавил. Спасибо за совет.
Я ставил Debian несколько месяцев назад без компонентов интеграции. Работало вполне нормально.

Если там новое ядро с компонентами то по идее должно быть гораздо быстрее. О том чтобы компоненты работали нестабильно пока ни от кого не слышал.

Может в ближайшее время потестирую и напишу об этом заметку.

На довольно многих предприятиях есть унаследованные инфраструктурные сервисы. Куда либо мигрировать их затратно. Часто люди которые их создавали уже давно уволились. Работает это все на какой либо забытой машине. Никакого резервного копирования не делается.

Если она сломается будет неприятно т.к на этот сервис может быть завязано много бизнес сервисов.

Поэтому мигрировать такую систему в систему виртуализации гораздо выгоднее с точки зрения поддержки и непрерывности бизнеса.

Кластеризацию и резервное копирование виртуализированного сервиса получаем автоматом сразу после помещения виртуальной машины в кластер Hyper-V.
Любую виртуализированную систему про которую пишу заметки, я оставляю работать на неделю другую и с помощью скриптов прокачиваю через нее гигабайты информации по FTP или SSH.
C компонентами интеграции Hyper-V в ядре Linux все отлично. Вот тут пример их применения

habrahabr.ru/blogs/virtualization/112850/

В принципе любой Linux с ядром начиная с 2.6.32 работает вполне надежно.

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность