Комментарии 114
На самом деле, backup решает и совсем другую проблему - восстановить файл, который был испорчен/удален, причем неделю назад. Ну и проблемы типа "в серверной был пожар" RAID не решить.
Поэтому backup и RAID вряд ли заменят одна другую.
Поэтому backup и RAID вряд ли заменят одна другую.
Да, я в курсе. Здесь намеренно упрощено.
Для задачи типа "получить файл, который был неделю назад" сейчас применяют электронные архивы программно-аппаратные комплексы с внутренними API (например, HP RISS или EMC Centera), в которых сохраняются все документы организации. Очень удобная штука для электронной почты. Можно получить [санкционированный] доступ к любому письму за последние, скажем, 5 лет.
А для решения задачи "в серверной был пожар" строят территориально распределённые ЦОДы с синхронным зеркалированием систем хранения. Очень непростая задача, кстати.
Для задачи типа "получить файл, который был неделю назад" сейчас применяют электронные архивы программно-аппаратные комплексы с внутренними API (например, HP RISS или EMC Centera), в которых сохраняются все документы организации. Очень удобная штука для электронной почты. Можно получить [санкционированный] доступ к любому письму за последние, скажем, 5 лет.
А для решения задачи "в серверной был пожар" строят территориально распределённые ЦОДы с синхронным зеркалированием систем хранения. Очень непростая задача, кстати.
мне просто показалось, что это принципиальный момент.
Хранить все версии файла можно и, например, с помощью возможностей файловой системы, как было еще в netware 5(или даже раньше) - причем даже в разных фолдерах разным образом - просто это увеличит требования к объемам дисков и, соответственно, общую стоимость.
Насчет распределенных центров я тоже в курсе, просто то же самое решается ежедневным увозом ленточек с бекапом из офиса в банк, что, в общем, гораздо дешевле. Т.е. мое мнение, что это все хорошо,но RAID5+backup, даже при цене 200$ за ленточки на день, все равно самый оптимальный вариант по соотношению надежность/цена.
Хотя, возможно, я уже отстал от жизни :)
Хранить все версии файла можно и, например, с помощью возможностей файловой системы, как было еще в netware 5(или даже раньше) - причем даже в разных фолдерах разным образом - просто это увеличит требования к объемам дисков и, соответственно, общую стоимость.
Насчет распределенных центров я тоже в курсе, просто то же самое решается ежедневным увозом ленточек с бекапом из офиса в банк, что, в общем, гораздо дешевле. Т.е. мое мнение, что это все хорошо,но RAID5+backup, даже при цене 200$ за ленточки на день, все равно самый оптимальный вариант по соотношению надежность/цена.
Хотя, возможно, я уже отстал от жизни :)
На самом деле, это провокационные заголовок и лид.
Статья без них вполне нормальная и не противопоставляет backup рейд-массивам.
Статья без них вполне нормальная и не противопоставляет backup рейд-массивам.
Поверьте мне, нет. Существуют задачи, при которых недостаточно RPO по варианту "увоза ленточек раз в день в банк", а необходимо синхронное реплицирование. Одна из таких задач банковский процессинг (работа банкоматов). Ну и стоимость таких систем естественно довольно высока. Здесь даже не вопрос "надёжность/цена", здесь требуется максимальная надёжность на имеющийся бюджет. Для SMB компаний конечно будет достаточно RAID5 (5DP) + backup. Нагрузки здесь не настолько высоки, чтобы вызывать перманентные веерные отключения, а RPO "раз в день" вполне приемлемо.
По поводу "прошлонедельного файла" я ваше замечание понял. Сейчас ведущие вендоры активно пиарят системы архивирования и призывают различать архивирование и резервное копирование. Хотя, конечно, в этом много маркетинга, но в целом они правы нужно различать резервирование и архивирование информации, особенно той, срок хранения которой регламентируется государственными требованиями. Хорошо, если есть бекапы того файла за прошлую неделю. А если нет? А если это уникальная финансовая отчётность? Ну и опять повторюсь, для SMB это пока неактуально системы архивирования пока весьма дороги. Да и пользоваться лентой для архивов, имея налаженный процесс бекапа попроще.
По поводу "прошлонедельного файла" я ваше замечание понял. Сейчас ведущие вендоры активно пиарят системы архивирования и призывают различать архивирование и резервное копирование. Хотя, конечно, в этом много маркетинга, но в целом они правы нужно различать резервирование и архивирование информации, особенно той, срок хранения которой регламентируется государственными требованиями. Хорошо, если есть бекапы того файла за прошлую неделю. А если нет? А если это уникальная финансовая отчётность? Ну и опять повторюсь, для SMB это пока неактуально системы архивирования пока весьма дороги. Да и пользоваться лентой для архивов, имея налаженный процесс бекапа попроще.
Конечно существуют - но, похоже, мы говорим о разных областях применения. Лично я такие области не затрагивал, но верю, что с такими приложениями так оно и есть.
Что до области применения моего "простого" решения, то я думаю, что она шире среднего бизнеса (не люблю трехбуквенные сокращения) - на мой взгляд, например, для филиала большой компании это вполне нормально.
>Хорошо, если есть бекапы того файла за прошлую неделю. А если нет?
это немного неправильно, правильное бекап решение - это когда известно что и за когда есть. Например - раз месяц за год назад, раз в неделю за месяц, и раз в будний день за 2 недели назад.
Кстати, если говорить про архивирование для небольших компаний, то тут , как ни странно, проще, чем для больших структур.
На мой взгляд, subversion с клиентом в виде встроенного в win клиента webDAV может решить много задач архивирования, да и документооборота.
Что до области применения моего "простого" решения, то я думаю, что она шире среднего бизнеса (не люблю трехбуквенные сокращения) - на мой взгляд, например, для филиала большой компании это вполне нормально.
>Хорошо, если есть бекапы того файла за прошлую неделю. А если нет?
это немного неправильно, правильное бекап решение - это когда известно что и за когда есть. Например - раз месяц за год назад, раз в неделю за месяц, и раз в будний день за 2 недели назад.
Кстати, если говорить про архивирование для небольших компаний, то тут , как ни странно, проще, чем для больших структур.
На мой взгляд, subversion с клиентом в виде встроенного в win клиента webDAV может решить много задач архивирования, да и документооборота.
Что до области применения моего "простого" решения, то я думаю, что она шире среднего бизнеса (не люблю трехбуквенные сокращения) - на мой взгляд, например, для филиала большой компании это вполне нормально.
Да, вполне. Я собствеными глазами видел решения для архивации на основе бекапа. Правда, в основном не ленту используют, а SATA.
>Хорошо, если есть бекапы того файла за прошлую неделю. А если нет?
это немного неправильно, правильное бекап решение - это когда известно что и за когда есть. Например - раз месяц за год назад, раз в неделю за месяц, и раз в будний день за 2 недели назад.
А файл 11-ти месячной давности сохранился? На какой ленте? Сколько инкрементальных копий нужно восстановить? Где находятся эти ленты? Для больших архивов поиск по лентам это сущий ад.
А идея с SVN для архивации недурна :) Нужно только как-то интегрировать аутентификацию с AD, заставить пользователей делать commit и прикрутить клиента, чтобы сами свои файлы могли доставать.
(Да, кстати. Документооборот к этому ну совершенно никакого отношения не имеет.)
>А файл 11-ти месячной давности сохранился? На какой ленте? Сколько инкрементальных копий нужно восстановить? Где находятся эти ленты? Для больших архивов поиск по лентам это сущий ад.
файл-то сохранится, и при правильной политике и ее реализации поиск - это не особая проблема. Но, в общем, плюсы и минусы системы вполне понятны.
про архивацию - если пользователей можно заставить делать commit, по и subversion уже не обязательно - CVS интегрированный с AD существует уже 5 лет (cvsnt.org), и клиенты весьма приличные ("я и сама его принимаю"). Плюс subversion в том, что к ее репозитарию можно сделать доступ по webDAV, а в windows есть встроенная реализация этого webDAV. То есть - для пользователей все прозрачно!
Действительно, про документооборот лучше замнем - я не говорил, что это оно, просто такая система обладает некоторыми полезными свойствами из области документооборота
файл-то сохранится, и при правильной политике и ее реализации поиск - это не особая проблема. Но, в общем, плюсы и минусы системы вполне понятны.
про архивацию - если пользователей можно заставить делать commit, по и subversion уже не обязательно - CVS интегрированный с AD существует уже 5 лет (cvsnt.org), и клиенты весьма приличные ("я и сама его принимаю"). Плюс subversion в том, что к ее репозитарию можно сделать доступ по webDAV, а в windows есть встроенная реализация этого webDAV. То есть - для пользователей все прозрачно!
Действительно, про документооборот лучше замнем - я не говорил, что это оно, просто такая система обладает некоторыми полезными свойствами из области документооборота
Пипец, честно признаться думал что RAID 6 защищает данные почти на 100%
Ага, это старая тема насчёт одинаковых дисков в RAID-массиве.
Ага, видел такое...в 10ом рейде рассыпался один винт, нада было ехать менять, но решили подождать пока поставщики подвезут еще пару новеньких сказей, чтоб уж заодно в другой сервер воткнуть. Как выяснилось бухгалтерия не проплатила чего-то вовремя и вместо 1го дня ждали 3. На 4ый день с утра выяснилось что на другом диске из того же юнита полезли ошибки и пиндык :)
По идее один запасной диск для массива должен лежать на полочке :)
Ну, 100% защита невозможна в принципе из-за природы хранения данных на устройстве подверженном сбоям. А вот "почти на 100%" возможна (99%, 99.9%, 99.99% ...), причём каждая следующая "девятка" в разы удорожает стоимость системы хранения.
Не понимаю, почему популярны RAID 5?
С современными объёмами дисков самым нормальным должен быть RAID 10. Потому что отказоустойчивость выше и скорость работы выше.
В 1U сервер влезает 4 диска, это как раз либо RAID 5, либо RAID 10. Берём диски по 300 гигабайт, это будет 600 гигабайт RAID 10 или 900 гигабайт RAID 5. Лишние 300 гигабайт в данной ситуации, на мой взгляд, не играют роли, зато скорость работы в 2-5 раз (зависит от контроллера) это очень хороший бонус.
Такая большая разница получается за счёт намного более сложной обработки для RAID 5 и сильно нагружает контроллер раз и архитектуры RAID 10 два.
С современными объёмами дисков самым нормальным должен быть RAID 10. Потому что отказоустойчивость выше и скорость работы выше.
В 1U сервер влезает 4 диска, это как раз либо RAID 5, либо RAID 10. Берём диски по 300 гигабайт, это будет 600 гигабайт RAID 10 или 900 гигабайт RAID 5. Лишние 300 гигабайт в данной ситуации, на мой взгляд, не играют роли, зато скорость работы в 2-5 раз (зависит от контроллера) это очень хороший бонус.
Такая большая разница получается за счёт намного более сложной обработки для RAID 5 и сильно нагружает контроллер раз и архитектуры RAID 10 два.
В enterprise системах обычно хранение бизнес-информации осуществляется не в сервере, а минимум в отдельной дисковой полке с интегрированным RAID-контроллером. А чаще так и вообще в интеллектуальном хранилище, подключенном по fibre channel (однако, принципы защиты данных внутри него остаются теми же). Ну и диски соответственно, минимум SCSI (нормальны йобъём высокоскоростных дисков 73 или 146 ГБ).
Это шутка юмора насчёт "обычно"? Объёмы данных сильно разные, требования сильно разные, сами проекты сильно разные. Даже в рамках одной организации решения различаются кардинально (например, для CRM/ERP и почты), не понимаю, откуда это "обычно", учитывая стоимость SAN.
Насчёт минимума про диски тоже непонятно, откуда дровишки - я не встречал ещё ни одного производителя без решений на SATA. Учитывая объём/скорость/надёжность современных дисков, контроллеров и бла-бла, SATA решения не проигрывают SCSI в разы по скорости и надёжности как раньше, зато, как и раньше, выигрывают в разы по цене за мегабайт.
Насчёт минимума про диски тоже непонятно, откуда дровишки - я не встречал ещё ни одного производителя без решений на SATA. Учитывая объём/скорость/надёжность современных дисков, контроллеров и бла-бла, SATA решения не проигрывают SCSI в разы по скорости и надёжности как раньше, зато, как и раньше, выигрывают в разы по цене за мегабайт.
Вовсе не шутка. Идея SAN как раз в том, чтобы обеспечить единообразную архитектуру хранения для центра обработки данных. При большом количестве сущностей в ЦОД (серверов, накопителей и т.д.) дороже создавать и подерживать зоопарк разнородных решений, нежели использовать унифицированный SAN. Чтобы не быть голословным: из наших клиентов только несколько (по пальцам одной руки) не используют SAN (у них SAS/DAS дисковые полки).
SATA по прежнему медленнее SCSI (даже с учётом NCQ) и гораздо менее надёжны при высоких нагрузках. Решения на SATA вендоры предлагают в основном для недорогих NAS систем и для замены ленточек (т.н. backup-to-disk, у EMC несколько таких есть). То есть для систем, в которые данные положили, и они там просто лежат. Во все более-менее серьёзные сервера, и уж тем более системы хранения, устанавливаются SCSI диски (сейчас есть отличные 15000rpm). Можете сами убедиться, посмотрев ассортимент HP, IBM или EMC.
SATA по прежнему медленнее SCSI (даже с учётом NCQ) и гораздо менее надёжны при высоких нагрузках. Решения на SATA вендоры предлагают в основном для недорогих NAS систем и для замены ленточек (т.н. backup-to-disk, у EMC несколько таких есть). То есть для систем, в которые данные положили, и они там просто лежат. Во все более-менее серьёзные сервера, и уж тем более системы хранения, устанавливаются SCSI диски (сейчас есть отличные 15000rpm). Можете сами убедиться, посмотрев ассортимент HP, IBM или EMC.
Насчёт SAN спорить не буду - тут перекосы в статистике обсловлены опытом. У Вас один, у меня другой. Наверняка мой к крупным бизнес-потребителям не относится.
Насчёт SATA/SCSI спорить не хочу, но любопытно посчитать и узнать Ваше мнение =)
Есть два набора дисков, один 4 SCSI, другой 4 SATA.
На SATA весь массив из дисков 250 Гб raid ed стоит столько же, сколько один SCSI на 146 Гб. Не думаю, что скорость или надёжность RAID 10 на SATA ниже, чем у SCSI RAID5 - диски для SATA идут специально обученные с вдвое большим (по сравнению с обычными винтами) гарантированным ресурсом; а скорость RAID10 SATA должна быть примерно равна скорости RAID5 SCSI. Если SCSI-контроллеры не проседают на RAID5 и можно из четырёх дисков собрать массив на ~500 Гб, его стоимость получается почти в пять раз выше с примерно такой же производительностью, а если проседают, то и с меньшей.
Что я считаю не так? Ведь при прочих равных стоимость имеет значение.
Насчёт SATA/SCSI спорить не хочу, но любопытно посчитать и узнать Ваше мнение =)
Есть два набора дисков, один 4 SCSI, другой 4 SATA.
На SATA весь массив из дисков 250 Гб raid ed стоит столько же, сколько один SCSI на 146 Гб. Не думаю, что скорость или надёжность RAID 10 на SATA ниже, чем у SCSI RAID5 - диски для SATA идут специально обученные с вдвое большим (по сравнению с обычными винтами) гарантированным ресурсом; а скорость RAID10 SATA должна быть примерно равна скорости RAID5 SCSI. Если SCSI-контроллеры не проседают на RAID5 и можно из четырёх дисков собрать массив на ~500 Гб, его стоимость получается почти в пять раз выше с примерно такой же производительностью, а если проседают, то и с меньшей.
Что я считаю не так? Ведь при прочих равных стоимость имеет значение.
Напрягать мозги можно сколь угодно долго и верного ответа всё равно не получить. Для RAID6 насчитали на два порядка большую надёжность, чем для RAID5. Что на практике оказалось, мягко говоря, не так.
SCSI, диски разных вендоров в одной группе, RAID различного уровня, схемы бекапов и прочая это всё best practices для хранения, выработаные годами.
Чтобы посмотреть правы вы или нет, нужно купить лписанные вами системы и проверить. Мой опыт подсказывает, что дешёвое решение на SATA будет и менее производительным и в несколько раз менее надёжным для системы, создающей серьёзную нагрузку на систему хранения. Чудес, увы, не бывает.
SCSI, диски разных вендоров в одной группе, RAID различного уровня, схемы бекапов и прочая это всё best practices для хранения, выработаные годами.
Чтобы посмотреть правы вы или нет, нужно купить лписанные вами системы и проверить. Мой опыт подсказывает, что дешёвое решение на SATA будет и менее производительным и в несколько раз менее надёжным для системы, создающей серьёзную нагрузку на систему хранения. Чудес, увы, не бывает.
Чудес не бывает, но системы на Intel со всеми параметрами хуже систем на Opteron и при этом дороже - точно такая же реальность.
Можно это выяснять покупая новые машины, а можно узнать несколько раз в разных местах и сделать выбор на основе этих данных =)
Можно это выяснять покупая новые машины, а можно узнать несколько раз в разных местах и сделать выбор на основе этих данных =)
А вы скорость как считаете? На разных задачах она ведь совершенно разная. Я я так понимаю что у SCSI дисков в принципе случайный доступ быстрее раза в 2 и количеством SATA вы его не перебьете.
А вот всякие SAN/NAS мне щас интересны и в частности думаю над организацией хранилища с доступом по iSCSI и над тем насколько оно лучше чем NFS например, так что тему почитаю :)
А вот всякие SAN/NAS мне щас интересны и в частности думаю над организацией хранилища с доступом по iSCSI и над тем насколько оно лучше чем NFS например, так что тему почитаю :)
Скорость считается по KIOPS при интегральном тесте (вашего) типичного приложения. Для многих это Oracle.
NAS системы могут расшаривать fs по ip-сети с использованием протоколов NFS/CIFS (т.е. они выглядят как сервер с расшаренными папками/директориями). Если думаете об организации именно сети хранения данных, то для небольших контор (по бюджетам, а не по пользователям ;) хорошим решением будет iSCSI (работает на базе существующей ip-сети, дешевле fibre channel).
NAS системы могут расшаривать fs по ip-сети с использованием протоколов NFS/CIFS (т.е. они выглядят как сервер с расшаренными папками/директориями). Если думаете об организации именно сети хранения данных, то для небольших контор (по бюджетам, а не по пользователям ;) хорошим решением будет iSCSI (работает на базе существующей ip-сети, дешевле fibre channel).
Скорость я считаю двумя путями - провожу аналогию от SATA (RAID5 имеет одни и те же подводные камни) и эмпирически, имея на руках данные по просто копированию файлов.
> Я я так понимаю что у SCSI дисков в принципе случайный доступ быстрее раза в 2 и количеством SATA вы его не перебьете.
Это в теории. На практике сильно зависит от производителя, поколения винта и контроллера. Если брать самое удачное стечение обстоятельств для обоих вариантов, то RAID10 SATA не будет медленнее RAID5 SCSI.
Но кроме скорости есть и надёжность - передовые технологии всё-таки внедряют сначала в SCSI, плюс цена SATA уменьшается за счёт удешевления компонет, которое, в свою очередь, ведёт к уменьшению времени работы. А ещё есть цена за мегабайт. Выбирая между ценой и надёжностью можно выбрать подходящую систему.
Но это тоже в теории. Я в наших серверах не видел ни одного вылетевшего SCSI и ни одного вылетевшего SATA =)
Поэтому склоняюсь к варианту, когда переплачивать в пять раз за третий-восьмой (по разным данным) знак после запятой в теоретической надёжности смысла нет.
> Я я так понимаю что у SCSI дисков в принципе случайный доступ быстрее раза в 2 и количеством SATA вы его не перебьете.
Это в теории. На практике сильно зависит от производителя, поколения винта и контроллера. Если брать самое удачное стечение обстоятельств для обоих вариантов, то RAID10 SATA не будет медленнее RAID5 SCSI.
Но кроме скорости есть и надёжность - передовые технологии всё-таки внедряют сначала в SCSI, плюс цена SATA уменьшается за счёт удешевления компонет, которое, в свою очередь, ведёт к уменьшению времени работы. А ещё есть цена за мегабайт. Выбирая между ценой и надёжностью можно выбрать подходящую систему.
Но это тоже в теории. Я в наших серверах не видел ни одного вылетевшего SCSI и ни одного вылетевшего SATA =)
Поэтому склоняюсь к варианту, когда переплачивать в пять раз за третий-восьмой (по разным данным) знак после запятой в теоретической надёжности смысла нет.
Поймите, что скорость на случайном чтении/записи напрямую зависит от RPM диска. Соответсвенно для СУБД это количество транзакций в секунду.
Это даже не теория, это муть какая-то. Ещё с IBM-овских винтов пошла тема с silence режимом работы - количество оборотов то же, а головки дёргаются менее интенсивно. Может, ещё раньше было, но у IBM я встретил это впервые.
Зависимость от оборотов есть, но она нелинейная и большое влияние на нелинейность оказывает производитель. И не меньшее влияние на скорость в целом оказывает контроллер.
И ещё про случайный доступ. Он, несомненно, очень важен, но СУБД не дураки пишут и стараются минимизировать эти самые случайные доступы.
Зависимость от оборотов есть, но она нелинейная и большое влияние на нелинейность оказывает производитель. И не меньшее влияние на скорость в целом оказывает контроллер.
И ещё про случайный доступ. Он, несомненно, очень важен, но СУБД не дураки пишут и стараются минимизировать эти самые случайные доступы.
Учитывайте, что с хранилищем работает не одно единственное приложение, и даже не один единственный сервер. В случае SAN это несколько десятков серверов!
конечно не линейная. но близка к тому. и контроллер тоже важен и СУБД пишут не дураки, но и СУБД не знает физических параметров хранилища, она просто делает fsync() с некой переодичностью, а для того чтобы этот fsync произошел на самом деле - надо переместить головку до нужного места.
Не надо так сильно абстрагироваться от реальности =)
>Но это тоже в теории. Я в наших серверах не видел ни одного вылетевшего SCSI и ни одного вылетевшего SATA =)
вот оно, счастье :) А я вот видел и то и другое, и это меня совершенно не обрадовало.
И, похоже, быстрых (15000 RPM) дисков на SATA вообще не делают.
вот оно, счастье :) А я вот видел и то и другое, и это меня совершенно не обрадовало.
И, похоже, быстрых (15000 RPM) дисков на SATA вообще не делают.
http://www.t-platforms.ru/storage/san/58…
Это не HP, но свои решения они предлагают и так и так. Неужели решение на SATA является дешёвкой и они обманывают людей? ;)
Это не HP, но свои решения они предлагают и так и так. Неужели решение на SATA является дешёвкой и они обманывают людей? ;)
Это high performance fibre channel решение. Вы знаете сколько стоит FC-диск? Это вам не дешёвый SCSI :)
Что касается возможности установки SATA дисков в FC-полку (у HP это называется FATA), то нужны они сами понимаете для чего. И ни о какой производительности в 575KIOPS в таком случае и речи быть не может. Если посмотрите внимательней на ТТХ, то при описании производительности стоят магические буковки "FC".
Что касается возможности установки SATA дисков в FC-полку (у HP это называется FATA), то нужны они сами понимаете для чего. И ни о какой производительности в 575KIOPS в таком случае и речи быть не может. Если посмотрите внимательней на ТТХ, то при описании производительности стоят магические буковки "FC".
Магические буквы видел =) Это нормально =)
Просто, видимо, жаба душит за чуть большую производительность и чуть большую надёжность платить в пять-десять раз больше. Было бы оно хотя бы в два раза выше...
Хорошо ещё, что сейчас стоит проблема выбора только между SATA и SCSI в сервер =)
Просто, видимо, жаба душит за чуть большую производительность и чуть большую надёжность платить в пять-десять раз больше. Было бы оно хотя бы в два раза выше...
Хорошо ещё, что сейчас стоит проблема выбора только между SATA и SCSI в сервер =)
Не чуть. Лишние "единички" в KIOPS, лишняя "девятка" в надёжности для кого-то это очень важные вещи. А для обеспечения этих "единичек" и "девяток" инженеры вендоров проводят большую работу. Это обывателю кажется что "чуть", на самом деле, если цена надёжности решений уровня 99.99% и уровня 99.999% отличается в разы, то это в большей степени объективно оправдано. Более того, есть задачи для которых надёжность 99.99% не применима (кажется, я уже повторяюсь) и потому там мерило "цена/надёжность" не подходит.
Если вам нравится "железо", то наверное плохо. Поковыряться и разобраться в работе системы, похожей по классу на ту, из линка, это очень увлекательно! Это же не просто шкаф набитый дисками, у неё есть собственные контроллеры, ОС, управляющие сервера и специальный софт. Это же "интеллектуальное" хранилище, а не тупой bunch of disks.
Хорошо ещё, что сейчас стоит проблема выбора только между SATA и SCSI в сервер =)
Если вам нравится "железо", то наверное плохо. Поковыряться и разобраться в работе системы, похожей по классу на ту, из линка, это очень увлекательно! Это же не просто шкаф набитый дисками, у неё есть собственные контроллеры, ОС, управляющие сервера и специальный софт. Это же "интеллектуальное" хранилище, а не тупой bunch of disks.
Не чуть
Чуть, чуть =)
Вы сами пример про RAID6 приводили. Мне абсолютно без разницы, сломается диск с надёжностью 99,99 или 99,999. Поэтому способы увеличения количества девяток до приемлемого уровня ищу другие. Просто купить железку и радоваться заявленным цифиркам не наш метод =)
Другое дело, что слишком мало ПО позволяет использовать альтернативные пути увеличения количества девяток.
Любопытно, кто-нибудь предлагает решения с четырмя девятками после запятой под SLA? =)
Хорошо ещё, что сейчас стоит проблема выбора только между SATA и SCSI в сервер =)
А где магическое слово SAS ? =)
Я не интересовался ценами, но есть уверенность, что это фигня =) Когда будет недостаточно винтов в машине, следующим шагом будет SAN.
А причем тут SAN? :) SAS это следующий виток развития SCSI. Меня там заинтересовала возможность устрановки или SAS или SATA винтов без смены контроллера и шасси. Надо быстрые диски? Ставим SAS. Надо большие объемы и критична стоимость ставим SATA.
Я думал, что SAS это тоже внешний девайс.
Их наплодили десять куч, заниматься разбором всех аббревиатур лениво =)
Когда придёт время, проведём тестирование насчёт дисковых систем для 1U машин. Надеюсь, четырёхядерные процессоры перестанут стоить как самолёты к этому времени =)
Правда, толку от этого для окружающих немного - тестироваться будет PostgreSQL на Windows.
Их наплодили десять куч, заниматься разбором всех аббревиатур лениво =)
Когда придёт время, проведём тестирование насчёт дисковых систем для 1U машин. Надеюсь, четырёхядерные процессоры перестанут стоить как самолёты к этому времени =)
Правда, толку от этого для окружающих немного - тестироваться будет PostgreSQL на Windows.
Видимо, основная проблема в том, что область применения в статье не указана.
Есть области, в которых есть смысл делать распределенные центры обработки данных, а есть в которых нет смысла отделять сервер от компьютера секретарши (хм, хотя, может, именно таких уже и нет)
Например, в одной из областей, с которой я знаком [решение для средних размеров филиала глобальной корпорации -500 юзеров] - SATA до сих пор не актуально, так как 15000RPM hot-plug SATA решение, даже если и существует, стоит не сильно дешевле того же на SCSI.
В другой знакомой мне области, наоборот, эффективнее сделать просто софтовый/полусофтовый SATA RAID и бекап дополнительным диском SATA же.
Есть области, в которых есть смысл делать распределенные центры обработки данных, а есть в которых нет смысла отделять сервер от компьютера секретарши (хм, хотя, может, именно таких уже и нет)
Например, в одной из областей, с которой я знаком [решение для средних размеров филиала глобальной корпорации -500 юзеров] - SATA до сих пор не актуально, так как 15000RPM hot-plug SATA решение, даже если и существует, стоит не сильно дешевле того же на SCSI.
В другой знакомой мне области, наоборот, эффективнее сделать просто софтовый/полусофтовый SATA RAID и бекап дополнительным диском SATA же.
В голове крупных бизнес-потребителей ИТ произошло наконец-то смещение акцента с бизнес-приложений на данные, обрабатываемые этими приложениями.
И дело не в количестве пользователей, а в специфике задач и размерах бюджета на ИТ вот что значит "крупный". Для специалиста в области хранения данных рекомендовать строить систему на SATA для задач, скажем, банковского процессинга, равносильно признанию собственного непрофессионализма.
Такое определение слова "крупный" - неочевидно - для него надо быть на стороне продающего решения, а не покупающего их.
Т.е. с моей точки зрения крупный - это в первую очередь много ползователей, а бюджет у него - разумный.
Но, в общем, это уже разговор не по делу.
А с точки зрения специальных приложений я вполне могу представить себе систему, где избыточны не диски, а сервера - и тогда диски могут быть SATA, а сами сервера - самыми дешевыми на рынке 1U
Т.е. с моей точки зрения крупный - это в первую очередь много ползователей, а бюджет у него - разумный.
Но, в общем, это уже разговор не по делу.
А с точки зрения специальных приложений я вполне могу представить себе систему, где избыточны не диски, а сервера - и тогда диски могут быть SATA, а сами сервера - самыми дешевыми на рынке 1U
> Для специалиста в области хранения данных рекомендовать строить систему на SATA для задач, скажем, банковского процессинга, равносильно признанию собственного непрофессионализма.
Есть подозрение, что это исключительно из-за цены вопроса =) Чем дороже, тем лучше.
Есть подозрение, что это исключительно из-за цены вопроса =) Чем дороже, тем лучше.
Для домашнего пользователя обычно RAID 5 не очень доступен т.к. надо как минимум 4 диска.
Думаю дома идеален RAID 1 (два диска) + частые бекапы созданных пользователем данных (документы, исходники прог и т.п.) + периодические всякого фуфла типа музыки (её можно скачать повторно) и редкие системы т.к. систему можно и переставить.
А так главная проблема это конечно бабло. Если оно есть то и данные никуда не теряются, а если нет то тут как повезёт :)
Думаю дома идеален RAID 1 (два диска) + частые бекапы созданных пользователем данных (документы, исходники прог и т.п.) + периодические всякого фуфла типа музыки (её можно скачать повторно) и редкие системы т.к. систему можно и переставить.
А так главная проблема это конечно бабло. Если оно есть то и данные никуда не теряются, а если нет то тут как повезёт :)
Любопытно, куда можно бэкапить 500 гигабайт с домашней машины? ;) И какая должна быть частота =)
Для домашней машины интересная задача. У меня сейчас тоже этот вопрос назрел. Я решил для себя, что бекапить фильмы и музыку необязательно. Главное это система (около 7 ГБ) и личные данные (около 4 ГБ). Если вы пользуетесь linux/*bsd, то можете аккуратно нарезать одинаковые партиции на разных винта и слепить из них программный RAID (0/1/5).
Кстати, для RAID5 достаточно 3-х разделов на разных физических дисках.
Кстати, для RAID5 достаточно 3-х разделов на разных физических дисках.
У меня уже есть решение для музыки/видео/архивов - они скопированы на работу путём приноса туда винтов =)
Но это решение очень уж неуниверсальное. Недорогого решения не вижу, наверное самым простым вариантом будет купить ещё два винта (текущая конфигурация это RAID 0) и запустить RAID 10 или второй RAID 0 и туда писать вручную.
Покупать я их сейчас не буду, зато буду через пол года покупать новую машину. Вот и думаю насчёт одной партии винтов - а не взять ли винты в разное время или от разных производителей?
Но это решение очень уж неуниверсальное. Недорогого решения не вижу, наверное самым простым вариантом будет купить ещё два винта (текущая конфигурация это RAID 0) и запустить RAID 10 или второй RAID 0 и туда писать вручную.
Покупать я их сейчас не буду, зато буду через пол года покупать новую машину. Вот и думаю насчёт одной партии винтов - а не взять ли винты в разное время или от разных производителей?
В домашнюю я взял диски WD и Hitachi разных партий. Полное зеркало не рекомендую делать только для важных изменяющихся данных. Для данных, которые просто лежат и иногда используются, лучше сделать резервные копии (на другой диск, например). Данные, которые просто лежат, можно либо забекапить на WORM (CD-R, DVD-R) либо не бекапить. Кино с музыкой в случае чего можно и из сети скачать :) Главное предварительно всем раздать ;)
Данные, которые просто лежат, на DVD записывать слишком долго, плюс иметь головную боль с обновлением бэкапа.
Пришло в голову ещё одно решение. Для таких данных завести просто винт и купить ещё внешнюю коробку USB2.0 и/или FireWire, куда синхронизировать обновления. А работать продолжать на RAID 1, правда куда девать столько места, непонятно =) Разве что под кино отдать, кино нестрашно потерять.
Получаем, что на винты затраты будут чуть выше из-за коробки (количество винтов остаётся 4), головной боли с DVD нет, и, один из главных для домашней машины моментов - работать будут только два винта, так как третий в системнике будет спать обычно, а четвёртый из коробки будет подключаться раз в пол года.
Пришло в голову ещё одно решение. Для таких данных завести просто винт и купить ещё внешнюю коробку USB2.0 и/или FireWire, куда синхронизировать обновления. А работать продолжать на RAID 1, правда куда девать столько места, непонятно =) Разве что под кино отдать, кино нестрашно потерять.
Получаем, что на винты затраты будут чуть выше из-за коробки (количество винтов остаётся 4), головной боли с DVD нет, и, один из главных для домашней машины моментов - работать будут только два винта, так как третий в системнике будет спать обычно, а четвёртый из коробки будет подключаться раз в пол года.
Ну я, например, просто на NAS rsync'ом все данные "/Users" копирую.
Можно на плёнку, но я пока не изучал этот вопрос поэтому сколько стоит и насколько оправданно не знаю.
Я бы не сказал, что это вопрос лишь денег. Для домашней машины ещё куча факторов появляется мои 6 дисков очень шумели, например :)
Для RAID5, кстати, достаточно 3-х дисков.
Для RAID5, кстати, достаточно 3-х дисков.
Мне кажется, что выбор backup, скажем так, скорее психологический, нежели технологический.
Т.е. создание бэкапа подразумевает некоторые действия, за которые можно отчитаться - принудительно скинул данные на диск (ленту), убрал в сейф, расписался в журнале, спокоен. Дисковые массивы с избыточностью таких же действий не требуют. Поэтому для человека не понятно, кто и за что отвечает и кто будет виноват.
Кроме того, опять же психологически может "давить" то, что дисковые массивы постоянно находятся в работе и поэтому кажется более логичным использовать переодически задействуемые средства хранения: ленты, диски. "Меньше работают - меньше ломаются!" Естественно, если основные данные не меняются (добавляются) непрерывно.
Получается, что "слабым звеном" в выборе систем хранения данных может оказаться человек с догмами. Если этот человек принимает принципиальное решение, то и систему надо предлагать такую, которая устроит и его и вас.
Т.е. создание бэкапа подразумевает некоторые действия, за которые можно отчитаться - принудительно скинул данные на диск (ленту), убрал в сейф, расписался в журнале, спокоен. Дисковые массивы с избыточностью таких же действий не требуют. Поэтому для человека не понятно, кто и за что отвечает и кто будет виноват.
Кроме того, опять же психологически может "давить" то, что дисковые массивы постоянно находятся в работе и поэтому кажется более логичным использовать переодически задействуемые средства хранения: ленты, диски. "Меньше работают - меньше ломаются!" Естественно, если основные данные не меняются (добавляются) непрерывно.
Получается, что "слабым звеном" в выборе систем хранения данных может оказаться человек с догмами. Если этот человек принимает принципиальное решение, то и систему надо предлагать такую, которая устроит и его и вас.
Могу вас заверить, что с людьми, принимающими решения в области ИТ для крупных кастомеров (CIO и т.п.), ведётся постоянная просветительская работа со стороны вендоров. Так что эти люди "в теме".
А с бекапом сейчас назревает довольно пикантная ситуация. Дело в том, что объёмы данных растут быстрее, чем скорость их передачи (в глобальном смысле). Это приводит к тому, что backup window "растягивается". То есть, за время пока происходит бекап, в системе накапливается значительный объём новых данных, которые снова нужно бекапить. А в некоторых случаях и некоторых специфических задачах (предсказание погоды, например) данные накапливаются быстрее, чем происходит бекап. Вот такая забавная штука.
А с бекапом сейчас назревает довольно пикантная ситуация. Дело в том, что объёмы данных растут быстрее, чем скорость их передачи (в глобальном смысле). Это приводит к тому, что backup window "растягивается". То есть, за время пока происходит бекап, в системе накапливается значительный объём новых данных, которые снова нужно бекапить. А в некоторых случаях и некоторых специфических задачах (предсказание погоды, например) данные накапливаются быстрее, чем происходит бекап. Вот такая забавная штука.
Для крупных кастомеров согласен - вопросов нет.
А для мелких.. оставим в стороне погоду и прочую "жесть", и приземлимся до уровня случаев, где данные меняются в течении рабочего дня: документы, базы и т.д.
Тут "психологизм" и вылезет - будут скидывать документы руками на флешки, писать на болванки, скидывать на хард в рэке (в конце дня вынимаемый и убираемый в несгораемый сейф). Еще немаловажна стоимость нормального решения резервного копирования и хранения данных для мелких случаев. Где вендоры, предлагающие дешевые решения?
А для мелких.. оставим в стороне погоду и прочую "жесть", и приземлимся до уровня случаев, где данные меняются в течении рабочего дня: документы, базы и т.д.
Тут "психологизм" и вылезет - будут скидывать документы руками на флешки, писать на болванки, скидывать на хард в рэке (в конце дня вынимаемый и убираемый в несгораемый сейф). Еще немаловажна стоимость нормального решения резервного копирования и хранения данных для мелких случаев. Где вендоры, предлагающие дешевые решения?
Хм ну как вариант D2D (собственено бекап на HDD и ныканье его в сейф).
Да я это и упомянул - в смысле хард в рэке и в сейф. Но всеравно это не идеальные решения, т.к. высокая вероятность потери данных на бэкапе: качество болванок упало, флешкам верить нельзя да и ремонтировать их дорого. С хардами в рэках тоже вопросов достаточно. И стоимость вытаскивания данных при аппаратном сбое м.б. высокой.
Интереснее было бы решение с внешним кейсом на 2 HDD с аппаратным RAID внутри, но таких предложений не очень то и много.
Кстати, а как организовано резервное копирование в 1С и сотоварищах? Вот уж где поле непаханное для внедрения по разным конторам...
Интереснее было бы решение с внешним кейсом на 2 HDD с аппаратным RAID внутри, но таких предложений не очень то и много.
Кстати, а как организовано резервное копирование в 1С и сотоварищах? Вот уж где поле непаханное для внедрения по разным конторам...
Интереснее было бы решение с внешним кейсом на 2 HDD с аппаратным RAID внутри, но таких предложений не очень то и много.
Такое решение собирается на коленке за день. Для этого надо материнскую плату MiniATX или еще лучше MiniITX. Далее нужен будет переходник для CF и сам CF для загрузки системы, гигабитная сетевая карта + 2 HDD в RAID1. Далее просто используем iSCSI. Штатные подобные решения тоже существуют. Вы что не видели внешних массивов с поддержкой RAID 10 и RAID 5 для офисов?
Видел... Но я говорю о совсем дешевых (простых) решениях, которые и собирать то некому :)
Дешево это сколько 100-200$ без дисков ?
Угу ... практика экономии на всем - распространенное явление :)
В таком случае купите два USB диска и не мучайтесь. За 100-200 долларов вы хорошего решения не получите.
Это не мне :)
Я к тому что между хорошим решением и бэкапом люди выбирают первое, потому что ограничены в средствах и никто им не может объяснить преимущества более дорогих решений и обосновать их стоимость.
Вот для решений мелких офисов какая нормальная стоимость? $400?
Я к тому что между хорошим решением и бэкапом люди выбирают первое, потому что ограничены в средствах и никто им не может объяснить преимущества более дорогих решений и обосновать их стоимость.
Вот для решений мелких офисов какая нормальная стоимость? $400?
Большая часть NAS серверов ориентировано, на постоянную работу. В связи с чем пустая коробка будет стоить от 400-600 баксов. Считайте туда входит блок питания, корпус, специазированная плата (для встраиваемых решений) и ПО. Вот и набегает. Кстати есть еще интересная мысль. 2 eSATA порта и два таких диска. Строите на них RAID далее после синхронизации отключаете :)
Психология "мелких" обычно заставляет их экономить даже на ленточных бекапах и втором диске для зеркалирования системы своего основного сервера (я подозреваю, что до сих пор кое-кто совмещает компьютер секретарши и сервер "в одном флаконе", как заметил 
centrist). Обычно всё это происходит до первого сербёзного сбоя и осознания того, что из-за прижимистости компания потеряла существенный доход.
А вендоров, предлагающих дешёвые решения, действительно практически нет.
centrist). Обычно всё это происходит до первого сербёзного сбоя и осознания того, что из-за прижимистости компания потеряла существенный доход.А вендоров, предлагающих дешёвые решения, действительно практически нет.
В случае "совмешения" сервера и рабочей станции.. тут лучик света есть, т.к. на совеременных матерях иногда добавляют RAID контроллер, и возможно установить 2 HDD. Для других же теоретически можно сделать средствами XP (программно), но системный диск не зеркалируется, и надо +2 HDD к системному, что еще более не убедительно.
Software RAID спасёт. Не знаю как на WinXP, а в Linux можно сделать RAID на партициях. Т.е. для зеркалирования достаточно 2-х дисков. Да и "системный раздел" тоже можно зазеркалить.
Боюсь не скоро "компьютер секретарши-сервер" будет работать под Linux...
Будь я аникейщиком, именно в такой организации я бы линукс и поставил. Вообще, по моему мнению, именно секретарш/customer support можно перевести на линукс вообще без каких-либо проблем.
Вы серьёзно? Интересно!
вполне серьезно. В какой-то момент я понял, что в "корпоративном окружении" 90% пользователей, вообще-то, не почувствуют разницы, если на их компьютере win заменить на линукс. 5% чем то интересуются, ставят icq(или пытаются ставить - в зависимости от политики IT), а других 5% перемещение иконки на 5 пикселов приводит в ступор - обеим этим категориям переходить сложнее. А вот остальным достаточно объявить, что иконка ворда будет выглядеть по другому и, в общем, все.
А насколько ваша выборка репрезентативна? Какого класса эти компании, каковы их области деятельности?
Я могу судить только по местам где я работал или, в меньшей степени, где работали мои знакомые - несколько ТНК и несколько мелких фирмочек.
Главное наблюдение тут не в том, как выглядит корпоративное окружение, а в области психологии. Почему-то считается, что переход на линукс плох именно тем, что надо обучать пользователей - но я пришел к выводу что те самые 90% вообще не заметят разницы.
Главное наблюдение тут не в том, как выглядит корпоративное окружение, а в области психологии. Почему-то считается, что переход на линукс плох именно тем, что надо обучать пользователей - но я пришел к выводу что те самые 90% вообще не заметят разницы.
В Win 2003 , во всяком случае, системный раздел зеркалируется без проблем.
Вообще я тут пришел к выводу, что никакой пользы от RAID на материнской плате нет. Дело в том, что пытаясь запустить такой RAID под линукс, я наткнулся на мнение, что все равно все алгоритмы, что там есть, работают на CPU. И в этом случае по скорости работы преимуществ перед софтовым RAID никакой. Загрузка с софтового вполне возможна. А возможностей по мониторингу в софтовом RAID побольше будет. И главное - можно повесить винты на разные контроллеры, что , нас самом деле, большой плюс к надежности. Опять же, тупые hw RAID не позволяют зеркалировать раздел.
Вообще я тут пришел к выводу, что никакой пользы от RAID на материнской плате нет. Дело в том, что пытаясь запустить такой RAID под линукс, я наткнулся на мнение, что все равно все алгоритмы, что там есть, работают на CPU. И в этом случае по скорости работы преимуществ перед софтовым RAID никакой. Загрузка с софтового вполне возможна. А возможностей по мониторингу в софтовом RAID побольше будет. И главное - можно повесить винты на разные контроллеры, что , нас самом деле, большой плюс к надежности. Опять же, тупые hw RAID не позволяют зеркалировать раздел.
Ну не совсем. Там есть некоторое количество операций, что выполняются контроллером. Но к сожалению аппаратного XOR движка там обычно нет.
ну я тоже так думал, и был удивлен увидев противоположное мнение. Информации , где просто и понятно было бы описано, что конкретно делают эти аппаратные контролеры, я не нашел (может, плохо искал). Rebuild в фоновом режиме они не делают, как я понимаю, в отличие от софтового. Но, в общем, за что купил, за то и продаю
В W2k3 - да, в WiXP Prof системный можно только с бубном и хаком. Не системный - стандартными средствами.
Как-то мне софтовые решения кажутся менее надежными, особенно в таком важном деле как сохранность данных.
Как-то мне софтовые решения кажутся менее надежными, особенно в таком важном деле как сохранность данных.
Хм а слепки не спасают? Ну и Disk to Disk решения? Или все упрается в то что частота снятия слепков и объемы слепков настолько кореллируют что слепок просто не успевает упасть в Backup до снятия нового слепка?
Именно так.
Кстати, вы правы в том, что backup-to-disk всё больше используется. Хотя особого прироста в скорости бекапа это не даёт. Здесь основную роль играет пропускная способность каналов передачи (SCSI, Ethernet, FC).
Кстати, вы правы в том, что backup-to-disk всё больше используется. Хотя особого прироста в скорости бекапа это не даёт. Здесь основную роль играет пропускная способность каналов передачи (SCSI, Ethernet, FC).
Да, в общем приличных дешевых NAS нет, а использовать USB хранилище для переодического скидывания для 2 человек уже не годится.
По сравнению с лентами у backup-to-disk имеется прирост скорости в случайном доступе.
Подумайте при какой операции используется случайный доступ и вы поймёте, почему скорость бекапа значимо не отличается.
Чаще всего достать какие-либо конкретные данные на диске. Хм в целом можно и ленту помотать. Если же скорость доступа критична... то о каком доставании из бекапа может идти речь :) Если не в скорости дело, то в чем? В унификации блоков чтоли ?
Есть такие страшные слова как "консолидация", "виртуализация хранения", "жизненный цикл информации". Посмотрите на сайтах вендоров как выглядят backup-to-disk системы и их ТТХ.
Системы backup-to-disk используются в основном для бекапа. Причём бекапа централизованного, со многих серверов одновременно. А для того, чтобы доставать конкретные данные существуют совсем иные решения контентно-адресуемые системы.
Системы backup-to-disk используются в основном для бекапа. Причём бекапа централизованного, со многих серверов одновременно. А для того, чтобы доставать конкретные данные существуют совсем иные решения контентно-адресуемые системы.
ок.
Думаю что ситуация следующая - для крупных кастомеров вендоры вполне способны решения с + и -.
Мелкие и очень мелкие кастомеры выбирают решения которые им понятны и устраивают по цене. Вполне возможно, что они просто не знают про другие решения или им никто должным образом не объяснил преимущества систем надежного хранения по сравнению с обычным бэкапом "на дискетку". И некто не развеял их "психологические" догмы. У них вполне возможно нет обслуживания техники. Ну придет мальчик Вася, переставит систему и поменяет картридж. А предлагающих решения на более серьезном уровне для оч. мелких нет - потому что вылезает масса вопросов. Хотя можно создать гораздо более надежные решения при умеренной стоимости и для них.
Для средних - там могут процветать наколеночные решения, т.к. денег тоже жалко, а подросший Вася сделает все "как надо". Ему + и - тоже никто не объясняет и не убедит уговорить начальство купить то, что нужно.
Думаю что ситуация следующая - для крупных кастомеров вендоры вполне способны решения с + и -.
Мелкие и очень мелкие кастомеры выбирают решения которые им понятны и устраивают по цене. Вполне возможно, что они просто не знают про другие решения или им никто должным образом не объяснил преимущества систем надежного хранения по сравнению с обычным бэкапом "на дискетку". И некто не развеял их "психологические" догмы. У них вполне возможно нет обслуживания техники. Ну придет мальчик Вася, переставит систему и поменяет картридж. А предлагающих решения на более серьезном уровне для оч. мелких нет - потому что вылезает масса вопросов. Хотя можно создать гораздо более надежные решения при умеренной стоимости и для них.
Для средних - там могут процветать наколеночные решения, т.к. денег тоже жалко, а подросший Вася сделает все "как надо". Ему + и - тоже никто не объясняет и не убедит уговорить начальство купить то, что нужно.
Цитируя Игоря Николаева: "RAID - это средство для борьбы с тараканами в голове".
1. Использование уровней raid выше первого - безумие.
Если используются что-либо сложнее зеркала, то данные хранятся в собственном недокументированном формате фирмы изготовителя raid контроллера. И вам ни за что не восстановить данные в случае выгорания контроллера без его замены.
А стоимость замены хорошего контроллера, это стоимость авиаперелета до Лондона и обратно. Но и после этого можно получить сюрприз в виде чуть-чуть другой аппаратной ревизии, несовментимость форматов данных при разных версиях firmware.
В случае raid 1 при попытке почитать половинку на обычном контроллере можно тоже получить смещение начала ваших данных на пару секторов, хоть это и неприятно, но не фатально.
2. Использование raid без резервного копирования - верный способ потерять ваши данные.
Практически при любом использовании дискового хранилища, всегда есть сектора которые после записи в них не читаются потом по пол года. Даже если вы иногда делаете полное резервное копирование, пустые сектора все равно не читаются.
Теперь представте что у вас есть raid 5 из пяти дисков, один из которых вдруг подох. Вы радостно подключаете новый и запускаете процедуру rebuild (или, что хуже, она начинается автоматически). Тут начинается волшебное действо. Для восстановления raid-а читаются все данные со всех оставшихся дисков. И вдруг выясняется что за прошедшие полгода один сектор на одном из оставшихся дисков почему-то тоже попортился.
Все. На этом raid завершает свою работу. Система умерла. Если вы использовали raid 5 все данные умерли тоже. При raid 1 наверно вы сможете их восстановить, просто наплевав на сбойные сектора. Да и вероятность появления ошибки за полгода для четырех дисков выше чем для одного. Самое обидное, что если бы не rebuild, все бы работало еще какое-то время.
А так, если у вас не резервной копии или она неактуальная месячной давности, вы по уши в дерьме. Но если вы умны, в другой раз вы не будете слушать сказки системных интеграторов.
3. Про тех, кто покоцал свои суперважные файлы три минуты или три месяца назад я даже рассказывать ничего не буду.
4. Система в режиме деградации и восстановления почти всегда не выдерживает нагрузки.
Если система хорошо нагружена, то при деградации в случае отказа одного из компонентов ее производительность заметно ухудшается. Перестроение же массива на нагруженой системе почти всегда приводит к отказу в обслуживании для сервиса, который использует эту дисковую систему. Как правило 10-и минут наблюдения за мучениями оказывается достаточно, что бы проявить милосердие и отключить уже и так не работающий сервис и дать дискам скорее завершить восстановление.
Кстати не могу понять почему практически нет реализаций raid 1 где бы одновременно использовалось три компонента.
З.Ы. Гугл вообще не использует raid. У них распределенное хранилище с тройным резервированием. Причем все компоненты на которых хранится отдельный блок данных (64M) разнесены географически. А для каждого блока наборы из этих 3-х компонентов не совпадают.
1. Использование уровней raid выше первого - безумие.
Если используются что-либо сложнее зеркала, то данные хранятся в собственном недокументированном формате фирмы изготовителя raid контроллера. И вам ни за что не восстановить данные в случае выгорания контроллера без его замены.
А стоимость замены хорошего контроллера, это стоимость авиаперелета до Лондона и обратно. Но и после этого можно получить сюрприз в виде чуть-чуть другой аппаратной ревизии, несовментимость форматов данных при разных версиях firmware.
В случае raid 1 при попытке почитать половинку на обычном контроллере можно тоже получить смещение начала ваших данных на пару секторов, хоть это и неприятно, но не фатально.
2. Использование raid без резервного копирования - верный способ потерять ваши данные.
Практически при любом использовании дискового хранилища, всегда есть сектора которые после записи в них не читаются потом по пол года. Даже если вы иногда делаете полное резервное копирование, пустые сектора все равно не читаются.
Теперь представте что у вас есть raid 5 из пяти дисков, один из которых вдруг подох. Вы радостно подключаете новый и запускаете процедуру rebuild (или, что хуже, она начинается автоматически). Тут начинается волшебное действо. Для восстановления raid-а читаются все данные со всех оставшихся дисков. И вдруг выясняется что за прошедшие полгода один сектор на одном из оставшихся дисков почему-то тоже попортился.
Все. На этом raid завершает свою работу. Система умерла. Если вы использовали raid 5 все данные умерли тоже. При raid 1 наверно вы сможете их восстановить, просто наплевав на сбойные сектора. Да и вероятность появления ошибки за полгода для четырех дисков выше чем для одного. Самое обидное, что если бы не rebuild, все бы работало еще какое-то время.
А так, если у вас не резервной копии или она неактуальная месячной давности, вы по уши в дерьме. Но если вы умны, в другой раз вы не будете слушать сказки системных интеграторов.
3. Про тех, кто покоцал свои суперважные файлы три минуты или три месяца назад я даже рассказывать ничего не буду.
4. Система в режиме деградации и восстановления почти всегда не выдерживает нагрузки.
Если система хорошо нагружена, то при деградации в случае отказа одного из компонентов ее производительность заметно ухудшается. Перестроение же массива на нагруженой системе почти всегда приводит к отказу в обслуживании для сервиса, который использует эту дисковую систему. Как правило 10-и минут наблюдения за мучениями оказывается достаточно, что бы проявить милосердие и отключить уже и так не работающий сервис и дать дискам скорее завершить восстановление.
Кстати не могу понять почему практически нет реализаций raid 1 где бы одновременно использовалось три компонента.
З.Ы. Гугл вообще не использует raid. У них распределенное хранилище с тройным резервированием. Причем все компоненты на которых хранится отдельный блок данных (64M) разнесены географически. А для каждого блока наборы из этих 3-х компонентов не совпадают.
3. Про тех, кто покоцал свои суперважные файлы три минуты или три месяца назад я даже рассказывать ничего не буду.
На домашнем компьютере можно использовать Google Desktop + плагин ревизий. Таким образом можно восстановить хотя бы суть текстовых файлов за довольно значительный период и при этом восстановить разные версии.
DVD-резак и пачка болванок стоят немного, да и думать особо не надо - записал, сунул в шкаф, забыл.
При частом изменении файлов имхо лучше всего поставить VCS, но оригинальный каталог бэкапить почаще тоже (а не бэкапить хранилище CVSNT или что Вы там выбрали для этого дела).
А для больших "суперважных" файлов я и не знаю, что может быть удобнее бэкапа на DVD (если поместятся, конечно).
При частом изменении файлов имхо лучше всего поставить VCS, но оригинальный каталог бэкапить почаще тоже (а не бэкапить хранилище CVSNT или что Вы там выбрали для этого дела).
А для больших "суперважных" файлов я и не знаю, что может быть удобнее бэкапа на DVD (если поместятся, конечно).
Посмотрел цены на стриммеры... 500 гиговый диск + коробка к нему будут стоить дешевле.
DVD где угодно прочесть можно, это иногда немаловажно.
Диск в моём ответе = НЖМД
Коробка если она с USB то тоже может где угодно прочитаться, кроме случаев с фильмами и фото.
Коробка если она с USB то тоже может где угодно прочитаться, кроме случаев с фильмами и фото.
Я почему так упорствую против DVD. Дело в том, что когда создание резервных копий это не ваша работа то наверняка вы будете не всегда заставлять себя вставлять диск и нажимать на кнопку (она должна быть одна). Поэтому лучше когда бекап делается "сам". Например, комп проснулся часов в пять утра и ловко сделал все свои дела: бекап, скандиск, дефрагментация, проверка антивирусом всех новых файлов и т.п.
Я соглашусь что начиная с определенного объема данных DVD становится неудобным из-за размера. Когда и если у меня будет такая проблема, я куплю несколько внешних USB-накопителей, но не буду втыкать везде стримеры :) Да и к лентам предубеждение имею.
Копирование же можно автоматизировать. Я сейчас вообще в качестве средства для хранения бэкапа (и переноски оного) 4GB флэшку использую, но все же DVD подешевле...
Копирование же можно автоматизировать. Я сейчас вообще в качестве средства для хранения бэкапа (и переноски оного) 4GB флэшку использую, но все же DVD подешевле...
Спасибо за интересный комментарий. Позволю себе не согласиться с некоторыми утверждениями.
Во-первых, система, которая хранит/обрабатывает критичные для бизнеса данные не должна содержать единой точки отказа. Это означает, что RAID-контроллеры, как правило, продублированы. Во-вторых, если контроллер отказывает во время гарантийного срока, то вендор заменяет его за свой счёт. Так что можете слетать в Лондон и обратно на сэкономленные деньги. В-третьих, в системе хранения используются компоненты одного вендора, а они тщательно тестируются на совместиность. Если используется мультивендорное решение, то тут действительно есть проблема несовместимости. Но использовать компоненты нескольких производителей в системе хранения это искать приключений на свою сами-знаете-что. В-четвёртых, если вы так боитесь не совместимости, то используйте software RAID. На уровне LVM зеркалирование работает весьма хорошо, а риска потери данных из-за несовместимости практически нет (при условии использования одной ОС, естественно).
Если вы делаете резервное копирование, то читаются все сектора. И коды коррекции тоже читаются и даже проверяются. Здесь есть другая опасность: данные могут "испортиться" пока они просто хранятся на диске и никто этого не заметит, пока не попробует эти данные получить. С этим вендоры тоже борятся. Например, у EMC сектор равен 520 байтам, дополнительные 8 байт отданы под расширенный ECC. Кроме того, на "интеллектуальных" хранилищах в фоновом режиме работает специальный процесс, который читает все сектора. И в случае, если сектор читается плохо (не с первой попытки), переносит данные в другой, более надёжный сектор.
И не надо. Я уже неоднократно говорил, что это не задача RAID, и не задача бекапа.
Да. Тут ничего не могу возразить. Rebuild серьёзно просаживает систему. Однако, с этим тоже пытаются бороться (не могу сказать, что очень успешно). Один из таких способов виртуализация на уровне дискового хранения. Т.е. в RAID-группы объединяются не сами диски, а находящиеся на них chunk. Такой подход применяет, например HP.
Такие реализации есть, но я пока ещё не видел ниодного кастомера, который бы это использовал. Причина высокая избыточность и, как следствие, цена. На дабл мирроре избыточность 200%, на типичном рейде менее 20%. А если объём данных велик? При переводе в деньги (при цене высокопроизводительного диска более 1K$) это удручает.
Не забывайте, что Google это компания с почти 100 миллиардной капиталлизацией, основу бизнеса которой составляет их информационная система. У них много оригинальных подходов, которые вряд ли можно советовать "обычным" компаниям. Например, сервера поисковой машины заменяются целиком в случае неисправности. Они посчитали, что так для них дешевле. То же самое и в double mirroring. Кстати, обратите внимание, они используют chunk для зеркалирования. То, о чём я говорил выше.
Использование уровней raid выше первого - безумие. Если используются что-либо сложнее зеркала, то данные хранятся в собственном недокументированном формате фирмы изготовителя raid контроллера. И вам ни за что не восстановить данные в случае выгорания контроллера без его замены.
А стоимость замены хорошего контроллера, это стоимость авиаперелета до Лондона и обратно. Но и после этого можно получить сюрприз в виде чуть-чуть другой аппаратной ревизии, несовментимость форматов данных при разных версиях firmware.
Во-первых, система, которая хранит/обрабатывает критичные для бизнеса данные не должна содержать единой точки отказа. Это означает, что RAID-контроллеры, как правило, продублированы. Во-вторых, если контроллер отказывает во время гарантийного срока, то вендор заменяет его за свой счёт. Так что можете слетать в Лондон и обратно на сэкономленные деньги. В-третьих, в системе хранения используются компоненты одного вендора, а они тщательно тестируются на совместиность. Если используется мультивендорное решение, то тут действительно есть проблема несовместимости. Но использовать компоненты нескольких производителей в системе хранения это искать приключений на свою сами-знаете-что. В-четвёртых, если вы так боитесь не совместимости, то используйте software RAID. На уровне LVM зеркалирование работает весьма хорошо, а риска потери данных из-за несовместимости практически нет (при условии использования одной ОС, естественно).
Практически при любом использовании дискового хранилища, всегда есть сектора которые после записи в них не читаются потом по пол года. Даже если вы иногда делаете полное резервное копирование, пустые сектора все равно не читаются.
Если вы делаете резервное копирование, то читаются все сектора. И коды коррекции тоже читаются и даже проверяются. Здесь есть другая опасность: данные могут "испортиться" пока они просто хранятся на диске и никто этого не заметит, пока не попробует эти данные получить. С этим вендоры тоже борятся. Например, у EMC сектор равен 520 байтам, дополнительные 8 байт отданы под расширенный ECC. Кроме того, на "интеллектуальных" хранилищах в фоновом режиме работает специальный процесс, который читает все сектора. И в случае, если сектор читается плохо (не с первой попытки), переносит данные в другой, более надёжный сектор.
Про тех, кто покоцал свои суперважные файлы три минуты или три месяца назад я даже рассказывать ничего не буду.
И не надо. Я уже неоднократно говорил, что это не задача RAID, и не задача бекапа.
Система в режиме деградации и восстановления почти всегда не выдерживает нагрузки.
Если система хорошо нагружена, то при деградации в случае отказа одного из компонентов ее производительность заметно ухудшается. Перестроение же массива на нагруженой системе почти всегда приводит к отказу в обслуживании для сервиса, который использует эту дисковую систему. Как правило 10-и минут наблюдения за мучениями оказывается достаточно, что бы проявить милосердие и отключить уже и так не работающий сервис и дать дискам скорее завершить восстановление.
Да. Тут ничего не могу возразить. Rebuild серьёзно просаживает систему. Однако, с этим тоже пытаются бороться (не могу сказать, что очень успешно). Один из таких способов виртуализация на уровне дискового хранения. Т.е. в RAID-группы объединяются не сами диски, а находящиеся на них chunk. Такой подход применяет, например HP.
Кстати не могу понять почему практически нет реализаций raid 1 где бы одновременно использовалось три компонента.
Такие реализации есть, но я пока ещё не видел ниодного кастомера, который бы это использовал. Причина высокая избыточность и, как следствие, цена. На дабл мирроре избыточность 200%, на типичном рейде менее 20%. А если объём данных велик? При переводе в деньги (при цене высокопроизводительного диска более 1K$) это удручает.
З.Ы. Гугл вообще не использует raid. У них распределенное хранилище с тройным резервированием. Причем все компоненты на которых хранится отдельный блок данных (64M) разнесены географически. А для каждого блока наборы из этих 3-х компонентов не совпадают.
Не забывайте, что Google это компания с почти 100 миллиардной капиталлизацией, основу бизнеса которой составляет их информационная система. У них много оригинальных подходов, которые вряд ли можно советовать "обычным" компаниям. Например, сервера поисковой машины заменяются целиком в случае неисправности. Они посчитали, что так для них дешевле. То же самое и в double mirroring. Кстати, обратите внимание, они используют chunk для зеркалирования. То, о чём я говорил выше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Беззащитные данные