Вы правы. Но статья не о том, как правильно зашифровать данные, а скорее из разряда: «Вот прикупил себе SSD. Чего это у него там такое? Встроенное шифрование? А как его включить? В инструкции нет ничего. Это что же, я за это заплатил, а оно лежит мёртвым грузом и не работает? Непорядок!».
По крайней мере, у меня это так было.
Лично для меня это означало бы необходимость апгрейда с Windows 7 Professional до Ultimate. Поэтому я его не рассматривал, и особо ничего рассказать про него не могу. Может, кто другой напишет.
Хорошо, сдаюсь. Если у вас 50 серверов и вы хотите одним махом настроить на всех пятидесяти репликацию данных, то 50 раз «кликать «next, next, next»», а в конце понять, что один из параметров был задан неверно — очень непрактично и тоскливо.
К счастью, кроме обвязки для PowerShell, у нас есть ещё Web API, который позволяет выполнить такое. См., например:
arcserve RHA Control Service Web API Reference Index: https://arcserve.zendesk.com/hc/en-us/articles/202810715
arcserve RHA Control Service API User Guide: Lesson 1 Environment Setup/Requirements and Creating a Session: https://arcserve.zendesk.com/hc/en-us/articles/202041319
Кроме того есть возможность экспорта/импорта сценариев в/из XML-файлы. То есть можно этот файл генерировать в вашем средстве автоматизации, а потом закачивать в Arcserve RHA.
Я сейчас одну вещь скажу, Вы только не обижайтесь. Мне кажется, что у Вас индустриальное означает брутальное. То есть если софт суровый, с командной строкой, то он индустриальный. А если с картинками — то игрушка.
Вот как по вашему, если у ленточной библиотеки есть веб-интерфейс с графикой — это уже несерьёзно?
А если у маршрутизатора надо писать «wr mem» то это индустриально, а если нажать на кнопку «Сохранить» на веб-интерфейсе, то это пошло?
Мне тоже нравится многое делать в командной строке. Но вот файл «sendmail.cf» считаю лично для себя неудобным. Предпочитаю заполнить формы какие-нибудь.
Короче говоря, каждый выбирает для себя, и всё хорошо в меру.
Не вводите людей в заблуждение. Seafile и ownCloud – это программы той же категории, что и DropBox, OneDrive, Google Drive и т.д. То есть предназначены, главным образом, для периодической синхронизации данных на клиентской машине/телефоне с хранилищем на сервере.
Это накладывает отпечаток на их способ работы. В частности, ownCloud периодически сканирует локальные файлы, чтобы понять, кого их них нужно отправить на сервер.
А Seafile, хоть и использует inotify для мгновенного оповещения о том, что с файлами что-то произошло, должен потом этот файл просканировать и определить, что же это было. Кроме того, он вносит дополнительное звено – репозитарий (как у Git), который должен сначала обновиться локально, а уж потом синхронизироваться с серверным.
Сравните это с модулем ядра (linux) или filter-driver в Windows, используемые Arcserve RHA, которые СРАЗУ знают, какие данные в файле изменились, а не пересканируют его, чтобы понять, что же произошло.
И скажите, как могут Seafile или ownCloud при их подходе в реальном времени реплицировать один большой файл, в который постоянно вносятся изменения (базу Exchange или Oracle или SQL, как в примере 3.2 из статьи?
Пообщался с разработчиками. Они говорят следующее:
После того, как на UNIX/Linux запускается сценарий репликации, мы монтируем файловую систему XOFS поверх существующей файловой системы. Команда ‘mount’ будет показывать 2 файловых системы: старую и новую (XOFS).
После монтирования XOFS поверх существующей файловой системы, пользователь сможет обращаться к файлам, просматривать каталоги… Однако, весь доступ происходит через XOFS. XOFS транслирует все вызовы в лежащую под ней файловую систему и возвращает результат тому, кто делал вызов.
Мы перехватываем всё, что касается создания, удаления, записи, mkdir, rmdir, change attr, mklink и т.д. Мы сбрасываем все эти события в журнал, вместе с данными, которые пишутся. Затем процесс в пользовательском режиме подхватывает этот журнал, переформатирует и пересылает на удлённую машину-реплику. Реплика получает, обрабатывает и повторяет действия из журнала.
Работа XOFS не зависит от того, какого типа файловая система находится под ней. XOFS просто транслирует вызовы и возвращает коды возврата. Но если появится новый тип файловой системы, для которой появятся новые системные вызовы, то XOFS также потребует доработки.
Вместе с продуктом поставляется оснастка для PowerShell. Многие вещи удобно выполнять из командной строки, например:
Set-Bookmark — установить закладку, на которую потом можно будет откатиться во времени
Suspend-Scenario / Resume-Scenario — приостановить/продолжить работу сценария (для выполнения сервисных работ, например)
Но я не сторонник радикальных мер. Что-то удобнее делать в командной строке, а что-то — в графическом интерфейсе. Поиск точки на временной оси, на которую нужно откатиться, мне однозначно удобнее делать в графическом интерфейсе.
Поторопился я. Имеется в виду загружаемый модуль ядра, который служит прослойкой при обращении к файловой системе.
Находится в RedHat и SUSE вот здесь:
/opt/CA/ARCserveRHA/kernel/fs/xofs.*
Подробнее см. http://documentation.arcserve.com/Arcserve-RHA/Available/R16-5/ENU/Bookshelf_Files/HTML/UL/Files_Installed_on_Red_Hat_and_Novell_SUSE_Linux_Enterprise.html
Есть возможность оценить, с какой скоростью нужно будет передавать данные с одной системы на другую. Это так называемый «Assessment Mode» — реальная репликация не производится, но собирается статистика (например, в течение суток). Если вы видите, что скорости не запредельные, что их потянет и сеть, и система ввода-вывода, то можно запускать репликацию.
Но, конечно, всё хорошо в меру. Всегда найдётся какая-то система, которая может ввести в ступор. Приходит в голову игра «жизнь» на всех блоках данных диска…
Конечно, Вы правы. В 500 миллионах блоков вероятность коллизии значительно выше, но всё равно остаётся в пределах допустимого риска по мнению производителя. Я попробую запросить расчётные значения у разработчиков.
| Т.е. на вашей практике, еще на сталкивались с какими-то проблемами из-за sha-1 коллизий, насколько я понял.
Верно, не сталкивались.
Тут бы мне тихо и мирно закончить дебаты, но всё-таки не могу оставить без комментариев некоторые Ваши утверждения:
1. «В случае с ядерными ракетами, пример не корректный, так как там не проверяют миллиард раз в день сработает защита или нет.»
Я не ставил задачу сравнить вероятности. Очень надеюсь, что они несравнимы. Я лишь хотел указать, что вероятность сбоя, в принципе, отлична от нуля, и нельзя безапелляционно утверждать, что если вероятность сбоя (или коллизии в нашем случае) отлична от нуля, то доверия такой системе нет.
2. По поволу лотереи Powerball.
Думаю, что в расчет вероятности выигрыша джекпота вкралась ошибка.
Действительно, вероятность совпадения выигрышных чисел ДЛЯ ОДНОГО КОНКРЕТНОГО ЧЕЛОВЕКА равна 1/2^28 ( точнее, говорят, 1 к 292 201 338).
Но если купили миллион билетов, то вероятность выигрыша для одного человека не изменится, а вот вероятность того, что джекпот в принципе случится, станет больше в миллион раз, то есть будет равна… 1/292
То есть вероятность того, что я, мой сосед и мой племянник (то есть конкретные три человека) выиграют джекпот, действительно супер-низкая: 1/2^84, как Вы и сказали.
Но то, что джекпот выиграют три ПРОИЗВОЛЬНЫХ человека из миллиона купивших билеты, всего лишь 1/292^3.
Если куплено больше билетов, то вероятность ещё выше.
1. Дедупликация в таком виде используется во многих продуктах известных производителей программного и аппаратного обеспечения. Не кажется ли Вам, что если бы коллизия хэшей имела бы коль сколько-нибудь серьёзную вероятность возникновения, давно бы появилась обоснованная критика этого метода со стороны серьёзных специалистов, а не только дискуссии на форумах?
2. В вконце концов, дедупликация — это инструмент, который вы можете использовать, а можете и не использовать. Всё зависит от вашей собственной оценки рисков. Вы когда-нибудь ездили на автомобиле? Вы знаете, что погибнуть в автокатастрофе отлична от нуля и вовсе не ничтожна? Например, в России вероятность погибнуть в ДТП в течение года составляет около 0.00019.
Но вы всё-равно ездите. Оцениваете риск, но удобства от езды на автомобиле перевешивают опасность.
Так же и при дедупликации. Разница только в том, что риск автомобильной аварии осязаем, а риск коллизии миллиарда хешей ежедневно — ничтожен.
3. Что значит «ничтожен»? Выше я уже приводил примеры крайне маловероятных событий, вероятность которых выше, чем вероятность возникновения коллизии.
Но известно ли Вам, что вероятность того, что ошибочно будет произведён пуск ядерной ракеты также отлична от нуля? Это Вас не беспокоит? Вы просто уверены, что вероятность такого события ничтожна, хотя последствия чудовищны. А ничтожна — это насколько мала? когда для Вас число будет столь малым, что не будет вызывать беспокойства? 2^-80 достаточна? А 2^-160? А какая достаточна? Давайте выберем такой размер хеша, который будет соответствовать Вашим понятиям ничтожной вероятности.
Просто до нас уже кто-то прикинул вероятность коллизии для SHA-1 и решил, что это весьма небольшая вероятность, позволяющая использовать основанную на ней дедупликацию в промышленных системах.
Боюсь, что мои знания слишком поверхностны, чтобы обсуждать эту тему так глубоко, выступая в то же время адвокатом целой индустрии, основанной на дедупликации.
Или вот такое (мрачное) сопоставление.
В практикуме по страхованию жизни (легко ищется в интернете) можно прочитать, что вероятность прожить ещё один год для взрослого человека составляет около 0.99
Допустим, в вашем ИТ-департаменте работает 10 человек
Вероятность того, что в течение года все они дружно переплывут через реку Стикс, составляет
(1-0.99)^10 ~= 1/(2^7)^10 ~= 2^-70
То есть встретить коллизию SHA-1 вероятность гораздо меньше, чем всему департаменту ломануться на вечеринку к Одину.
Не кажется ли вам, что настолько маловероятное событие не заслуживает беспокойства о нём?
«Государь Гелон!
Есть люди, думающие, что число песчинок бесконечно. Я не говорю о песке в окрестности Сиракуз и других местах Сицилии, но о всём его количестве как в странах населённых, так и необитаемых.»
Архимед. Исчисление песчинок в пространстве равном шару неподвижных звёзд (Псаммит).
А, есть люди, которые считают, что 1/2^80 (вероятность коллизии SHA-1) – это обычное такое число, ничего особенного. И что встретить коллизию SHA-1 – обычное дело.
Сравнить же с этим числом можно (если не ошибаюсь) количество элементарных частиц в нашей галактике. А это куда больше, чем количество песчинок, подсчитанных Архимедом (2^80 против 10^63 – тысячи мириад чисел «восьмых»).
И вероятность коллизии меньше, чем вероятность того, что данные на жёстком диске случайно переманитятся, но CRC останется прежним! Представляете? Было «Я к вам пишу — чего же боле?» а стало «А теперь Горбатый! Я сказал – Горбатый!» только за счёт случайного перемагничивания.
Когда вероятность коллизии столь мала, что непонятно, увидим ли мы её когда-нибудь за всю историю существования человечества, то как-то трудно считать это ненадёжным решением. Возможно, серверы нашего тысячелетия расыпятся в прах, а коллизию мы так и не встретим. А может быть, натолкнёмся на коллизию уже завтра – со случайными величинами ни в чём быть уверенным нельзя.
В общем, всё зависит от вашего доверия/недоверия к тому, может ли возникнуть событие с ничтожно низкой вероятностью. И «ничтожно» — это куда меньше, чем найти две одинаковых песчинки не просто в окрестностях Сиракуз, но и во всей нашей галактике.
Любая технология резервного копирования подразумевает, что должна проводиться периодическая проверка восстановимости. И дело не только в дедупликации.
Лично мне приходилось сталкиваться с такими двумя случаями:
1. Копирование на ленточный привод годами проходило без ошибок. Ленты подписывались и складывались в шкафчик. Когда возникла необходимость восстановить данные, оказалось что ленты пусты. Ни разу никто не проверил, действительно ли на лентах что-то записано или нет.
2. Снова лента. Долгое время проводилось ежедневное резервное копирование сервера с базой данных Oracle. Операционная система стояла на диске C:, база данных — на диске D:. Когда сервер рухнул, оказалось, что копировался только бесполезный диск C:, про диск D: забыли при создании задания на резервное копирование.
Что я хочу этим сказать? Если бы люди хоть раз провели бы тестовое восстановление, то ошибки всплыли бы.
Точно также и с дедупликацией. Если есть регламент проверки восстановимости, то можно положиться на такую систему.
Для пущей уверенности держать несколько серверов хранения резервных копий и периодически переливать хранилище на отчуждаемый носитель (магнитную ленту).
Образ диска разбивается на блоки условленного размера, и позиция этих блоков не меняется, то есть они не скользят. Это не мешает, однако, получать высокий процент дедупликации на реальных данных при минимальных вычислительных затратах.
А уж если бы коллизия SHA-1 кому-то попалась (необязательно нам), то такая новость сразу бы наводнила Интернет, и мы тут же увидели бы её на Хабре, да и во всяких википедиях тоже.
Не могу отделаться от ощущения, что вы уже начали шифровать («как завадался...»).
По крайней мере, у меня это так было.
К счастью, кроме обвязки для PowerShell, у нас есть ещё Web API, который позволяет выполнить такое. См., например:
arcserve RHA Control Service Web API Reference Index: https://arcserve.zendesk.com/hc/en-us/articles/202810715
arcserve RHA Control Service API User Guide: Lesson 1 Environment Setup/Requirements and Creating a Session: https://arcserve.zendesk.com/hc/en-us/articles/202041319
Кроме того есть возможность экспорта/импорта сценариев в/из XML-файлы. То есть можно этот файл генерировать в вашем средстве автоматизации, а потом закачивать в Arcserve RHA.
Вот как по вашему, если у ленточной библиотеки есть веб-интерфейс с графикой — это уже несерьёзно?
А если у маршрутизатора надо писать «wr mem» то это индустриально, а если нажать на кнопку «Сохранить» на веб-интерфейсе, то это пошло?
Мне тоже нравится многое делать в командной строке. Но вот файл «sendmail.cf» считаю лично для себя неудобным. Предпочитаю заполнить формы какие-нибудь.
Короче говоря, каждый выбирает для себя, и всё хорошо в меру.
Это накладывает отпечаток на их способ работы. В частности, ownCloud периодически сканирует локальные файлы, чтобы понять, кого их них нужно отправить на сервер.
А Seafile, хоть и использует inotify для мгновенного оповещения о том, что с файлами что-то произошло, должен потом этот файл просканировать и определить, что же это было. Кроме того, он вносит дополнительное звено – репозитарий (как у Git), который должен сначала обновиться локально, а уж потом синхронизироваться с серверным.
Сравните это с модулем ядра (linux) или filter-driver в Windows, используемые Arcserve RHA, которые СРАЗУ знают, какие данные в файле изменились, а не пересканируют его, чтобы понять, что же произошло.
И скажите, как могут Seafile или ownCloud при их подходе в реальном времени реплицировать один большой файл, в который постоянно вносятся изменения (базу Exchange или Oracle или SQL, как в примере 3.2 из статьи?
После того, как на UNIX/Linux запускается сценарий репликации, мы монтируем файловую систему XOFS поверх существующей файловой системы. Команда ‘mount’ будет показывать 2 файловых системы: старую и новую (XOFS).
После монтирования XOFS поверх существующей файловой системы, пользователь сможет обращаться к файлам, просматривать каталоги… Однако, весь доступ происходит через XOFS. XOFS транслирует все вызовы в лежащую под ней файловую систему и возвращает результат тому, кто делал вызов.
Мы перехватываем всё, что касается создания, удаления, записи, mkdir, rmdir, change attr, mklink и т.д. Мы сбрасываем все эти события в журнал, вместе с данными, которые пишутся. Затем процесс в пользовательском режиме подхватывает этот журнал, переформатирует и пересылает на удлённую машину-реплику. Реплика получает, обрабатывает и повторяет действия из журнала.
Работа XOFS не зависит от того, какого типа файловая система находится под ней. XOFS просто транслирует вызовы и возвращает коды возврата. Но если появится новый тип файловой системы, для которой появятся новые системные вызовы, то XOFS также потребует доработки.
Set-Bookmark — установить закладку, на которую потом можно будет откатиться во времени
Suspend-Scenario / Resume-Scenario — приостановить/продолжить работу сценария (для выполнения сервисных работ, например)
Но я не сторонник радикальных мер. Что-то удобнее делать в командной строке, а что-то — в графическом интерфейсе. Поиск точки на временной оси, на которую нужно откатиться, мне однозначно удобнее делать в графическом интерфейсе.
Находится в RedHat и SUSE вот здесь:
/opt/CA/ARCserveRHA/kernel/fs/xofs.*
Подробнее см. http://documentation.arcserve.com/Arcserve-RHA/Available/R16-5/ENU/Bookshelf_Files/HTML/UL/Files_Installed_on_Red_Hat_and_Novell_SUSE_Linux_Enterprise.html
Но, конечно, всё хорошо в меру. Всегда найдётся какая-то система, которая может ввести в ступор. Приходит в голову игра «жизнь» на всех блоках данных диска…
Верно, не сталкивались.
Тут бы мне тихо и мирно закончить дебаты, но всё-таки не могу оставить без комментариев некоторые Ваши утверждения:
1. «В случае с ядерными ракетами, пример не корректный, так как там не проверяют миллиард раз в день сработает защита или нет.»
Я не ставил задачу сравнить вероятности. Очень надеюсь, что они несравнимы. Я лишь хотел указать, что вероятность сбоя, в принципе, отлична от нуля, и нельзя безапелляционно утверждать, что если вероятность сбоя (или коллизии в нашем случае) отлична от нуля, то доверия такой системе нет.
2. По поволу лотереи Powerball.
Думаю, что в расчет вероятности выигрыша джекпота вкралась ошибка.
Действительно, вероятность совпадения выигрышных чисел ДЛЯ ОДНОГО КОНКРЕТНОГО ЧЕЛОВЕКА равна 1/2^28 ( точнее, говорят, 1 к 292 201 338).
Но если купили миллион билетов, то вероятность выигрыша для одного человека не изменится, а вот вероятность того, что джекпот в принципе случится, станет больше в миллион раз, то есть будет равна… 1/292
То есть вероятность того, что я, мой сосед и мой племянник (то есть конкретные три человека) выиграют джекпот, действительно супер-низкая: 1/2^84, как Вы и сказали.
Но то, что джекпот выиграют три ПРОИЗВОЛЬНЫХ человека из миллиона купивших билеты, всего лишь 1/292^3.
Если куплено больше билетов, то вероятность ещё выше.
2. В вконце концов, дедупликация — это инструмент, который вы можете использовать, а можете и не использовать. Всё зависит от вашей собственной оценки рисков. Вы когда-нибудь ездили на автомобиле? Вы знаете, что погибнуть в автокатастрофе отлична от нуля и вовсе не ничтожна? Например, в России вероятность погибнуть в ДТП в течение года составляет около 0.00019.
Но вы всё-равно ездите. Оцениваете риск, но удобства от езды на автомобиле перевешивают опасность.
Так же и при дедупликации. Разница только в том, что риск автомобильной аварии осязаем, а риск коллизии миллиарда хешей ежедневно — ничтожен.
3. Что значит «ничтожен»? Выше я уже приводил примеры крайне маловероятных событий, вероятность которых выше, чем вероятность возникновения коллизии.
Но известно ли Вам, что вероятность того, что ошибочно будет произведён пуск ядерной ракеты также отлична от нуля? Это Вас не беспокоит? Вы просто уверены, что вероятность такого события ничтожна, хотя последствия чудовищны. А ничтожна — это насколько мала? когда для Вас число будет столь малым, что не будет вызывать беспокойства? 2^-80 достаточна? А 2^-160? А какая достаточна? Давайте выберем такой размер хеша, который будет соответствовать Вашим понятиям ничтожной вероятности.
Просто до нас уже кто-то прикинул вероятность коллизии для SHA-1 и решил, что это весьма небольшая вероятность, позволяющая использовать основанную на ней дедупликацию в промышленных системах.
В практикуме по страхованию жизни (легко ищется в интернете) можно прочитать, что вероятность прожить ещё один год для взрослого человека составляет около 0.99
Допустим, в вашем ИТ-департаменте работает 10 человек
Вероятность того, что в течение года все они дружно переплывут через реку Стикс, составляет
(1-0.99)^10 ~= 1/(2^7)^10 ~= 2^-70
То есть встретить коллизию SHA-1 вероятность гораздо меньше, чем всему департаменту ломануться на вечеринку к Одину.
Не кажется ли вам, что настолько маловероятное событие не заслуживает беспокойства о нём?
Есть люди, думающие, что число песчинок бесконечно. Я не говорю о песке в окрестности Сиракуз и других местах Сицилии, но о всём его количестве как в странах населённых, так и необитаемых.»
Архимед. Исчисление песчинок в пространстве равном шару неподвижных звёзд (Псаммит).
А, есть люди, которые считают, что 1/2^80 (вероятность коллизии SHA-1) – это обычное такое число, ничего особенного. И что встретить коллизию SHA-1 – обычное дело.
Сравнить же с этим числом можно (если не ошибаюсь) количество элементарных частиц в нашей галактике. А это куда больше, чем количество песчинок, подсчитанных Архимедом (2^80 против 10^63 – тысячи мириад чисел «восьмых»).
И вероятность коллизии меньше, чем вероятность того, что данные на жёстком диске случайно переманитятся, но CRC останется прежним! Представляете? Было «Я к вам пишу — чего же боле?» а стало «А теперь Горбатый! Я сказал – Горбатый!» только за счёт случайного перемагничивания.
Когда вероятность коллизии столь мала, что непонятно, увидим ли мы её когда-нибудь за всю историю существования человечества, то как-то трудно считать это ненадёжным решением. Возможно, серверы нашего тысячелетия расыпятся в прах, а коллизию мы так и не встретим. А может быть, натолкнёмся на коллизию уже завтра – со случайными величинами ни в чём быть уверенным нельзя.
В общем, всё зависит от вашего доверия/недоверия к тому, может ли возникнуть событие с ничтожно низкой вероятностью. И «ничтожно» — это куда меньше, чем найти две одинаковых песчинки не просто в окрестностях Сиракуз, но и во всей нашей галактике.
Лично мне приходилось сталкиваться с такими двумя случаями:
1. Копирование на ленточный привод годами проходило без ошибок. Ленты подписывались и складывались в шкафчик. Когда возникла необходимость восстановить данные, оказалось что ленты пусты. Ни разу никто не проверил, действительно ли на лентах что-то записано или нет.
2. Снова лента. Долгое время проводилось ежедневное резервное копирование сервера с базой данных Oracle. Операционная система стояла на диске C:, база данных — на диске D:. Когда сервер рухнул, оказалось, что копировался только бесполезный диск C:, про диск D: забыли при создании задания на резервное копирование.
Что я хочу этим сказать? Если бы люди хоть раз провели бы тестовое восстановление, то ошибки всплыли бы.
Точно также и с дедупликацией. Если есть регламент проверки восстановимости, то можно положиться на такую систему.
Для пущей уверенности держать несколько серверов хранения резервных копий и периодически переливать хранилище на отчуждаемый носитель (магнитную ленту).
А уж если бы коллизия SHA-1 кому-то попалась (необязательно нам), то такая новость сразу бы наводнила Интернет, и мы тут же увидели бы её на Хабре, да и во всяких википедиях тоже.