Комментарии 71
Несколько странное с точки зрения oracle решение сложить redo+undo на один раздел.
С точки зрения NetApp так вообще, хоть в один раздел все базы клади. Просто разными томами управлять проще, реплицировать, следить за нагрузкой.
У undo и redo принципиальная разная структура операций: по redo идут чисто последовательные запись и чтение, по undo идет random read-write.
redo гораздо более критичен по производительности.
И смысла иметь синхронно реплицируемое undo при отстающих остальных табличных пространствах совершенно никакого.
redo гораздо более критичен по производительности.
И смысла иметь синхронно реплицируемое undo при отстающих остальных табличных пространствах совершенно никакого.
Это не в моей компетенции, я с oracle не слишком дружен. Очень давно уже наши DBA используют такую структуру, еще до моего прихода, и всех всё устраивает. Сейчас redo + undo лежит на флешах, соответственно на random read полностью все равно, а random write для NetApp всё равно. Но спасибо за информацию, у нас еще есть базы, которые используют механические диски для redo, надо будет посмотреть.
В таком случе хотел еще спросить — такой вариант с отстванием части разделов с dba согласован?
Он неработоспособен и при потере master массива невозможно будет запуститься на slave, кроме этого возможна потеря достаточно большого объема транзакций при последущем восстановлении с ленточек.
По потере — причина в том, что если БД работает достаточно активно и redo log switch происходит раз в минуту (что неправильно, но бывает), а в БД всего 3 группы redo, то через три минуты произойдет затирание redo, сгенерированного три минуты назад, а архивная копия лога из-за задержки на slave еще не доедет.
По невозможности подняться — из-за несинхронного режима 100% вероятность получить fractured oracle блоки (в которх разный rba в заголовке и в трейле) при пропадании master или просто при разрыве канала синхронизации. Fractured блоки oracle не умеет восстаналивать по redo (если только не был выполнен begin backup, но постоянно с этим жить нельзя — можно только включать на момент split mirror для получения косистентной копии, например), так что опять только вариант восстанавления с ленточек.
Рекомендую перевести всю синхронизацию oracle на синхронный режим.
Он неработоспособен и при потере master массива невозможно будет запуститься на slave, кроме этого возможна потеря достаточно большого объема транзакций при последущем восстановлении с ленточек.
По потере — причина в том, что если БД работает достаточно активно и redo log switch происходит раз в минуту (что неправильно, но бывает), а в БД всего 3 группы redo, то через три минуты произойдет затирание redo, сгенерированного три минуты назад, а архивная копия лога из-за задержки на slave еще не доедет.
По невозможности подняться — из-за несинхронного режима 100% вероятность получить fractured oracle блоки (в которх разный rba в заголовке и в трейле) при пропадании master или просто при разрыве канала синхронизации. Fractured блоки oracle не умеет восстаналивать по redo (если только не был выполнен begin backup, но постоянно с этим жить нельзя — можно только включать на момент split mirror для получения косистентной копии, например), так что опять только вариант восстанавления с ленточек.
Рекомендую перевести всю синхронизацию oracle на синхронный режим.
Спасибо за развернутый комментарий. DBA в курсе, что у нас не синхронная репликация, по этому у нас 10-20 redo-файлов по 1гб каждый, в зависимости от базы. log switch раз в 1-2 минуты в среднем на нагруженных базах, что дает нам от 20 до 40 минут информации в redo.
В далеких планах конвертация 6280 в metro, но с этим есть ряд сложностей, как физически, так и финансово.
В далеких планах конвертация 6280 в metro, но с этим есть ряд сложностей, как физически, так и финансово.
Пожалуйста :)
Рекомендуемое oracle-ом время между log switch — 15-20 минут, так что рекомендую кроме количества также увеличить размер каждого redo хотя бы до 8Gb — это здорово снизит нагрузку по записи dwbr и немного увеличит mttr, что не так страшно.
По fractured блокам — попробуй на тестовой БД под умеренной нагрузкой провести эксперимент, разорвать синхронизацию и на стороне slave выполнить recover+open (restelogs). По моему опыту даже в синхронном режиме без begin backup не получится поднять копию БД.
Рекомендуемое oracle-ом время между log switch — 15-20 минут, так что рекомендую кроме количества также увеличить размер каждого redo хотя бы до 8Gb — это здорово снизит нагрузку по записи dwbr и немного увеличит mttr, что не так страшно.
По fractured блокам — попробуй на тестовой БД под умеренной нагрузкой провести эксперимент, разорвать синхронизацию и на стороне slave выполнить recover+open (restelogs). По моему опыту даже в синхронном режиме без begin backup не получится поднять копию БД.
Пробовали увеличить размер redo, заканчивалось это тем, что при log switch происходит сильный всплеск log file sync на базе из за копирования большого кол-ва информации в arch, что для некоторых приложений крайне не желательно, приложения зависают. Потому пока вот так.
Касаемо recover, я постоянно делаю копии для разработки на базе снапшотов, база не открывается в лучшем случае 1 раз из 20, может тут помогает оракловый dNFS? Пока базы жили на блочной СХД, без begin backup не поднимались вообще, да и с ним через раз.
Еще раз повторюсь, я не силен в oracle, потому пишу только то, что слышал «краем уха» общаясь с нашими dba и разбирая совместно с ними проблемы.
Касаемо recover, я постоянно делаю копии для разработки на базе снапшотов, база не открывается в лучшем случае 1 раз из 20, может тут помогает оракловый dNFS? Пока базы жили на блочной СХД, без begin backup не поднимались вообще, да и с ним через раз.
Еще раз повторюсь, я не силен в oracle, потому пишу только то, что слышал «краем уха» общаясь с нашими dba и разбирая совместно с ними проблемы.
Не понял про:
Поясните пожалуйста, как определили что iops ы равны. Ведь, например в классическом RAID хостовые iops = iops диска * на N (где N=1,2,4,6,6.66 итд)
спасибо!
Дисковые операции != кол-ву iops на nfs.
Поясните пожалуйста, как определили что iops ы равны. Ведь, например в классическом RAID хостовые iops = iops диска * на N (где N=1,2,4,6,6.66 итд)
спасибо!
Когда нагрузка выросла до 80% утилизации дисков, имеем лаг синхронизации для самых тяжелых баз порядка 15-20 минут постоянно, в моменты пиковой нагрузки (бэкап например, диски 90-95% утилизации), лаг увеличивается до бесконечности. Из чего следует, что никакого переключения за 5 минут быть не может, ибо только докатывание изменений в лучшем случае 20 минут + обратная ресинхронизация после разворота репликации, которая на больших разделах идет очень долго, те же 20 минут в лучшем случае.
Еще вопросик:
Какая пропускная способность канала? Он FC?
Ну и на последок, не рассматривали HP 3Par? просто учился на него недавно, думается мне что там нет таких проблем… по цене правда не уверен что адекватней
Саппорт нетаппа — редкостные долбо… бы. Причём речь не про начальные круги, а там, дальше. Существования проблем не признают, предлагаю при следующих авариях собирать статистику производительности для дальнейшего анализа.
Подпишусь под каждым словом. Если у вас есть разовая проблема, есть полное описание и логи, скриншоты базовой статистики, и хочется понять, что было сделано не так и кто виноват, дабы не повторилось, или возможно какой-то фикс — просят перфстат в момент проблемы, ничем помочь не могут и отвечают неделями. Из за них теперь все работы ночами, даже просто удаление снапшотов.
Просто интересно, а про support какой организации такого не скажешь?
Ну, например, HP. По замене гарантийного железа вообще все отлично, по глюкам — бывало приезжали специалисты и разбирались на месте. Это, естественно, про корпоративный сектор и дорогие железки.
Спасибо! А с каких железок начинается порог «дорогих»?
У них же поддержка через партнёров и приезжают их специалисты, а не из HP.
В Питере был довольно крупный отдел саппорта именно HP, я знаком был с несколькими инженерами оттуда.
Занятно, теперь осталось понять при каких условиях они включаются в работу.
Скорее всего залогом успеха является хороший сервисный контракт. Если у вас контракт «Proactive 24» или «Critical Service», у которых поддержка «24х7, 4h response» то в 100% случаев ты будешь говорить с самим HP.
По дисковым массивам я знаю, что у них стояли локально Eva и XP, так что они могли применить твою рабочую конфигурацию у себя и имитировать разные варианты решения проблемм в песочнице.
По дисковым массивам я знаю, что у них стояли локально Eva и XP, так что они могли применить твою рабочую конфигурацию у себя и имитировать разные варианты решения проблемм в песочнице.
что в претендентах были Hitachi, EMC и NetApp
А HP рассматривался? И если нет то почему?
Рассматривался HP P10000 3PAR. Не устроило, что они немного устарели на тот момент времени по сравнению со свежими, еще даже не начавшими продаваться новыми поколениями Symmetrix & VSP, отсутствие флеш-буфера и полное отсутствие поддержки FCOE, для нас это было важно. Мы очень хотели нативный FCOE, если уж говорить про блок, потому как нам очень не хотелось строить отдельную сеть SAN. Но в итоге то FCOE у нас все равно не работает :)
>>Потеря данных Oracle в случае краха одной из сторон — 0 секунд
Но у вас же репликация отстает. Это требование в итоге стало не критичным?
Мне периодически приходится делать дизайн схем резервирования и пока лучше DataGuard (тот который online redo apply делает)ни чего для себя не нашел. А хочется, т.к. цена на такое решение достаточно кусачая получается :-(
Но у вас же репликация отстает. Это требование в итоге стало не критичным?
Мне периодически приходится делать дизайн схем резервирования и пока лучше DataGuard (тот который online redo apply делает)ни чего для себя не нашел. А хочется, т.к. цена на такое решение достаточно кусачая получается :-(
При отставании записи в datafiles oracle должен восстановить все недописанное по archive и redo логам.
Что касается цены — второй сайт в любом случае подлежит полному лицензированию, так что разница в цене с DataGuard не столь велика должна быть.
Что касается цены — второй сайт в любом случае подлежит полному лицензированию, так что разница в цене с DataGuard не столь велика должна быть.
>>второй сайт в любом случае подлежит полному лицензированию
Холодные standby не лицензируются, на сколько я знаю. В случае аппаратной репликации, на другой стороне инстанс даже не запущен. А вот горячие standby, на которые применяется тот-же dataguard, лицензируются в полном объеме.
Холодные standby не лицензируются, на сколько я знаю. В случае аппаратной репликации, на другой стороне инстанс даже не запущен. А вот горячие standby, на которые применяется тот-же dataguard, лицензируются в полном объеме.
Эта информация устарела. Oracle все ужесточил, теперь можно не лицензировать только если на failover сервере не установлен soft и он физически не подключен к массиву :) Круто, да? ;)
НЛО прилетело и опубликовало эту надпись здесь
Есть фраза про постоянные замены железок по гарантии. А что летит чаще всего? И, кстати, какого объема СХД на ДЦ?
Дисков заменили — уже сбился со счета, заменили 4 блока питания дисковых полок и одну дисковую полку целиком. Сейчас еще будем менять память в одном из контроллеров, ошибки ECC. Общий полезный объем обеих 6280 — 228тб, 3270 — 54тб (метро-кластер, физически 108тб). Диски все SAS 600gb 3.5".
А как со временем замены? Быстро приходят новые диски и блоки?
А каждая замена диска, как-то влияет на производительность всего стораджа? Запускается же какой-то процесс ребилда для каждого случая?
И если они так часто летят, у вас небыло момента когда дисков могло вылететь столько что вы уже не сможете починить массив?
ps
Кстати, а что там за SAS диски внутри?
И если они так часто летят, у вас небыло момента когда дисков могло вылететь столько что вы уже не сможете починить массив?
ps
Кстати, а что там за SAS диски внутри?
> А каждая замена диска, как-то влияет на производительность всего стораджа?
Почти не заметно.
> Запускается же какой-то процесс ребилда для каждого случая?
Запускается автоматически в фоне, идет с небольшим приоритетом, 600гб диск за пару часов становится в строй.
> дисков могло вылететь столько что вы
По этому обычно держат hot-spare диск, как только один вылетел, стразу на spare начинается ребилд, Шансы что за этот час выйдет из строя еще 2 диска (raid-dp переживает выход 2 дисков, т.е. потеря данных будет только если помрут сразу 3) довольно низкие.
> уже не сможете починить массив?
Ну, а где бывают такие админы, у которых не сделаланы баккапы? :)
Почти не заметно.
> Запускается же какой-то процесс ребилда для каждого случая?
Запускается автоматически в фоне, идет с небольшим приоритетом, 600гб диск за пару часов становится в строй.
> дисков могло вылететь столько что вы
По этому обычно держат hot-spare диск, как только один вылетел, стразу на spare начинается ребилд, Шансы что за этот час выйдет из строя еще 2 диска (raid-dp переживает выход 2 дисков, т.е. потеря данных будет только если помрут сразу 3) довольно низкие.
> уже не сможете починить массив?
Ну, а где бывают такие админы, у которых не сделаланы баккапы? :)
Проблема не в железках Netapp, а в реализации проекта.
Еще вопрос к автору — а вы тестируете работоспособность баз\виртуальных машин в случае сбоя на одной из площадок? Оно действительно поднимается?
Целиком площадка не падала, падали сервера баз данных, переезжали сами. Падала сеть между ДЦ — не поднялось из за ошибок кластерного ПО, ошибка в конфигурации, сейчас проводим работу над ошибками, строим отдельную fencing-сеть, к счастью испытывать пока не пришлось.
Виртуалки переживают пока любые неприятности и работают без проблем, поднимаются сами, что бы не случилось.
В идеале конечно хочется получить автоматического возвращения работоспособности даже при падении всей площадки (например питание), но пока это немного хромает, есть над чем работать.
Виртуалки переживают пока любые неприятности и работают без проблем, поднимаются сами, что бы не случилось.
В идеале конечно хочется получить автоматического возвращения работоспособности даже при падении всей площадки (например питание), но пока это немного хромает, есть над чем работать.
>>к счастью испытывать пока не пришлось
Если не испытывать — нельзя быть уверенным, что в нужный момент всё отработает как надо. У нас некоторые клиенты специально, каждые полгода меняют местами ДЦ, чтобы в случае реальной проблемы все знали что делать и был ожидаемый результат.
Но то, что виртуалки и базы успешно переезжают — это в любом случае хорошо.
Если не испытывать — нельзя быть уверенным, что в нужный момент всё отработает как надо. У нас некоторые клиенты специально, каждые полгода меняют местами ДЦ, чтобы в случае реальной проблемы все знали что делать и был ожидаемый результат.
Но то, что виртуалки и базы успешно переезжают — это в любом случае хорошо.
Просто поменять местами и мы можем, и даже автоматом всё-всё сразу, только это не полный отказ всей площадки по питанию, или, что еще хуже, splitbrain из за экскаватора, разные немного вещи. Тут уже завязка на всю инфраструктуру, в которой еще и сеть присутствует, и вот сеть как раз сильно большое зло, когда у вас не отдельный от сети SAN. В теории мы знаем, что произойдет и как это лечить, а на практике — стараемся максимально закрыть все дыры, но всё время вылезает что-то новое.
7 лет работаю с NetApp системами. Про заполнение аггрегата есть баг, да. За этим надо следить, по всему остальному надо понимать как система работает и знать нюансы. Надо правильно её «готовить» ) А так системы отличные, если руки и голова есть, то будут работать как часы, годами.
Данный пост и предназначен для небольшого понимания внутренней «кухни» NetApp, не более того. Просто поделился наблюдениями. Идеальных универсальных систем не бывает. Есть только приближенные к идеалу на данном этапе развития, но и цена там…
Спасибо за статью, часто приходиться работать с поставщиками оборудования — на слайдах все красиво и прекрасно, но когда начинаешь устанавливать вылазят те или иные ограничения, сложности о которых поставщик «забыл» упомянуть. Это в принципе касается всех (и EMC и NetApp). Только реальный опыт подобный описанному вами дает понять где и у кого слабые места.
А есть системы за которыми не нужно следить :)?
madorc, при всём уважении, а вы не думали о FlashPool, если у вас NVRAM не справляется?
FlexShare — всё же не QoS, для того чтобы у вас был QoS вам нужно на C-Mode переходить.
Далее, если вам нужно «Потеря данных Oracle в случае краха одной из сторон — 0 секунд» — это Metro Cluster «адназначна»
Если у вас сильно загружены диски, то может всё же КЭШ добавить? Кстати какой у вас Cache Hit?
По поводу проблем со SnapMirror в разные стороны… хм… проверю… как-нибудь.
P.S. занимаюсь уже 7-й год как EMC так и NetApp'ом и могу вам сказать что NetApp никогда не скрывал про необходимость свободного пространства — скажите мне фамилию того кто вам не сказал про это :)
FlexShare — всё же не QoS, для того чтобы у вас был QoS вам нужно на C-Mode переходить.
Далее, если вам нужно «Потеря данных Oracle в случае краха одной из сторон — 0 секунд» — это Metro Cluster «адназначна»
Если у вас сильно загружены диски, то может всё же КЭШ добавить? Кстати какой у вас Cache Hit?
По поводу проблем со SnapMirror в разные стороны… хм… проверю… как-нибудь.
P.S. занимаюсь уже 7-й год как EMC так и NetApp'ом и могу вам сказать что NetApp никогда не скрывал про необходимость свободного пространства — скажите мне фамилию того кто вам не сказал про это :)
Есть полноценный QoS с ограничением по IOPS или MB/s — он доступен в cDOT.
Никакой связи в записи с объемом кэша нет — запись ведется через NVRAM, который размером в несколько гигабайт.
Про все остальное прекрасно ответил bakset.
Никакой связи в записи с объемом кэша нет — запись ведется через NVRAM, который размером в несколько гигабайт.
Про все остальное прекрасно ответил bakset.
Все пять проблем, которые перечислил Заказчик, в большей степени связаны с некорректным использованием функционала NetApp и/или некорректным дизайном систем хранения FAS6280 под окружение Заказчика.
Первая проблема скорее всего связана с ограничениями, которые накладывает Sync SnapMirror (например превышение количество параллельных потоков реплицирования или реплицирование томов, находящихся на одном агрегате с дедуплицированными томами)
Вторая проблема — количеств изменений в байтах (новых блоков данных) за заданный промежуток времени превышает время, за которое эти изменения могут реплицироваться на удаленную систему
Третья проблема — уже озвучили (Storage QoS появился в cDOT)
Четвертая проблема — свободное место в агрегате. Есть такая фича у NetApp, но это должен знать архитектор решения и закладывать необходимый объём.
Пятая проблема — опять же проблема дизайна, если в одном агрегате диски нагружены на 100%, а в другом агрегате на 10% — это неверная конфигурация, неправильное распределение количества шпинделей по агрегатам и/или распределение типов данных по агрегатам.
Системы то хорошие )))
Первая проблема скорее всего связана с ограничениями, которые накладывает Sync SnapMirror (например превышение количество параллельных потоков реплицирования или реплицирование томов, находящихся на одном агрегате с дедуплицированными томами)
Вторая проблема — количеств изменений в байтах (новых блоков данных) за заданный промежуток времени превышает время, за которое эти изменения могут реплицироваться на удаленную систему
Третья проблема — уже озвучили (Storage QoS появился в cDOT)
Четвертая проблема — свободное место в агрегате. Есть такая фича у NetApp, но это должен знать архитектор решения и закладывать необходимый объём.
Пятая проблема — опять же проблема дизайна, если в одном агрегате диски нагружены на 100%, а в другом агрегате на 10% — это неверная конфигурация, неправильное распределение количества шпинделей по агрегатам и/или распределение типов данных по агрегатам.
Системы то хорошие )))
nice try, NetApp
Кстати на счёт пятой проблемы, наверно действительно дело в дизайне. Как так получилось, что один агрегат более нагружен чем второй? Этот вопрос нужно было решить на этапе внедрения, если это не представлялось возможным по каким-то причинам «предугадать» сайзером.
Положительная сторона в том, что в новой версии 8.2 C-Mode появилась возможность агрегаты переключать на ходу между контроллерами (ARL), а функционал vol move доступен бесплатно и тоже может онлайн мигрировать тома между агрегатами. Таким образом даже в направильно сбалансированной системе теперь можно перераспредилить нагрузку между агрегатами и контроллерами с гранулярностью до вольюма.
А вообще любым инструментом можно сделать что-нибудь «не то», если очень «захотеть».
Положительная сторона в том, что в новой версии 8.2 C-Mode появилась возможность агрегаты переключать на ходу между контроллерами (ARL), а функционал vol move доступен бесплатно и тоже может онлайн мигрировать тома между агрегатами. Таким образом даже в направильно сбалансированной системе теперь можно перераспредилить нагрузку между агрегатами и контроллерами с гранулярностью до вольюма.
А вообще любым инструментом можно сделать что-нибудь «не то», если очень «захотеть».
Не понял про:
Поясните пожалуйста, как определили что iops ы равны. Ведь, например в классическом RAID хостовые iops = iops диска * на N (где N=1,2,4,6,6.66 итд)
Еще вопросик:
Какая пропускная способность канала? Он FC?
Ну и на последок, не рассматривали HP 3Par? просто учился на него недавно, думается мне что там нет таких проблем… по цене правда не уверен что адекватней
Спасибо!
Дисковые операции != кол-ву iops на nfs.
Поясните пожалуйста, как определили что iops ы равны. Ведь, например в классическом RAID хостовые iops = iops диска * на N (где N=1,2,4,6,6.66 итд)
Когда нагрузка выросла до 80% утилизации дисков, имеем лаг синхронизации для самых тяжелых баз порядка 15-20 минут постоянно, в моменты пиковой нагрузки (бэкап например, диски 90-95% утилизации), лаг увеличивается до бесконечности. Из чего следует, что никакого переключения за 5 минут быть не может, ибо только докатывание изменений в лучшем случае 20 минут + обратная ресинхронизация после разворота репликации, которая на больших разделах идет очень долго, те же 20 минут в лучшем случае.
Еще вопросик:
Какая пропускная способность канала? Он FC?
Ну и на последок, не рассматривали HP 3Par? просто учился на него недавно, думается мне что там нет таких проблем… по цене правда не уверен что адекватней
Спасибо!
Учитывая эти и другие накладные расходы, сколько в результате полезного пространства может быть использованно в каждом из агрегатов в абсолютных значениях?
Я имею ввиду более конкретно, а то расплывчато получается.
К примеру:
=======================Пример===========================
Есть СХД FAS6280 с двумя контроллерами
У контроллера «А» есть 48 диска 600ГБ
Создан агрегат aggr0 из (21+2) + (21+2) (т.е 2x RAID-DP) + 2х спардиска
Итого полезного RAW пространства грубо говоря 2*21*600 = 25200 ГБ
df -A -h для агрегата aggr0 показывает 22ТБ из них реально заюзать чтобы не падал перфоменс 19TB.
=======================Пример===========================
В таком духе.
Спасибо.
Я имею ввиду более конкретно, а то расплывчато получается.
К примеру:
=======================Пример===========================
Есть СХД FAS6280 с двумя контроллерами
У контроллера «А» есть 48 диска 600ГБ
Создан агрегат aggr0 из (21+2) + (21+2) (т.е 2x RAID-DP) + 2х спардиска
Итого полезного RAW пространства грубо говоря 2*21*600 = 25200 ГБ
df -A -h для агрегата aggr0 показывает 22ТБ из них реально заюзать чтобы не падал перфоменс 19TB.
=======================Пример===========================
В таком духе.
Спасибо.
19ТБ реально заюзать.
Реально заюзать и больше чем 22ТБ, использую thin provisioning и deduplication, совместное их использование даёт около 50% экономии пространства, при очень минимальном влиянии на производительность.
Реально заюзать и больше чем 22ТБ, использую thin provisioning и deduplication, совместное их использование даёт около 50% экономии пространства, при очень минимальном влиянии на производительность.
WTF?
Конкретику пожалуйста, выше пример.
Конкретику пожалуйста, выше пример.
Сорри ниже ошибся с местом ответа, продублировал, а старый уже отредактировать не могу (
Конкретика простая.
Пример аггрегат 20ТБ,
Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
На vol включается дедупликация
На каждом из этих vol делается по одному Thin LUN на 2ТБ.
Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
Как то так )
Конкретика простая.
Пример аггрегат 20ТБ,
Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
На vol включается дедупликация
На каждом из этих vol делается по одному Thin LUN на 2ТБ.
Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
Как то так )
Спасибо, интересно узнать конкретику заказчика по примеру выше.
Хтелось бы удостовериться, что не имеет место следующий случай:
Что при экономии на RAID-DP и с учётом всех оверхедов, мы получаем полезного пространства больше чем кто-бы то из вендоров-конкурентов мог бы предоставить на высоконагруженных задачах, но так как хотелось ещё больше, съели лишнее пространство (весь резерв системы рекомендуемый по бестпрактису) и получили «проблему у нетапа».
Хтелось бы удостовериться, что не имеет место следующий случай:
Что при экономии на RAID-DP и с учётом всех оверхедов, мы получаем полезного пространства больше чем кто-бы то из вендоров-конкурентов мог бы предоставить на высоконагруженных задачах, но так как хотелось ещё больше, съели лишнее пространство (весь резерв системы рекомендуемый по бестпрактису) и получили «проблему у нетапа».
Конкретика простая.
Пример аггрегат 20ТБ,
Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
На vol включается дедупликация
На каждом из этих vol делается по одному Thin LUN на 2ТБ.
Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
Как то так )
Пример аггрегат 20ТБ,
Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
На vol включается дедупликация
На каждом из этих vol делается по одному Thin LUN на 2ТБ.
Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
Как то так )
Правильно ли я понимаю, что 30 сессий синхронной репликации на контроллер в одну сторону система выдерживает?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Netapp — реальность против маркетинга