Статья сплошное бла-бла-бла и никакой конкретики. Бэкап в облако это одно, а вот быстрое восстановление из облака это другое.
Два абзаца, которые полностью противоречат друг другу:
Совмещение периферийного и мультиоблачного хранения – также непростая задача. Чтобы эти системы эффективно работали вместе, нужно знать объемы и типы данных, где и как эти данные будут собираться, передаваться и сохраняться. Для планирования процесса потребуется также знать, как долго должны храниться данные каждого типа, где, когда и сколько данных нужно будет передавать между различными системами и облачными платформами, как осуществляется их резервное копирование и защита.
И сразу же забыв, что написано выше:
Все это поможет администраторам свести к минимуму сложности, связанные с объединением периферийного и мультиоблачного хранения.
Вроде на NAS-ах таких процы относительно слабы и памяти немного.
Хотя CS 1.6 сервер когда-то и на пне втором запускался с 48 mb памяти. Держал максимум 4 игроков, при заходе 5 того все начинало дико лагать, т.к. CPU сервера уходил в планку на 100% загрузки :).
А вот с более современными играми, что то мне кажется не потянет их Synology.
Да на самом деле есть у них более подробное описание. Inline используется дедупликация с постоянным размером блока. Она менее требовательна к ресурсам, но и коэффициент дедупа меньший получается. SFP используются в постпроцессной дедупликации с блоком данных переменной длинны. Она выполняется соответственно в фоне в моменты наименьшей нагрузки, но требует дополнительного места под хранение недедуплицированных данных. Тип дедупликации назначается конкретному disk domain-у и может быть изменен на лету. Но в конкретный момент времени к конкретному disk domain-у применяется только один из алгоритмов дедупа. По умолчанию используется Inline дедуп с постоянным блоком. Дополнительно к уже дедуплицированным данным применяются еще и алгоритмы сжатия. Причем, что касается постпроцессной дедупликации с переменным блоком, там перед сохранением данных на диски выполняется предварительное Inline сжатие входящих данных, затем в фоне их постпроцессная дедупликация, после которой уже дедуплицированные данные дополнительно еще проходят через алгоритм постпроцессного сжатия. При Inline сжатии комбинируют LZ и Huffman entropy encoding. При постпроцессном сжатии дедуплицированных данных используются какие-то свои проприетарные deep compression algorithm.
В общепринятом понимании так и должно быть. Но всегда интересна конкретная реализация конкретного производителя, так как из нее могут вытекать как плюсы, так и минусы конкретного решения. А в данном случае не совсем понятно, что имелось в виду и как на самом деле работает, если приведенная схема из официальной документации, да еще и описана не корректно.
Хотя я все равно придерживаюсь мнения, что дедуп на первичных данных — это попытка натянуть "сову на глобус" и продать идею, что "так all-flash обойдется вам дешевле". Дедуп реально эффективен на бэкапах, на первичных данных при определенного рода авариях от него больше вреда, чем пользы.
Смотря что вы имеете в виду под записью на СХД. Запись в память контроллера или запись на диски. Судя по приведенной выше схеме запись на диски происходит после вычисления SFP. Постпроцесс это все же уже работа с данными записанными на диски.
Глобальный кеш: позволяет, чтобы LUN не имели владельцев. Каждый контроллер обрабатывает полученные запросы на чтение и запись, обеспечивая балансировку нагрузки между контроллерами.
Тут если зарыться в документацию тоже не все так просто. Внезапно, как раз из-за отсутствия Shared Frontend и FIMs модулей режим active-active для контроллеров СХД будет корректно работать только при установленном на хосте UltraPath (MPIO) от Huawei. Так как он начинает вместо FIMs модулей определять в какой порт на front-е отправить I/O, что бы не пришлось выполнять его перенаправление внутри контролера СХД в другую VNode на другой CPU или даже на другой контроллер для обработки.
А с точки зрения владения луном, на этих массивах все происходит несколько ниже уровнем. Если упростить, то по факту различными кусочками одного луна в конкретный момент времени владеют разные CPU обоих контроллеров. Т.е. если I/O случайно прилетит не к тому CPU (не к той VNode), то что бы не менять владельца, все равно придется его перенаправить в правильный VNode, что больше похоже на режим ALUA и может выливаться в дополнительные задержки ввода/вывода. По факту получается, что лучше не использовать нативный MPIO в OS, а всегда ставить вендорский UltraPath.
Если встроенная дедупликация не может быть выполнена с высокой вероятностью, система вычисляет «аналогичный» отпечаток (SFP) данных и вставляет его в таблицу «возможностей». Затем система сжимает пользовательские данные, записывает сжатые данные в пул хранения и возвращает сообщение об успешной записи.
Т.е. хост все это время ждет? Или имеется ввиду, что возвращает сообщение контроллерам СХД? Вроде как обычно ack возвращается хосту после записи данных в кэш контроллера СХД. Или я что то не так понял или эта СХД работает по другому?
Много обещающее название, а в статье какая-то лабуда. Что в итоге то хотели сказать? Покупайте наши СХД? Тогда как-то не убедительно вышло. И причем тогда?
Спасибо за статью! Наконец-то в этом корпоративном блоге что-то полезное. А не про очередной "новый и конечно же самый крутой ноутбук". Не то что бы технология новая и все то же самое уже давно и стабильно работало на поколении EMC VNX2 :). Но молодцы, что корректно перенесли функционал при смене поколений СХД и смене базовой OS на контроллерах.
Жалко, что вы рассказали только про то, что и так можно найти в документации по продукту. Интересно было бы понимать хотя бы в общих чертах как рассчитывается температура слайсов, как и где выделяется пространство на тирах при создании новых лунов и росте тонких лунов на пуле. Как решается вопрос при нехватке места на быстром тире под все горячие данные. Что происходит, когда в одном тире есть RG с различным количеством дисков (что не рекомендовано, но у заказчиков случается :) ). Совсем не осветили вопрос про минимально необходимое свободное место на тирах, которое нужно что-бы тиринг в принципе работал. Не то что бы все это жизненно необходимо :), но для общего понимания внутренних механизмов работы пула было бы неплохо знать.
Ну тут вам решать конечно, но и у того же HPE в блэйдах можно было ставить по две mezzanine карты, насколько помню. В том числе IB в последних поколениях.
Коллеги вас правильно поправили про Isilon. Может стоит лучше в сторону нормальных вычислителей копать? Чем искать нестандартный сторадж с IB наружу? По крайне мере из того что мне попадалось из A брендов по 1U серверам, у всех через райзер как минимум две PCI-E карты дополнительных поддерживалось. Одна с полноразмерной планкой, вторая с короткой.
Для меня основная проблема, что большей частью эти переводы и новости суть мусорные. И такой контент по личным ощущениям последнее время занимает как минимум 70-80% Хабра. Особенно доставила последняя истерия с NGNIX, когда 3 из 4 новых статей тут были про эту ситуацию и по сути не несли какой либо полезной информации.
Статья, к сожалению, сплошной маркетинг и вода. Из реально полезного разве что ссылки после статьи.
Отдельная песня это картинка с первым поколением Unity. Ваши маркетологи же сделали вот такое:
На худой конец вот такое (могли бы и доработать и подставить 380/380F и виртальный аплайнс для чего обычного paint-а достаточно):
Абсолютно все. Подписи пространны и без едениц измерения. В чем измеряются значения на графиках? В штуках, в попугаях, в долларах, в рублях? Из контекста можно только догадываться. Но полной уверенности нет.
То что пару фриков использует какую то ось, не говорит что она жива.
Надеюсь вы это не про себя :).
Список есть в комментариях выше, но так как мы с вами похоже вошли в цикл, то желаю вам всего хорошего и поменьше впадать в крайности :).
За сим откланиваюсь из этого треда.
Статья сплошное бла-бла-бла и никакой конкретики. Бэкап в облако это одно, а вот быстрое восстановление из облака это другое.
Два абзаца, которые полностью противоречат друг другу:
И сразу же забыв, что написано выше:
Вроде на NAS-ах таких процы относительно слабы и памяти немного.
Хотя CS 1.6 сервер когда-то и на пне втором запускался с 48 mb памяти. Держал максимум 4 игроков, при заходе 5 того все начинало дико лагать, т.к. CPU сервера уходил в планку на 100% загрузки :).
А вот с более современными играми, что то мне кажется не потянет их Synology.
Много слов, минимум конкретики = ожидание, что в вебинаре будет 80-90% маркетингового булшита. Жалко на это тратить время. Как-то так.
Да на самом деле есть у них более подробное описание. Inline используется дедупликация с постоянным размером блока. Она менее требовательна к ресурсам, но и коэффициент дедупа меньший получается. SFP используются в постпроцессной дедупликации с блоком данных переменной длинны. Она выполняется соответственно в фоне в моменты наименьшей нагрузки, но требует дополнительного места под хранение недедуплицированных данных. Тип дедупликации назначается конкретному disk domain-у и может быть изменен на лету. Но в конкретный момент времени к конкретному disk domain-у применяется только один из алгоритмов дедупа. По умолчанию используется Inline дедуп с постоянным блоком. Дополнительно к уже дедуплицированным данным применяются еще и алгоритмы сжатия. Причем, что касается постпроцессной дедупликации с переменным блоком, там перед сохранением данных на диски выполняется предварительное Inline сжатие входящих данных, затем в фоне их постпроцессная дедупликация, после которой уже дедуплицированные данные дополнительно еще проходят через алгоритм постпроцессного сжатия. При Inline сжатии комбинируют LZ и Huffman entropy encoding. При постпроцессном сжатии дедуплицированных данных используются какие-то свои проприетарные deep compression algorithm.
В общепринятом понимании так и должно быть. Но всегда интересна конкретная реализация конкретного производителя, так как из нее могут вытекать как плюсы, так и минусы конкретного решения. А в данном случае не совсем понятно, что имелось в виду и как на самом деле работает, если приведенная схема из официальной документации, да еще и описана не корректно.
Хотя я все равно придерживаюсь мнения, что дедуп на первичных данных — это попытка натянуть "сову на глобус" и продать идею, что "так all-flash обойдется вам дешевле". Дедуп реально эффективен на бэкапах, на первичных данных при определенного рода авариях от него больше вреда, чем пользы.
ну либо схему китайцы неправильно нарисовали :)
Смотря что вы имеете в виду под записью на СХД. Запись в память контроллера или запись на диски. Судя по приведенной выше схеме запись на диски происходит после вычисления SFP. Постпроцесс это все же уже работа с данными записанными на диски.
Ну из этой схемы этого не видно. Возможно в тексте описано словами :).
Тут если зарыться в документацию тоже не все так просто. Внезапно, как раз из-за отсутствия Shared Frontend и FIMs модулей режим active-active для контроллеров СХД будет корректно работать только при установленном на хосте UltraPath (MPIO) от Huawei. Так как он начинает вместо FIMs модулей определять в какой порт на front-е отправить I/O, что бы не пришлось выполнять его перенаправление внутри контролера СХД в другую VNode на другой CPU или даже на другой контроллер для обработки.
А с точки зрения владения луном, на этих массивах все происходит несколько ниже уровнем. Если упростить, то по факту различными кусочками одного луна в конкретный момент времени владеют разные CPU обоих контроллеров. Т.е. если I/O случайно прилетит не к тому CPU (не к той VNode), то что бы не менять владельца, все равно придется его перенаправить в правильный VNode, что больше похоже на режим ALUA и может выливаться в дополнительные задержки ввода/вывода. По факту получается, что лучше не использовать нативный MPIO в OS, а всегда ставить вендорский UltraPath.
Тут или ошибка или неточность:
Т.е. хост все это время ждет? Или имеется ввиду, что возвращает сообщение контроллерам СХД? Вроде как обычно ack возвращается хосту после записи данных в кэш контроллера СХД. Или я что то не так понял или эта СХД работает по другому?
Много обещающее название, а в статье какая-то лабуда. Что в итоге то хотели сказать? Покупайте наши СХД? Тогда как-то не убедительно вышло. И причем тогда?
Спасибо за статью! Наконец-то в этом корпоративном блоге что-то полезное. А не про очередной "новый и конечно же самый крутой ноутбук". Не то что бы технология новая и все то же самое уже давно и стабильно работало на поколении EMC VNX2 :). Но молодцы, что корректно перенесли функционал при смене поколений СХД и смене базовой OS на контроллерах.
Жалко, что вы рассказали только про то, что и так можно найти в документации по продукту. Интересно было бы понимать хотя бы в общих чертах как рассчитывается температура слайсов, как и где выделяется пространство на тирах при создании новых лунов и росте тонких лунов на пуле. Как решается вопрос при нехватке места на быстром тире под все горячие данные. Что происходит, когда в одном тире есть RG с различным количеством дисков (что не рекомендовано, но у заказчиков случается :) ). Совсем не осветили вопрос про минимально необходимое свободное место на тирах, которое нужно что-бы тиринг в принципе работал. Не то что бы все это жизненно необходимо :), но для общего понимания внутренних механизмов работы пула было бы неплохо знать.
Ну тут вам решать конечно, но и у того же HPE в блэйдах можно было ставить по две mezzanine карты, насколько помню. В том числе IB в последних поколениях.
Коллеги вас правильно поправили про Isilon. Может стоит лучше в сторону нормальных вычислителей копать? Чем искать нестандартный сторадж с IB наружу? По крайне мере из того что мне попадалось из A брендов по 1U серверам, у всех через райзер как минимум две PCI-E карты дополнительных поддерживалось. Одна с полноразмерной планкой, вторая с короткой.
Это шутка? Если нет, то расскажите какую систему с IB наружу (и зачем?) и большей дисковой плотностью на юнит вы имели в виду. Прямо интересно.
Для меня основная проблема, что большей частью эти переводы и новости суть мусорные. И такой контент по личным ощущениям последнее время занимает как минимум 70-80% Хабра. Особенно доставила последняя истерия с NGNIX, когда 3 из 4 новых статей тут были про эту ситуацию и по сути не несли какой либо полезной информации.
Статья, к сожалению, сплошной маркетинг и вода. Из реально полезного разве что ссылки после статьи.
Отдельная песня это картинка с первым поколением Unity. Ваши маркетологи же сделали вот такое:
На худой конец вот такое (могли бы и доработать и подставить 380/380F и виртальный аплайнс для чего обычного paint-а достаточно):
Зачем в статье про Unity XT это? :)
Абсолютно все. Подписи пространны и без едениц измерения. В чем измеряются значения на графиках? В штуках, в попугаях, в долларах, в рублях? Из контекста можно только догадываться. Но полной уверенности нет.
Графики без указания едениц измерения — это жуть какая-то.
Надеюсь вы это не про себя :).
Список есть в комментариях выше, но так как мы с вами похоже вошли в цикл, то желаю вам всего хорошего и поменьше впадать в крайности :).
За сим откланиваюсь из этого треда.