Не все кто разбираются в виртуализации и контейнеризации знают vi! Я например пришел из Windows админов и сетевиков… и докер контейнеры работающие на ZFS в продкашене уже использую но без vi как то обходился… Если в рамках статьи vi обязателен, то я бы на месте автора тоже написал бы точные команды…
Спасибо за полезную статью! Я работаю с Microtik, однако с Proxy-ARP уже успел познакомиться на собственном опыте. Ваш материал помог упорядочить знания.
А есть ли подобное средство, но что бы одноразовые пароли запрашивались не только во время входа в систему, а во время любых запросов на повышение привелегий? Т.е. нужно что бы OTP пароли зарашивались уже внутри сеанса пользователя, если ему требуется повысить права, скажем, для установки приложения.
То есть современные СУБД в момент записи новых данных «портят» старые до того как полностью запишутся новые? Просто я думал все адекватные системы (в том числе файловые системы) имеют COW архитектуру, которая как раз исключает неконсистентное состояние данных даже при жестком отключении питания. То есть сначала создаются новые данные, затем уничтожаются старые…
О мгновенном снимке говорить не приходится, ведь это физическая операция, которая занимает какое-то время.
Вот это мне и не дает покоя… Например, я точно знаю, что снимки файловой системы ZFS выполняются одной элементарной операцией в один момент времени или не выполняются вообще. Другими словами это не процесс, а действие, во время которого существование других действий невозможно. Но у ZFS иная модель нежели у NTFS, — транзакционная… Неужели NTFS не способна на атомарный снимок?
Объясните пожалуйста более доходчиво, почему нельзя бэкапить БД средствами гипервизора?
Ведь гипервизор создает моментальный снимок файловой системы и все файлы будут прочитаны как бы в один момент времени, атомарно (не зависимо от реального времени чтения). То есть в худшем случае это должно быть равносильно отключению электропитания сервера БД. Согласен, это плохо, но терпимо.
У Майкрософт есть отличная утилита disk2vhd. Она делает тоже самое, бесплатная и компактная. Официальное решение так сказать.
Полученный VHD диск потом можно без проблем запускать на Hyper-V или монтировать через стандартные средства Windows.
Можете поделиться как решается проблема неактивных маршрутов? Кажется роуты на статике тоже могут переставать работать. Например, упало соединение на физическом интерфейсе (кабель порвался). Тогда маршрут для проверки основного канала станет неактивным и Netwatch успешно сделает ping, так и не поняв, что канал упал. Если же резервный канал поднимается только после регистрации падения основного, то Netwatch выполнит переход на резервный канал, а затем снова успешно сделает ping и выполнит скрипт для возврата на мертвый основной канал. Так и будет по кругу…
А вот в собственном скрипте мы можем явно указать интерфейс в команде ping, избежав проблем.
Если основной провайдер раздает настройки через DHCP, предложенная схема не сработает. Advanced_Routing_Failover_without_Scripting тоже не сработает.
Мы заранее не знаем адрес шлюза, а маршрут вида «ip route add dst-address=8.8.4.4/32 distance=1 gateway=ethernet1» не сработает. То есть мы не можем указать интерфейс вместо адреса в маршруте (могли бы, в случае PPP соединения).
Предлагаю решение:
1. Пометить DHCP клиент основного провайдера примечанием «Default Route» и включить добавление динамического маршрута.
2. Добавить маршрут для проверки основного канала. gateway=любой, address=8.8.4.4, comment=«Check Gateway»
3. Добавить в крон скрипт, который
--а. Ищет dhcp-client с пометкой «Default Route»
--b. Берет из него адрес шлюза.
--c. Ищет route с пометкой «Check Gateway»
--c. Присваивает проверочному маршруту найденный шлюз.
ip route set [find comment="Check Route"] gateway=[/ip dhcp-client get [find comment="Default Route"] value-name=gateway]
3. Добавить Netwatch смотрящий на проверочный маршрут.
On Up: ip dhcp-client set default-route-distance=1 [find comment="Default Route"]
On Down: ip dhcp-client set default-route-distance=10 [find comment="Default Route"]
Запасной маршрут должен иметь дистанцию от 2 до 9.
Внутри Netwatch можно добавить ресет коннекшенов и отправку email
Если основной провайдер раздает настройки через DHCP, предложенная схема не сработает. Advanced_Routing_Failover_without_Scripting тоже не сработает.
Мы заранее не знаем адрес шлюза, а маршрут вида «ip route add dst-address=8.8.4.4/32 distance=1 gateway=ethernet1» не сработает. То есть мы не можем указать интерфейс вместо адреса в маршруте (могли бы, в случае PPP соединения).
Предлагаю решение:
1. Пометить DHCP клиент основного провайдера примечанием «Default Route» и включить добавление динамического маршрута.
2. Добавить в крон скрипт, который
--а. Ищет dhcp-client с пометкой «Default Route»
--b. Берет из него адрес шлюза.
--c. Присваивает проверочному маршруту найденный шлюз. Пример такого скрипта.
3. Добавить Netwatch смотрящий на проверочный маршрут.
On Up: ip dhcp-client set default-route-distance=1 [find comment=«Default Route»]
On Down: ip dhcp-client set default-route-distance=10 [find comment=«Default Route»]
Запасной маршрут должен иметь дистанцию от 2 до 9.
Внутри Netwatch можно добавить ресет коннекшенов и отправку email
Класс WIAScanner не корректно декомпилируется. Поделитесь пожалуйста исходниками. Дело в том, что из реестра не выходит вызывать программу с параметрами, а без передачи параметров она не позволяет выбрать место для сохранения изображения.
Что бы изменения вступили в силу после редактирования реестра достаточно перезапустить службу «Служба загрузки изображений Windows (WIA)»
Делается это так:
Иногда очень важно хранить данные таким образом, что бы в последствии получить доступ просто подсоединив диски = аппаратно\програмно независимо.
Поделюсь своим опытом хранения данных на ZFS в продакшене вот уже 4 года. Использую RaidZ, это аналог RAID5, то есть может выйти из строя любой диск.
1. Независимость и целостность. RaidZ ближе всего подходит под условие аппаратно\программно независимый массив.
Можно полностью заменить аппаратную платформу, не меняя программную (достаточно перенести диски и флешку с ОС на другой ПК и включить его. Обычно используются системы построенные на FreeBSB которые поддерживают широкий спектр оборудования, от самых старых до самых новых ПК) Проверено много раз.
Можно полностью сменить программную платформу. Главное, что бы ОС поддерживала файловую систему ZFS (OpenSolaris, FreeBSD, Linux пока из коробки не поддерживает). После установки ОС Zpool импортируется одной командой! Проверено много раз.
2. Версионность (лучшая из виденных мною)
Механизм снапшотов интегрирован в файловую систему. Отсюда вытекает очень много положительных моментов.
Снапшоты аппаратно\программно независимы и не исчезнут из-за сбоя оборудования или ОС.
Снапшоты не замедляют работу ФС, как например в NTFS (этому способствует структура ФС, подробнее в Wiki, там очень интересно). У меня сейчас более 1000 снапшотов 8 тб файловой системы и все работает отлично. На то, что бы создать снапшот уходит пара секунд. Можно монтировать снапшоты когда нам требуется и получать полный доступ к данным внутри снапшота.
В EXT3\4 и NTFS снапшоты тоже возможны, но требуют отдельных сложных механизмов, которые не столь надежны и целостны.
3. Целостность.
Я настолько доверяю ZFS, что меня перестало интересовать какая ОС ее реализует и будут ли проблему у этой ОС. Zpool как бы существует отдельно от ОС, т.к. полностью обслуживается ZFS драйвером, а все параметры и снапшоты хранятся в самом пуле, а не в ОС. То есть если дисковый массив подключить к другому оборудованию и заново установить любую ОС, которая поддерживает ZFS, мы увидим наш пул, все файлы, снапшоты, разрешения фс, и старые настройки самого пула (например применять ли сжатие, использовать ли дедупликацию).
4. Дедупликация прозрачная и это бесплатно.
Для примера в Windows Server 2012 дедупликация есть, но она не прозрачная, то есть выполняется после того как файлы записаны или изменены в фоне по заданному расписанию (например ночью, когда сервер более свободен, т.к. это требует серьезных ресурсов).
5. Надежность
Уже успел столкнуться с выходом из строя одного из жестких дисков. Заметил по характерным звукам в соседней комнате. Лучше сразу настраивать оповещения, т.к. ZFS продолжает обслуживать пул и восстанавливает данные на лету по контрольным суммам. У меня даже скорость не упала при копировании через SMB. Пересборка 10 тб пула, заполненного на половину, после замены вышедшего из строя 2 тб диска заняла 16 часов.
Вам потребуется любая (насколько я знаю любая, но 100% гарантии все же дать не могу) видеокарта от AMD и поддержка VT-d для процессора и мат. платы.
Формально в виртуальную машину пробрасывается любая видеокарта, но в случае с Nvidia для нормальной работы карты требуется магия, которая описана здесь.
Пробросить встроенную видеокарту у меня с ходу не вышло, но обещаю, что попробую еще разок.
Вот это мне и не дает покоя… Например, я точно знаю, что снимки файловой системы ZFS выполняются одной элементарной операцией в один момент времени или не выполняются вообще. Другими словами это не процесс, а действие, во время которого существование других действий невозможно. Но у ZFS иная модель нежели у NTFS, — транзакционная… Неужели NTFS не способна на атомарный снимок?
Вот ссылка на описание снимков ZFS если что… docs.oracle.com/cd/E19253-01/820-0836/gbciq/index.html
Объясните пожалуйста более доходчиво, почему нельзя бэкапить БД средствами гипервизора?
Ведь гипервизор создает моментальный снимок файловой системы и все файлы будут прочитаны как бы в один момент времени, атомарно (не зависимо от реального времени чтения). То есть в худшем случае это должно быть равносильно отключению электропитания сервера БД. Согласен, это плохо, но терпимо.
Полученный VHD диск потом можно без проблем запускать на Hyper-V или монтировать через стандартные средства Windows.
А вот в собственном скрипте мы можем явно указать интерфейс в команде ping, избежав проблем.
Advanced_Routing_Failover_without_Scripting тоже не сработает.
Мы заранее не знаем адрес шлюза, а маршрут вида «ip route add dst-address=8.8.4.4/32 distance=1 gateway=ethernet1» не сработает. То есть мы не можем указать интерфейс вместо адреса в маршруте (могли бы, в случае PPP соединения).
Предлагаю решение:
1. Пометить DHCP клиент основного провайдера примечанием «Default Route» и включить добавление динамического маршрута.
2. Добавить маршрут для проверки основного канала. gateway=любой, address=8.8.4.4, comment=«Check Gateway»
3. Добавить в крон скрипт, который
--а. Ищет dhcp-client с пометкой «Default Route»
--b. Берет из него адрес шлюза.
--c. Ищет route с пометкой «Check Gateway»
--c. Присваивает проверочному маршруту найденный шлюз.
ip route set [find comment="Check Route"] gateway=[/ip dhcp-client get [find comment="Default Route"] value-name=gateway]3. Добавить Netwatch смотрящий на проверочный маршрут.
On Up:
ip dhcp-client set default-route-distance=1 [find comment="Default Route"]On Down:
ip dhcp-client set default-route-distance=10 [find comment="Default Route"]Запасной маршрут должен иметь дистанцию от 2 до 9.
Внутри Netwatch можно добавить ресет коннекшенов и отправку email
Advanced_Routing_Failover_without_Scripting тоже не сработает.
Мы заранее не знаем адрес шлюза, а маршрут вида «ip route add dst-address=8.8.4.4/32 distance=1 gateway=ethernet1» не сработает. То есть мы не можем указать интерфейс вместо адреса в маршруте (могли бы, в случае PPP соединения).
Предлагаю решение:
1. Пометить DHCP клиент основного провайдера примечанием «Default Route» и включить добавление динамического маршрута.
2. Добавить в крон скрипт, который
--а. Ищет dhcp-client с пометкой «Default Route»
--b. Берет из него адрес шлюза.
--c. Присваивает проверочному маршруту найденный шлюз.
Пример такого скрипта.
3. Добавить Netwatch смотрящий на проверочный маршрут.
On Up: ip dhcp-client set default-route-distance=1 [find comment=«Default Route»]
On Down: ip dhcp-client set default-route-distance=10 [find comment=«Default Route»]
Запасной маршрут должен иметь дистанцию от 2 до 9.
Внутри Netwatch можно добавить ресет коннекшенов и отправку email
LL prior RouterOS releases (6.11 and older) are not affected by this vulnerability as older OpenSSL library where used.
In addition RouterOS 6.12 will have new OpenSSL library that has this vulnerability resolved.
Делается это так:
Поделюсь своим опытом хранения данных на ZFS в продакшене вот уже 4 года. Использую RaidZ, это аналог RAID5, то есть может выйти из строя любой диск.
1. Независимость и целостность. RaidZ ближе всего подходит под условие аппаратно\программно независимый массив.
Можно полностью заменить аппаратную платформу, не меняя программную (достаточно перенести диски и флешку с ОС на другой ПК и включить его. Обычно используются системы построенные на FreeBSB которые поддерживают широкий спектр оборудования, от самых старых до самых новых ПК) Проверено много раз.
Можно полностью сменить программную платформу. Главное, что бы ОС поддерживала файловую систему ZFS (OpenSolaris, FreeBSD, Linux пока из коробки не поддерживает). После установки ОС Zpool импортируется одной командой! Проверено много раз.
2. Версионность (лучшая из виденных мною)
Механизм снапшотов интегрирован в файловую систему. Отсюда вытекает очень много положительных моментов.
Снапшоты аппаратно\программно независимы и не исчезнут из-за сбоя оборудования или ОС.
Снапшоты не замедляют работу ФС, как например в NTFS (этому способствует структура ФС, подробнее в Wiki, там очень интересно). У меня сейчас более 1000 снапшотов 8 тб файловой системы и все работает отлично. На то, что бы создать снапшот уходит пара секунд. Можно монтировать снапшоты когда нам требуется и получать полный доступ к данным внутри снапшота.
В EXT3\4 и NTFS снапшоты тоже возможны, но требуют отдельных сложных механизмов, которые не столь надежны и целостны.
3. Целостность.
Я настолько доверяю ZFS, что меня перестало интересовать какая ОС ее реализует и будут ли проблему у этой ОС. Zpool как бы существует отдельно от ОС, т.к. полностью обслуживается ZFS драйвером, а все параметры и снапшоты хранятся в самом пуле, а не в ОС. То есть если дисковый массив подключить к другому оборудованию и заново установить любую ОС, которая поддерживает ZFS, мы увидим наш пул, все файлы, снапшоты, разрешения фс, и старые настройки самого пула (например применять ли сжатие, использовать ли дедупликацию).
4. Дедупликация прозрачная и это бесплатно.
Для примера в Windows Server 2012 дедупликация есть, но она не прозрачная, то есть выполняется после того как файлы записаны или изменены в фоне по заданному расписанию (например ночью, когда сервер более свободен, т.к. это требует серьезных ресурсов).
5. Надежность
Уже успел столкнуться с выходом из строя одного из жестких дисков. Заметил по характерным звукам в соседней комнате. Лучше сразу настраивать оповещения, т.к. ZFS продолжает обслуживать пул и восстанавливает данные на лету по контрольным суммам. У меня даже скорость не упала при копировании через SMB. Пересборка 10 тб пула, заполненного на половину, после замены вышедшего из строя 2 тб диска заняла 16 часов.
Надеюсь мой опыт будет кому-то полезен!
Формально в виртуальную машину пробрасывается любая видеокарта, но в случае с Nvidia для нормальной работы карты требуется магия, которая описана здесь.
Пробросить встроенную видеокарту у меня с ходу не вышло, но обещаю, что попробую еще разок.
Пишите, если будут вопросы!