Так ли незаменимы магнитные ленты для бэкапа? Часть 3
??так, в двух предыдущих постах серии я попытался вас убедить, что на сегоднящний день устройства для записи на магнитную ленту (стримеры или ленточные библиотеки, “tape library”) часто значительно проигрывают в удобстве, цене и надежности решения простым и эффективным дисковым NAS-массивам на дисках SATA.
Такие массивы:
- Обеспечивают приемлемую надежность, а также, в случае организации RAID, непрерывность работы в случае сбоя диска.
- На них возможна организация непрерывного контроля целостности данных, своевременная упреждающая индикация возможных сбоев через SMART или иные средства контроля.
- Относительная простота и доступность служб восстановления данных с поврежденных или вышедших из строя дисков (никогда не слышал про такие в отношении поврежденных лент).
- Эффективно экономят место за счет не только компрессии, но и значительно более выгодной по результатам дедупликации.
- Обеспечивают произвольный доступ, в том числе одновременно на запись и чтение, для произвольного количества хостов, и независимость скорости бэкапа от стабильности потока записи с хоста
- Стандартность, гибкость и легкодоступность “расширения емкости”, быстрота и дешевизна процесса расширения, не связана с необходимостью покупать “библиотеку” и менять стратегии бэкапа.
- Отсутствие у решения проблем “механического” характера и открытой “точной механики”.
- Недороги - стоимость терабайта на сегодня снизилась до 76$ за диск , против примерно 45$ за картридж LTO-4 на 800GB некомпрессированного объема, к которому, для его использования, необходим еще как минимум стример за 2000-2500$, а при превышении емкости картриджа авточенджер или библиотека, стоимостью 4 - 15 тысяч $.
Обычно, когда я начинаю рассказывать про преимущества дискового хранения резервных и архивных копий, мне всегда приводится одно возражение: “Когда мы делаем копии на ленту, то мы можем легко вынуть сделаную копию из библиотеки лент, и послать ее в удаленное хранилище, на случай серьезной потрери данных на оснвном сайте. А как это сделать в случае дискового массива? Ведь просто вынуть диск из RAID нельзя, значит оффлайн-хранение в случае дисков невозможно!”
Я не зря начал эту серию с поговорки “когда в руке молоток, то все кругом кажется гвоздями”. Эта поговорка иронизирует над ситуацией, когда выбор инструмента начинает диктовать выбравшему дальнейшее решение. Путь выбора инструмента для решения, вместо подхода “от задачи”, приводит нас, зачастую, к неоптимальному решению, только оттого, что имеющийся инструмент умеет “только вот так и больше никак”.
Да, нельзя вынуть жесткийдиск из RAID и отвезти его в хранилище. Но это просто попытка решить задачу с непригодным для ее решения подходом, ограничив себя выбором неподходящего инструмента.
Давайте попробуем решить задачу “оффлайн бэкапа”, двигаясь “от задачи”, а не от возможностей инструмента, не станем забивать шурупы молотком, только оттого, что он у нас уже оказался в руке, и найдем оптимальное решение.
Для чего же делается оффсайт-хранение данных? Прежде всего, для максимально быстрого восстановления, причем не просто “восстановления данных”, а “восстановления работоспособности бизнеса”, в котором “восстановление данных” есть только одна из подзадач. Хранение же копии данных вне территории основного сайта бизнеса защитит данные нашего бизнеса от потери их на территории основного сайта по тем или иным причинам. Но целью этого хранения является не столько сохранность данных, сколько сохранность работоспособности бизнеса. ??менно работоспособность бизнеса и есть для нас решающий критерий.
Поможет ли нам в решении этой задачи хранение картириджа с бэкапом недельной давности в банковской ячйке, в том случае, если мы по той или иной причине потеряли данные, а зачастую и оборудование на первичном сайте? Очевидно что нет. Нам нужно, по крайней мере, быстро найти для этой ленты устройство считывания, и куда-то восстановить данные с этой ленты. Напомню, потеря всего основного сайта вполне реальная перспектива, которую мы должны учитывать, раз уж мы решаем хранить резервные данные удаленно. При этом сами по себе, как вы видите, данные ленты для нас ничуть не помогают решить нашу задачу – восстановления работоспособности бизнеса. Тем более, если состояние данных в этой копии, например, недельной давности (как правило offline baсkup редко делается с более частой ротацией). Часто этот момент также игнорируется.
Теперь давайте посмотрим, как можно решить поставленную задачу используя для хранения резервных копий дисковые массивы.
Практически любой серьезный дисковый массив (а при выборе не-“аппаратного” устройства - множество программных решений, от коммерческих до rsync) сегодня умеет производить так называемую “репликацию”, то есть синхронизацию своего содержимого по сети с другим дисковым массивом. При этом на удаленный дисковый массив передаются только изменения, а в случае использования асинхронной репликации, это также снижает требования к каналу передачи данных, пусть и за счет “актуальности” данных. все равно это будут секунды, минуты, может быть часы, но никак не дни, как в случае offsite backup на магнитных лентах.
Сколько же способен пропустить через себя данных канал репликации? Давайте, для примера, возьмем достаточно “бытовой” канал в internet, с полосой пропускания в 10Mbit.
Нетрудно посчитать, что канал полосой 10Mbit за 24 часа может пропустить сквозь себя около 100 гигабайт.
Допустим, что на накладные расходы, такие как VPN-шифрование и возможные снижения полосы пропускания, ухудшат данные показатели, думаю, что рассчитывать на 75% от “паспортной” пропускной будет вполне резонно. Это около 75 гигабайт данных в сутки. Это, надо сказать, довольно немалый объем, не забывайте, что речь идет о измененных за сутки данных, а не о данных вообще, так как передаются фактически только “инкрементальные копии”, измененные блоки. При этом, за счет асинхронности репликации мы не ограничиваем возможностями этого канала нашу рабочую систему. Допустим, наши изменения данных в пиковое время дня первышают пропускную способность такого канала. Ничего страшного, просто на какое-то время увеличится data gap, когда закончится рабочий день и количество записываемых на первичную систему изменений снизится, реплицированный сторадж “догонит” основное хранилище. Все равно этот gap будет меньше, чем при записи данных ночью на ленту и вывоз ее утром курьером в удаленное хранилище. При этом мы еще и избавляемся от “участия человека” как, на практике, наиболее слабого звена, организуя процесс автоматически.
Таким образом, “оффлайн бэкап” в случае дисковых хранилищ называется “удаленная репликация”. Просто?
Как в первом, так и во втором случае мы получаем копию наших данных в недоступном форсмажорным стихийным бедствиям месте, однако, при этом, во первых, такая копия является гораздо более “актуальной” по отношению к рабочим, основным данным, во вторых – данные с нее могут быть непосредственно использованы при восстановлении работоспособности бизнеса, например перевезя, в случае необходимости, резервную систему с репликой на основной сайт и запустив доступ “в пожарном порядке” к данным непосредственно с нее. Зачастую “быстрый старт” после аварии бывает критически важен не только для репутации.
Впоследствии же на базе сетевой инфраструктуры репликации, использовав уже вложенные в нее деньги, можно начать строить полноценное disaster recovery & busines continuity solution. О необходимости такого решения при организации бизнеса сейчас задумываются все больше компаний.
Плюсы “удаленной репликации” перед “оффлайн-хранением носителя”:
- “Резервная копия” при удаленной репликации “моментальна”. В случае асинхроной репликации отставание от состояния данных первичного сайта составляет обычно от секунд до единиц минут, в отличие от дней, в случае копии ленты. Соответственно “актуализация”, то есть приведение к “текущему состоянию”, например базы данных, которая осуществляется “накатом” archive redo logs, занимает не часы и дни, а минуты и секунды.
- “Резервная копия” данных на удаленном реплицированном хранилище доступна не “потенциально”, как в случае картриджа с лентой, а вполне физически. В случае потери данных вместе с оборудованием первичного сайта, в результате какого-то стихийного бедствия, такого как пожар, наводнение, или “проведение следственных мероприятий”. В случае необходимости реплицированное хранилище можно вернуть на первичный сайт и практически немедленно, пусть и с ограничениями, связанными, например, с возможной меньшей производительностью резервного хранилища, возобновить работу с текущим состоянием данных.
- Стоимость канала передачи данных стабильно снижается, а его полоса пропускания – расширяется, гарантируя в будущем все более быструю репликацию, в соответствии с растущими потребностями бизнеса, и, со временем, все улучшая характеристики выбранного решения.
- В дальнейшем, на базе уже построенной инфраструктуры репликации можно построить и полноценное катастрофоустойчивое решение с двумя рабочими сайтами. Таким образом текущие, нынешние вложения в канал репликации, для решения защиты данных на базе удаленной репликации, могут быть использованы в будущем при создании катастрофоустойчивой системы, как его уже реализованной части (это то, что наши англоязычные коллеги называют “investment protection”).
Несмотря на то, что блог, который я пишу, преимущественно занимается продуктами компании NetApp, в трех вышедших постах под заглавием “Так ли незаменимы магнитные ленты для бэкапа” я рассматривал задачу резервного копирования “в общем”, без привязки к каким-то конкретным решениям и технологиям NetApp. В следующей части мы приблизимся к основной теме моего блога, добавим конкретики, и рассмотрим возможности, которые предлагают для организации “дискового резервного хранения” продукты компании NetApp, которыми я занимаюсь.
PS UPD: “Storage Newsletter reports that Tape Drive and Media Revenues decreased by 25% in 2009. The data comes from a report by the Santa Clara Consulting Group.” сообщает в своем блоге Storaje Mojo Робин Харрис.
Все оно конечно в теории хорошо и правильно, только стоимость DRS как-то в разы, да что там, на порядки выше стоимости организации вывоза лент. Почему здесь Вы учитываете только СХД? если основной сайт физически разрушен, то удаленный массив ситуацию без соответствующих серверов не спасет, ну никак. Компании же, которые могут себе позволить DRS, имеют четкую политику резервного копирования \ архивного хранения, и там все используется в меру. А уж стоимость лицензии репликации на массив довольна не мала, канал связи тоже не бесплатен, и тд и тп.
Сам цикл статей вполне себе неплох, но его ни в коем разе нельзя рассматривать в том ключе, в каком он назван.
Ivan, я ничего не говорю о стоимости DRS, вы снова невнимательно меня читаете.
DRS как рещение с решением “вывоза лент” никак не соотносятся, сравнивать их цену бессмысленно.
?? даже удаленная репликация никак не соотносится с DRS. Она соотносится с вывозом.
?? вот тут цены уже можно сравнивать, хотя, о чем собственно вся статья, цена в данном случае не определяет. Определяет успешность восстановления работоспособности, которая в случае репликации принципиально выше.
Давайте вообще не будем говорить о DRS в этом аспекте. Я как практик в этой области очнь хорошо представляю себе что значит и сколько стоит разработка и запуск Disaster recovery site, это тема не просто для отдельной статьи, а для отдельного блога. Давайте останемся в предложенном формате.
Существуют ситуации, когда нет удаленного хранилища и нет канала связи. Да и “бытовой” канал в internet, с полосой пропускания в 10Mbit в регионах не такая уж дешевая штука. В этом случае, только лента способна хоть что-то сохранить при катастрофе.
> Существуют ситуации, когда нет удаленного хранилища и нет канала связи.
Да много какие ситуации существуют, бывает когда и электричества нет, а вода - из колодца ведром. Но давайте все же не рассматривать маргинальные для сегодняшнего IT случаи.
Что же касается “недешевой штуки” - так безопасность никогда не была “дешевой штукой”, где угодно. Тут уже, как всегда, руководство решает, готово ли оно “рискнуть” и сэкономить за счет большего риска потери бизнеса, или нет. ?? это уже вопрос в области бизнеса, и бизнес-рисков, а не IT.
Ну, скажем так, считали мы(я) стоимость размещения массива NetApp на удаленной площадке для репликации данных, на круг вышла цена только железа + лицензии под 400 тыс уе, на массив с 4ТБ данных (правда не на SATA дисках), это без стоимости аренды \ организации канала и аналогичных затрат (как то помещение), при этом полноценный DRS - уже под 800 уе (опять же софт и лицензии), без учета сопутствующих расходов, бизнес решил, что суточная потеря данных - некритична, да и недельная потеря так же (по нашему проекту).
По скорости работы с лентой - 130ГБ, слить на ленту и проверить запись - 55 минут.
ЗЫ: Вообщем повторюсь - сам цикл, абсолютно правильный, но название некорректно.
ЗЗЫ: Читаю то Вас давно, просто как-то не писал, а тут за живое задели :)
> но название некорректно.
??нтересно, чем же некорректно название, и какое бы вы название предложили :)
> считали мы(я) стоимость размещения массива NetApp
Ну во первых, несмотря на то, что блог про NetApp, ни в одной из трех статей цикла пока про NetApp не упоминается, задача рассматривается “в целом”.
Во вторых считать можно по разному. “вы” в данном случае, пресейл в партнере или сторона клиента? Уверены, что рассмотрели все возможные варианты построения?
> полноценный DRS - уже под 800 уе
Если говорить про “полноценный”, то боюсь не в 800 тысяч, а в 8 миллионов, да и то, есть сомнения.
> бизнес решил, что суточная потеря данных - некритична, да и недельная потеря так же
Ну есть такие бизнесы, которым некритична и вообще потеря данных, их немало, более того, в России немало бизнесов изначально так планируется ;)
Еще раз призываю оставить в стороне маргинальные варианты.
> ??нтересно, чем же некорректно название, и какое бы вы название предложили :)
Ну, я статей не пишу, сразу так в голову и не приходит
> Ну во первых, несмотря на то, что блог про NetApp, ни в одной из трех статей цикла пока про NetApp не упоминается, задача рассматривается “в целом”.
> Во вторых считать можно по разному. “вы” в данном случае, пресейл в партнере или сторона клиента? Уверены, что рассмотрели все возможные варианты построения?
Хех, я тут с двух сторон, представитель партнера у клиента, я весь этот комплекс внедрял и поддерживаю. Варианты, конечно не все, политика, знаете ли :)
> Если говорить про “полноценный”, то боюсь не в 800 тысяч, а в 8 миллионов, да и то, есть сомнения.
В России можно и за 20 построить, я ж писал, это стоимость железа с лицензиями, без инфраструктуры (!)
> Ну есть такие бизнесы, которым некритична и вообще потеря данных, их немало, более того, в России немало бизнесов изначально так планируется ;)
> Еще раз призываю оставить в стороне маргинальные варианты.
Ну, тут клиент как бы не такого плана, перестраховка во всем и везде.
Я, на самом деле, уже далеко не первый раз сталкиваюсь с требованием именно бизнеса к копированию на ленту, и причем в довольно не маленьких компаниях мирового масштаба.
Ну а название, все же что-то типа “Эволюция стратегии резервного копирования”, ибо бекап это как-то ну не совсем что ли верно.
А, вот еще, сколько работаю с резервным копированием, пришел к выводу, что инкрементального копирования лучше избегать там, где его можно избежать. Если есть возможность делать full то делаю его.
> Я, на самом деле, уже далеко не первый раз сталкиваюсь с требованием именно бизнеса к копированию на ленту
В этом-то как раз ничего удивительного, бизнес “не шарит” и предпочитает использовать то, к чему привыкли (вариант: “то, что используют компании списка Fortune500″), на то в компании и есть CIO, чтобы “шарить” в IT.
> А, вот еще, сколько работаю с резервным копированием, пришел к выводу, что инкрементального копирования лучше избегать там, где его можно избежать. Если есть возможность делать full то делаю его.
Верно. Еще буду про это писать, цифрой “три” явно не удалось ограничиться.
?? это, кстати, тоже плюс для дискового копирования с репликацией, по крайней мере в релизации NetApp: репликация и снэпшоты инкрементальны по объемам передаваемых данных, и по занимаемому объему, а вот копия при этом получается полная.
Ну, еще момент, перегнать по сети 2-3 ТБ данных это жесть, так сказать, а на ленте - 4 картриджа - экспресс почта и все дела
Про снепшоты верно конечно, тут возразить нечего, единственно убивает (лично в моей ситуации) ограничение в 255 снепшотов на том.
Ivan, простите, но мне кажется, Вы считали клиенту не тот вариант.
Дано: недельная потеря данных некритична (хотел бы я послушать это из уст главбуха крупного предприятия!), $400k - неподъёмная сумма.
Ваш ответ: репликация на NetApp на не-SAS дисках! Т.е. решение, которое отличается:
1)энтерпрайзовой ценой - т.е. цена вообще не должна учитываться, если взялись считать такое решение;
2)минимальным лагом - миллисекунды, я полагаю [при требовании - недели];
3)максимальной надежностью [для ограниченного в средствах бэкапа не нужно];
4)максимальными “фичами” [в условиях отсутствия задачи DRS и критичности цены опять же только минус]
Entry-level стандартный сервер 5U с пачкой SATA-дисков (для 4ТБ можно даже не 5U) это именно то, что доктор прописал. Тем более, если на основной площадке NetApp, то снэпшоты радикально облегчат репликацию. Стоимость минимальна, разместить можно в любом хорошем датацентре, начиная от ближайшего провайдера/хостера с (почти)бесплатным трафиком, и вплоть до зарубежной площадки, заведомо ограждённой от стихийного бедствия “следственные действия” - собрать сервер с 4ТБ ЖД смогут удалённо в любой хостинговой конторе, позволяющей заказывать свою конфигурацию.
> Entry-level стандартный сервер 5U с пачкой SATA-дисков (для 4ТБ можно даже не 5U) это именно то, что доктор прописал
А что делать когда 4TB это очень мало? Когда 1 Full Backup занимает 9 LTO4 лент?
?? по поводу предыдущих постов
>Невозможность контроля состояния записанных данных при хранении (повреждения и невозможность считывания данных, зачастую обнаруживаются только при попытке восстановления данных в час “Ч”)
На лентах тоже есть что-то наподобие scrubbing’а
Этот процесс называется рекламация, и проводится после ежедневного бэкапа
murzic, читайте пост Ivan. 4ТБ это его цифра. 16ТБ 2-гиговыми SATA забивается в 5U даже не сильно оптимизированный под max число ЖД. Больше - тоже не проблема - было б что бэкапить. Лента - давно уже не самое объёмное хранилище данных - меряться объёмами с SATA лентам уже поздно.
> На лентах тоже есть что-то наподобие scrubbing’а
Это работает только для текущей, используемой ленты, проблема-то в том, что это не работает для пары десятков мирно лежащих лент с данными, которые там то ли есть, то ли уже нет, пока лента не загружена в драйв и не начато чтение, узнать это нельзя.
> А что делать когда 4TB это очень мало? Когда 1 Full Backup занимает 9 LTO4 лент?
А, вот видите, опять “проблема молотка”. Почему делается Full, если можно делать Incremental? Потому что с Incremental, да еще если он лежит на нескольких лентах, восстанавливаться очень долго.
Но в случае дисков этой проблемы с Incremental просто нет. Тогда зачем делать Full, если Incremental также хорошо работает как и Full, только занимает горздо меньше места?
> единственно убивает (лично в моей ситуации) ограничение в 255 снепшотов на том.
255 снэпшотов (вернее 245 их) на том позволяют организовать классическую ротацию бэкапов “как на ленте” длиной в 7 лет.
Если есть логин в блоги NetApp Community:
http://communities.netapp.com/community/products_and_solutions/netapp_integrated_data_protection/blog/2010/06/09/is-tape-really-required
Классический пример ситуации (просто первый под руками):
http://vmind.ru/2010/02/16/bekapy-eto-nashe-vse/
> Это работает только для текущей, используемой ленты, проблема-то в том, что это не работает для пары десятков мирно лежащих лент с данными, которые там то ли есть, то ли уже нет, пока лента не загружена в драйв и не начато чтение, узнать это нельзя.
Погодите, только что в статье вы рассказали про удаленную площадку с дисковыми полками. Так что давайте оба решения ставить в одинаковые рамки. Считаем что у нас удаленная площадка с ленточным роботом. ?? ленты не вытаскиваются из робота (кроме архива на 50 лет :) что кстати на дисках сделать проблематично).
В этом случае и на ленты можно делать нормальны инкрементальный бэкап. ?? в этом случае полка на 100 лент
1. Выигрывает по цене при равенстве объема
2. Получаем дополнительную фишку с выемкой (если требуется)
3. Занимает меньше места в стойке (если площадка куплена у провайдера, то этот параметр важен)
Я понимаю, что все меняется, но Вы уж определяйтесь как-нибудь.
Отсюда:
http://blog.aboutnetapp.ru/archives/51
“Еще одним существенным плюсом лент является возможность просто организовать распределенное, “оффлайновое” хранилище информации. Если из ленточной библиотеки достаточно просто вытащить и унести в надежное место один или несколько картриджей, то сделать то же самое с дисковым массивом совсем непросто.
Поэтому в областях длительного объемного хранения и offsite storage vaulting (хранения данных вне основной площадки обработки) крупные ленточные библиотеки все еще не имеют альтернатив.”
murzic:
”
В этом случае и на ленты можно делать нормальны инкрементальный бэкап. ?? в этом случае полка на 100 лент
1. Выигрывает по цене при равенстве объема
2. Получаем дополнительную фишку с выемкой (если требуется)
3. Занимает меньше места в стойке (если площадка куплена у провайдера, то этот параметр важен)”
У Вас нолик не лишний? “полка” на 100 лент это 18U. Если Вам реально нужно 80ТБ бэкапа, то бюджет вообще позволит о мелких тратах, типа rack space у провайдера не думать, а смотреть, что удобней. Кстати тот же объём вот сходу прикинул на трёх Fujitsu ETERNUS JX40 и 1U сервере в 7U утопчется на SATA.
Кто у кого “Выигрывает по цене при равенстве объема” хотелось бы не голословно, а на примерах, причем с учетом сказанного в статьях romx - другой стратегии бэкапа.
> Я понимаю, что все меняется, но Вы уж определяйтесь как-нибудь.
Вот именно, что все меняется.
“Только идиоты не меняют своих убеждений” приписывается Черчиллю.
Korj - 400 уе вполне подъемная сумма :), ибо требовалось именно нетапп, т.к. оно уже есть у нас. Просто пока отложили эту идею. В текущей ситуации ленты вполне подходят. Но описывать долго, тут довольно нестандартное архитектурное решение. Да и я тут со стороны партнера - пресейл инженер, со стороны клиента - администратор комплекса.
В общем ждем продолжения, romx.
Ivan, Вы уж определитесь, что Вы сказать хотите. ??значально Вы как бы оппонировали статье, мол $400k вышло, бизнес сказал “к чертям!” и взял ленточку. Возникли вопросы к такому предложению - теперь у Вас вроде как и деньги появились, просто мол “отложили”, и с неба обязательное требование “только NetApp”, хотя мне лично абсолютно непонятно требование иметь продакшен систему и удалённый ящик с байтами обязательно на одной ОС - удобно, да, но упираться в это вплоть до замены СХД ленточкой…
Кстати по NetApp only - FAS2020 с необходимыми лицензиями и SATA дисками вышел бы отнюдь не в $400k - на нулик меньше imho. Ставить что-то большее для бэкапа 4ТБ(130ГБ?) смысл неочевиден…
Библиотека = 5U
Expansion = 9U
??того: 115 LTO4 = 14U ~ 115TB
Fujitsu ETERNUS JX40
я так понимаю что там диски 2,5″ следовательно максимальная емкость 500Gb
??того: 24диска * 3 полки = 72 Диска * 500Gb = 36Tb (Всего)
?? это без учета таких штук, как RAID и Spare
Korj - решлили не ограничиваться только СХД, будет полноценный DRS (но потом :)), ибо просто за массив действительно немало. Но и ленты никто не выкидывает, ибо они по стратегии требуются. Если Вы заметили, я не столько оппонирую статье, сколько не согласен с названием статьи.
> не согласен с названием статьи
То есть вы считает, что для бэкапа ленты - незаменимы? ;)
Ну, хорошо, что именно Вы вкладываете в понятие “бекап”?
> Ну, хорошо, что именно Вы вкладываете в понятие “бекап”?
Говорилось в части первой.
Завтра еще раз перечитаю, видать подзабыл, ну а сейчас уже время, пора с работы :)
ЗЫ: дико неудобно, что оповещения на ящик нет об ответе
murzic:
Т.е. нулик у Вас не лишний. Тогда я 100% не вижу смысла говорить о цене RU при таких объёмах. Тут если что и считать, так полную цену всего. Но ради мозговой гимнастики, продолжу… :)
>Библиотека = 5U
>Expansion = 9U
>
>??того: 115 LTO4 = 14U ~ 115TB
??нтереса ради, что за модель? Почему 115ТБ, а не 92? Поставим нестандартные картриджи, чтоб ещё веселее в случае чего было искать, куда их вставить?
>Fujitsu ETERNUS JX40
>я так понимаю что там диски 2,5″ следовательно максимальная емкость 500Gb
>??того: 24диска * 3 полки = 72 Диска * 500Gb = 36Tb (Всего)
Ну производитель пишет о 72ТБ, видимо имеет в виду 1ТБ диски (на рынке такие есть), к заказу сегодня таки да доступны только 0.5ТБ. Ладно, для таких объёмов экономить на DAS смысла нет - взять Fuj DX80 - в тех же 14U будет 7полок*24 3.5″ 2ТБ = 168ТБ сразу iSCSI.
>?? это без учета таких штук, как RAID и Spare
…которых вообще нет и быть не может в лентах. 168-115=53ТБ на RAID и spare, если хотите.
Но ещё раз повторюсь - это бессмысленное меряние известно чем - ну ни малейшего влияния стоимость RU на общую цену решения на сотню терабайт не окажет, да и не на первом месте цена в принятии решения у такого бизнеса, скорее всего.
Now that’s some creative accounting.
Ваш пункт «недороги» наполнен очень странными, и крайне неправдоподобными расчетами.
> Ваш пункт «недороги» наполнен очень странными, и крайне неправдоподобными расчетами.
Это вы кому адресовали? Если мне, то я вообще нигде никаких расчетов не приводил и ничего не “наполнял”.
Ценовые расчеты просто смех !
библиотека 4U HP LTO4 48 слотов - 13000$, 48 картриджей по 45$ - 2160$ итого 15160$ за 38.4TB.
А теперь приведите цену брендового дискового массива ! При этом не с десктопными дисками внутри (по 76$ за 1ТБ ) , а нормальными, энтерпрайз класса, мы же тут не домашний самосбор обсуждаем ! Еще не забудьте указать кол-во юнитов которое он займет, а можно еще и питание посчитать, которое оно скушает за год.
boeing:
> Ценовые расчеты просто смех !
А где вы у меня вы видите “ценовые расчеты”?
> А теперь приведите цену брендового дискового массива !
А бэкапиться модно только на “брендовы дисковый массив”? ;)
На самом деле вы правильно увидели проблему, но только не поняли что именно вы увидели. :)
Дело в том, что если нам нужно бэкапить 1-2(-3-4) терабайта, то в случае лент мы уже сразу “попадаем” на цену либо библиотеки, либо же по крайней мере “брендового” стриммера (и ручной работы по замене лент), другого варианта ленты нам не предлагают.
В то время, как в случае дисков вы вполне можете решить задачу бэкапа да хоть просто винтом-двумя-тремя в USB-коробке.
Да, это не будет столь “плюшево”, как в случае “брендовых” решений, но в случае потери данных вам будет, поверьте, не до “шашечек” на том, что хранит ваш бэкап. Если он у вас, по счастью, есть.
А вот в случае лент у вас такого дешевого, быстрого (но тем не менее рабочего) варианта просто не будет. Никаких вариантов. Только стример или библиотека.
Далеко не всякий бизнес готов просто так вынуть и положить стоимость неплохого автомобиля только на бэкапы. В особенности если это ваши собственные деньги.
Какой USB ? Что-то вы отклоняетесь куда-то от собственной заметки ! Я лично выше по тексту “USB” нигде не вижу, зато вижу много “RAID” “дисковый массив”
boeing:
Это не я “отклоняюсь”, это вы читаете только то, что хотите прочесть.
Совсем тезисно: В случае лент у вас есть ОД??Н (достаточно дорогой сам по себе) вариант решения. В случае дисков у вас есть МНОГО РАЗНЫХ вариантов решения, начинающихся от “коробки с USB”, и заканчивающийся очень дорогими вариантами. Но этих вариантов, в отличие от ленты, МНОГО РАЗНЫХ, с разными возможностями и за разные деньги. ??менно это богатство выбора бывает во многих случаях весьма важно.
Если снова непонятно, то я уже не знаю как объяснить. Либо читайте написанное до просветления, либо можете считать тупым меня, я не обижаюсь. :)
murzic> ??того: 115 LTO4 = 14U ~ 115TB
murzic> Fujitsu ETERNUS JX40
murzic> я так понимаю что там диски 2,5″ следовательно максимальная емкость 500Gb
murzic> ??того: 24диска * 3 полки = 72 Диска * 500Gb = 36Tb (Всего)
murzic> ?? это без учета таких штук, как RAID и Spare
Эти полки 2U т.е. в 14U влезет 6 полок + место под контроллер (я про НетАпп), но никак не 3 полки! Соответственно не 36Tb, а 72Tb. А теперь давайте подумаем, что сравнивается, в плане эффективности использования пространства: ленты с full-backup или диски с дедупликацией и снепшотами? Подозреваю, что по полезному пространству то и выйдет.
А сейчас уже год 2012 и диски САТА уже по 3Tb.
boeing> библиотека 4U HP LTO4 48 слотов - 13000$,
Теперь соизмеримые варианты есть: FAS2040, FAS2220 с 12х3ТБ!
было полезно. спасибо