Зачем бэкап? У нас же RAID



    В корпоративные блоги принято писать success story — это положительно влияет на образ компании. К сожалению, не всегда в работе инженера всё заканчивается happy end-ом.
    Надо сказать, что коллеги уже начинают подшучивать, что я «притягиваю» проблемы. Тем или иным образом я поучаствовал почти во всех проблемных заявках за последнее время. И теперь хочу рассказать одну поучительную историю из своей практики.

    История началась с того, что меня попросили проанализировать производительность дискового массива одной СХД, «тормоза» которого парализовали работу целого филиала. Исходная ситуация такая:

    • На массиве находятся датасторы VMware-фермы.
    • Все тома располагаются на RAID5 (диски 7200 и 10000) и зеркалируются между двумя идентичными массивами.
    • Контракта с ведором на поддержку этого оборудования нет.
    • Версия прошивки массива — 7.3.0.4 (актуальная на тот момент 7.6.1.1).
    • Также СХД используется для виртуализации СХД HP EVA.

    Согласно логам производительности массива, «тормоза» возникали не из-за повышенной нагрузки. Я заподозрил, что причиной проблем является вышедший из строя контроллер на виртуализованной СХД HP EVA. Обычно проблемы с производительностью решаются удалённо, но в данном случае решили отправить инженера на место (тогда ещё никто не подозревал, что командировка затянется на две недели).

    И тут в ходе анализа производительности начал проявляться «полтергейст»: у томов с массива в интерфейсе vSphere периодически отображается неверный объём (от отрицательного до десятков петабайт), что заказчик расценил как проблему в массиве. При этом пропадал доступ к консолям части виртуальных машин, и возникают другие неприятности. Даже я уже начал нервничать, а заказчик просто в ауте.

    И тут начинается просто фейерверк проблем.

    Мы нашли баг ESXi, из-за которого могут отображаться неверные размеры томов. Но выясняется, что официального контракта на поддержку VMware нет. Поддержка осуществляется сторонней компанией и только по рабочим дням, а дело происходит в субботу.



    Для полного счастья, прошивки двух серверов из трёх и коммутаторов (блейд-шасси) отстают от прошивки модуля управления шасси, что тоже может приводить к самым неожиданным проблемам. Ну и вишенка на торте: на коммутаторах SAN стоят разные версии прошивок, и все позапрошлой мажорной версии (6.x.x, когда доступна 8.0.x).

    Напоследок выясняется, что в MS SQL Server Express закончилось свободное место, из-за чего возник «полтергейст» с доступностью консолей VM в vSphere и неверно отображались размеры томов. Так что пока администраторы решали проблемы БД, мы пытались разобраться с СХД.

    После некоторых действий основной том вдруг ушёл в оффлайн.

    Мы вспоминили про баг в прошивках СХД версий 7.3, 7.4 и 7.5, из-за которого на сжатых томах после определённого количества обращений могут появиться битые блоки (в этой ситуации не может помочь ни отказоустойвость RAID, ни зеркалирование томов на соседний массив, так как ошибка находится уровнем выше).

    И вот тут проявился самый интересный нюанс: оказывается, что СРК у заказчика не работает уже 3 месяца. То есть бэкапы есть, но они не актуальные, и восстанавливаться из них — всё равно, что потерять данные.

    Нам удалось перевести том в онлайн (через CLI массива), но при первой же попытке хоста что-то записать, он снова упал. Мы отключили все датасторы на серверах и следующие сутки провели в офисе, почти не дыша копируя все виртуальные машины куда получится — на серверы, USB-диски и ПК.

    В результате нам удалось спасти все данные, кроме ВМ, на которой запустили консолидацию снапшотов, так как в процессе консолидации LUN ушёл в оффлайн, и вместо данных ВМ осталась «каша». По закону подлости это оказалась ВМ электронного документооборота. Кроме того, для исключения разных рисков пришлось обновить почти всю инфраструктуру — VMware, Brocade, HP Blade и так далее.

    Предпосылки катастрофы


    Какие выводы может сделать из этой истории уважаемый читатель, чтобы не оказаться в подобной ситуации?

    1. СХД была спроектирована некорректно. Один том на ~12 Тб не будет нормально работать ни на одной классической СХД. Всегда разбивайте общую ёмкость на тома порядка 1-2 Тб. Да, будет меньше полезной ёмкости, но зато будет гораздо меньше шансов открыть заявку «у нас всё тормозит». UPDATE: На многих СХД с блочным доступом могут наблюдаться проблемы производительности при интенсивном доступе многих хостов к одному луну (например, кластеры виртуализации). В таких ситуациях лучше разбивать тома на более мелкие, чтобы не упереться в очередь команд на LUN.
    2. Прошивки никогда не обновлялись. Это не единственная история, когда баг в старой прошивке приводил к простоям или потере данных. Да, в новых прошивках тоже есть баги, но вас никто не принуждает пользоваться bleeding edge. Используйте стабильные, рекомендованные версии.
    3. Бэкапы. Сколько было просьб и рекомендаций делать и проверять бэкапы — не счесть. Повторяться не хочется, но ВСЕГДА ДЕЛАЙТЕ И СВОЕВРЕМЕННО ПРОВЕРЯЙТЕ БЭКАП. В этой истории можно было сократить время простоя не менее, чем в два раза, если бы СРК поддерживалась в рабочем состоянии.



    4. Не было вендорской поддержки оборудования. У нас отличные специалисты, с глубоким знанием оборудования, но бывают ситуации, когда помочь может только вендор.
    5. Не мониторилось свободное место в БД. Следите за свободным местом не только на дисках, но и в БД.

    Спасибо за внимание, работы вам без сбоев.

    Алексей Трифонов Tomatos, инженер Сервисного центра компании «Инфосистемы Джет».
    Инфосистемы Джет 146,09
    Компания
    Поделиться публикацией
    Комментарии 103
    • +1
      После этого случая начали регулярно делать бэкапы?
      • +4
        зачем? RAID же есть!!!
        • +3
          Зачем RAID? У нас же серверные отказоустойчивые диски!!!
          • +3
            Зачем Enterprise HDD? Дорого! На Desktop HDD все закрутим!!!
            • +3
              Зачем Desktop HDD? Можно же восстановленные диски купить!!!
              • +3
                Зачем восстановленные? Можно китайский ноунейм взять!!!
                • +1
                  Зачем китайский ноунейм hdd? Можно на али 50 микросд карт на 1 терабайт каждая за 100 баксов заказать!
                • 0
                  Зачем? можно в облако, и далее ситуация в облаке: «После этого случая начали регулярно делать бэкапы?»…
                  • 0
                    Зачем облако в ЦОД с Teer 3? Можно с Teer 1 взять!!!
                    • +1
                      Можно бэкапить кучей архивов на диск компа директора
                      • +1
                        Только на рабочий стол
                        • +3
                          А чтоб на столе не мешалось — можно в корзину положить, только не очищать!
                          • +2
                            Ой, я что-то нажал и всё пропало…
                            • 0
                              Оно само, я ничего не трогал!
          • 0
            Многие новые популярные СУБД плохо переносят резервное копирование — кластерные MongoDB, Cassandra — их предпочитают резервировать с помощью добавления дополнительных нод.
            • 0
              CommVault вроде их поддерживает или проблема с просадкой производительности во время бекапа?
              • +1
                Нода, с которой тянется бэкап перестает принимать изменения с других нод, данные на ней отстают от остальных, бэкап некосистентный получается, потом нода начинает догонять остальные ноды, а это излишняя нагрузка не всё.
                Бэкап этих СУБД делают другими способами — репликация на другие ноды и снэпшоты на СХД.
                • 0
                  Что значит «неконсистентный бекап»? Всмсле не рабочий или в смысле «со старыми данными»?
                  • 0
                    Согласованность данных (иногда консистентность данных, англ. data consistency) — согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость.
                    Kонсистентность является важнейшим понятием теории управления данными (data management) и входит в четвёрку ACID (Atomicity, Consistency, Isolation, и Durability) — Атомарность, Консистентность, Замкнутость и Живучесть (стойкость).

                    В СУБД больших размеров за время резервного копирования происходят записи данных и часть некоторые транзакции могут не попасть на конкретную ноду из-за того, что она в режиме резервного копирования находится.

                    • 0
                      Ну так получается что если «нода в режиме резервного копирования находится» — данные на ней не меняются? То есть мы делаем бекап того момента что был на начало бекапа, верно? То есть бекап у нас получается «рабочий», просто «некоторые транзакции могут не попасть на конкретную ноду»? Вопрос актуальности данных, или в том что такой бекап просто не рабочий, не поднимитсяпотом, поднимится нето и т.д.? Спрашиваю без издёвки, просто интерес.
                      • 0
                        Нода не полностью отваливается и часть данных может на нее писаться. Есть вариант полностью запрещать запись на эту ноду, но фокус в том, что на конкретной ноде не лежат ВСЕ данные — структура построение такова, что данные разбиты на части — шарды и чтобы получить полный бэкап всех данных — бэкап надо тянуть со всех шардов. Что вызывает рассогласование в них.
                        • +3
                          Блин, вот это жесть. В такие моменты радуюсь что не админ…
                          • +3
                            Это не жэсть — просто это некоторая специфика — вот у нас была рассмотрении заявка на поддержку одного банка — СУБД Cassandra, 100ТБайт данных, около 100 нод, каждая 64-128ГБ оперативки. По СХД и прочему — не обладаю информацией.

                            Как ЭТО бэкапить — очень не простой вопрос. Скорей всего на уровне СХД и разнос в разные датацентры.
                            • 0
                              Хватит рассказывать ужасы! :)
                              • 0
                                Очень странно, ведь в СУБД должна быть предусмотрена возможность синхронного бэкапа с нескольких нод.
                                • 0
                                  Про mongo уже писал
                                  To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.
                                  • +1
                                    Что касается Cassandra — то подключение идет к координатору и в зависимости от настроек, он может не дожидаться ответа от всех узлов об успешной записи данных.

                                    Узлы кластера кассандры равноценны, и клиенты могут соединятся с любым из них, как для записи, так и для чтения. Запросы проходят стадию координации, во время которой, выяснив при помощи ключа и разметчика на каких узлах должны располагаться данные, сервер посылает запросы к этим узлам.
                                    Для каждого запроса, как на чтение, так и на запись, есть возможность задать уровень согласованности данных.
                      • 0
                        Что значит «неконсистентный бекап»? Всмсле не рабочий или в смысле «со старыми данными»?


                        В смысле, что база портится от того, что для некоторых БД — VSS не указ, или его (или аналога) просто нет.
                  • 0
                    Их тоже можно и нужно бэкапить, дополнительные ноды это тот же RAID)
                    • 0
                      Согласен — и если они в другом датацентре — то будет обеспечена и катастрофоустойчивость — пожары, наводнение и прочее.
                      Только не защищает от логических ошибок такая организация бэкапа.
                      • 0
                        Я хотел сказать, реплики в другом ДЦ и RAID это не бэкап. Бэкап — это то что нужно (чаще всего) когда сам стёр или испортил данные. Метеориты падают в ДЦ или отдельно взятые RAID-массивы гораздо реже. Поэтому бэкапить все равно надо. Есть способы сделать это и для кластера mongodb, они даже описаны в документации.
                        • 0
                          В доках у них много чего, но на первом месте у них Back Up a Sharded Cluster with File System Snapshots.
                          А про mongodump
                          IMPORTANT
                          To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.

                  • 0
                    Насколько мне известно, бэкапиться они начали, но насколько часто они проверяют бэкапы, сказать затрудняюсь.
                  • 0
                    про выводы:

                    1 — По поводу томов по 1-2 тб, тут как мне кажется нужно привязываться к физическим дискам, а не к размеру тома. Ну и главный вопрос о том сколько хостов работают с этим томом, должно быть несколько томов на разных физических дисках и желательно чтобы том не выходил за приделы одной корзины, если говорить про классическую схд =)

                    2 — Через версии прошивок тоже прыгать не очень хорошо, у меня так отвалились все луны когда я прыгнул через версию =( (HP MSA p2000 G3), но конец был с хепиендом и без потери данных.
                    • 0
                      1. Если честно — странные советы. К размеру дисков привязывается размер RAID-группы, которые вы можете обклеил в пул и на нем резать нужного размера тома.
                      Как я написал ниже рекомендации по поводу размера томов я даю из других сладкий.
                      2. Именно поэтому работа заняли столько времени — мы не прыгали через версии, а обновлялись последовательно.

                      Кстати, одна странность нам сыграла на руку — администратор заказчика во время действовавшей поддержки вендора выкачивал прошивки, но почему-то опасался обновляться.
                      • 0

                        Объясните популярно по поводу 1-2 Тб томов, пожалуйста. Если у меня кластер виртуализации, то чем плох Один Большой Кластерный Том? Что делать с 10 томами по 2 Тб?

                        • 0

                          Тут как всегда несколько факторов:


                          1. СХД — если она нормально работает и рост нагрузки не планируется — менять ничего не стоит. Если одно из этих условий не выполняется — нужно смотреть подробнее. Если в кратце — несколько лунов позволят распараллелить запросы. Но это не объём комментария.
                          2. Виртуализация — несколько мелких ФС проверяться быстрее, чем одна большая.
                          3. Если вам нужен именно один большой том и никак иначе — нудно выбирать СХД с учётом этого, но я не очень представляю задачу, когда нужен один том на 100500 ТБ
                          • 0

                            Если что, то VMware тома поддерживает не более 64TB, Windows до 256TB, какая-нибудь EXT4 в Linux до 50TB. Это не значит, что всегда нужно выбирать максимальные значения. Но найти в наше время задачи, при которых 1TB будет не достаточно виртуалке, не проблема.

                            • 0
                              Если в кратце — несколько лунов позволят распараллелить запросы.


                              лунов, а не рейдов или чанков под ними?
                              • 0

                                Да, в данном случае имелось в виду ограничение на LUN queue depth. На современных массивах это уже почти не актуально, но прошлое и позапрошлое поколения массивов могут в него упираться иногда.

                      • 0
                        кстати про бэкапы. первая картинка как бэ намекает, но почему не сказано, что бэкапы нужно хранить в другой локации? а то если в одной… пожар и всё… пропало всё…
                        • 0
                          Мои коллеги тоже сталкивались с мистическими сбоями EVA. Правда вовремя успели все перенести, даже не пришлось обращаться к резервным копиям.
                          Не совсем в тему, но вспомнилась локальная шутка:
                          После всех грехов с EVA мы получили в догонку 3PAR.
                          • 0

                            В этой истории с EVA не было ничего мистического — просто вышел из строя контроллер и, кажется, модуль управления.

                            • 0
                              В нашем случае подглючивал один из контроллеров. Волшебным образом все тесты показывали норму, а в реальных условиях происходили отвалы. В итоге все перенесли на 3Par. Почти сразу после этого оно сдохло совсем.
                          • 0
                            Backup and recovery of your Oracle database is important to protecting data from corruptions, hardware failures, and data failures. While Oracle provides many features to protect your data, nothing can replace a backup.
                            http://www.oracle.com/technetwork/database/features/availability/br-overview-097160.html

                            Первая и самая главная заповедь.
                            • 0
                              Уж насколько я не люблю оракл как контору, но здесь просто нельзя с ними не согласиться.
                            • 0
                              Один том на ~12 Тб не будет нормально работать ни на одной классической СХД.

                              DDP на NetApp E-series — будет.
                              • +1

                                Да на самом деле много где будут работать и не жужжать. Совет из тематики "обжёгшись на молоке, дуешь и на воду". В целом странно видеть в наше время подобные рекомендации. Как и про "не выходить за пределы одной корзины" на классических СХД.


                                С таким же успехом можно рекомендовать использовать локальные диски, а все диски, что размером 2Tb и больше, разбивать на разделы по 1Tb. Это уж точно сбережет ваши данные.

                                • 0
                                  Чуть ниже ответил о причинах таких рекомендаций. Опять же это рекомендации — каждый волен следовать им или нет.
                                  Из опыта работы с СХД я для себя сделал вывод — лучше объединить несколько томов средствами ОС. Если можно почти безболезненно распараллелить запросы — зачем ставить их в одну очередь?
                                  • 0

                                    Каким образом вы объедините несколько томов например в VMware кластере, не увеличивая при этом размер VMFS? Или вы предлагаете использовать софтовый рэйд уже внутри виртуальной машины? Для примера в Win server можно использовать софтовый RAID, вот только на моей практике ничего кроме Raid1. Иначе резко повышаются шансы потерять все. А Raid1 не позволяет увеличить размер тома.


                                    При этом, в текущей реальности, размер тома внутри одной виртуальной машины более 1TB далеко не экзотика. А количество одновременных запросов на один логический том вполне поддается тюнингу почти во всех современных OS. (Для примера https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1268).


                                    Я работаю с кластерами VMware и СХД с 2008 года. Из СХД последовательно были HP MSA2000, EMC Clariion CX4, VNX5300. Мой опыт показывает, что если не пускать все на самотек и поддерживать в актуальном состоянии софт и версии прошивок железа, то никаких проблем с томами размером более 2TB нет. При том что подавляющее большинство обновлений выполняется без остановки ввода\вывода.

                                    • 0
                                      ESXi умеет работать с Datastore, который имеет несколько LUN — я так обходил проблему, что ESXi не видел LUN больше 2TB и я нарезал хранилку на 3 LUN.
                                      • 0

                                        Это се понятно. Только вот луны там соединяются в этакий JBOD, а это не позволяет балансировать по ним нагрузку. И уж точно не уменьшает размер VMFS (а как раз наоборот). Т.е. не приносит тех "преимуществ", о которых писал Tomatos ниже.

                                        • 0
                                          Вопрос в ограничениях vmfs хороший — LUN можно подкидывать уже после первоначального форматирования первого LUN, а потом подкидывать LUN по мере надобности. И тут возникает вопрос — как оно для ESXi выглядит — но наверное оно расширяется просто и все.
                                          • 0
                                            В случае с ESXi это выглядит как JBOD. Вот так данные размещаются на дисках: image
                                            Никакой балансировки или отказоустойчивости.
                                            • 0
                                              Как оно выглядит я представляю, так как делал сам. Вопрос был примерно такой — это одна цельная vmfs или все же достаточно независимые части.
                                      • 0
                                        Как вы сами сказали, не стоит пускать всё на самотёк и стоит планировать свою инфраструктуру. Если нужны ВМ с одним диском большого объёма или интенсивным IO — можно такие ВМ выносить на отдельные датасторы.
                                        В конце статьи я написал рекомендации, которые стоит учитывать, не правила. Каждую конкретную конфигурацию нужно внимательно рассматривать и планировать.
                                        Спасибо за ваши замечания.
                                  • 0
                                    Даже на EMCшном допотопном CLARiiON CX4-CX4 всё будет норм. Как и на не-помню-чём Hitachi с тремя layer и межцодовой репликацией. Как и на большинстве встроенных контроллеров, да чего уж там, 12 ТБ это по нынешним меркам вообще тупо зеркало :)
                                    • 0

                                      В большинстве случаев — да.

                                  • 0
                                    Так с современным подходом к VMWare, если использовать VSAN (HDD + SSD), 3 ноды и каждая виртуалка имеет зеркальную копию — получается RAID массивы вообще не нужны. А бэкапы делаются чтобы исключить ошибку в базе
                                    • 0
                                      А какая стоимость VSAN для трех нод?
                                      • 0
                                        По 180/280 тыр за процессор, но всё же рекомендуют минимум 4 ноды для нормального обслуживания, так как данные остаются без резервирования при выключении одной ноды из трёх.
                                        • 0
                                          итого от 3к уе за процессор, 3*3=9к уе, и это только стоимость лицензий.
                                          за соизмеримую сумму можно купить HP MSA с дисками…
                                          • 0
                                            MSA 2050 без дисков стоит 7.5к, так что гибридная выйдет тысяч в 20.
                                            • 0
                                              и что HP MSA даст вам полностью отказоустойчивый кластер?
                                              • 0
                                                В случаи 3х-4х и больше серверов, HP MSA таки легко даст вам отказоустойчивый кластер VMware HA/FT. У меня в эксплуатации больше 10 шт MSA — ооочень надежные «машины» — не смотря на то что один раз за 7 лет у меня был неприятный глюк с обновление прошивки одной из схд…
                                                • 0
                                                  А теперь давайте представим выход из строя этой HP MSA.
                                                  • 0
                                                    =) ну и как вы представляете выход всех компонентов из строя (которые задублированы)? да, вероятность такого события не 0, и думаю что такое возможно достичь только в случаи если применить кривые руки. Как уже заметили — наличие рейда или схд не отменяет необходимости делать резервные копий, и еще хранить эти копии на другой площадке…
                                                    • 0
                                                      Очень даже представляю. Так как сталкивался с таким событием, имея СХД от IBM. Есть такое правило — если есть точка отказа, значит есть вероятность что этот отказ таки случится! Хоть вероятность его и очень мала. А вот в случае VMWare VSAN такой точки нет!
                                                      • +1
                                                        Хоть вероятность его и очень мала. А вот в случае VMWare VSAN такой точки нет!


                                                        матчасть учить мы вас попросим: гугль: my nightmare with vsan
                                                      • +1
                                                        Вы зря так скептически настроены по поводу выхода из строя массива, тем более LowEnd. У нас много историй остановки «всего» из-за поломки даже HighEnd оборудования.
                                                        Например, однажды у одного заказчика в течение полугода из-за ошибки в микрокоде было два останова — в первый раз вышел из строя HighEnd массив одной «японской» компании, в другой раз HighEnd сервер большой компании с голубым логотипом.
                                                        Хорошо, что у них две географически разнесённые площадки и простой был минимален или его не было совсем, но факт остаётся фактом.
                                                        • 0
                                                          а если так задаст вопрос )) чтобы вы выбрали LowEnd/HighEnd массив или софтварный VMWare VSAN? Для задач где оборудование используется только для внутренних задач компании не не сдается в «аренду».
                                                          • 0
                                                            Я по любому выберу VSAN. Узлы можно разместить в разных ЦОДах, что совсем сведёт время простоя в случае отказа к нулю.
                                                            • 0
                                                              vSAN не серебряная пуля — у него есть свои ограничения.
                                                              СХД точно так же можно разместить на разных площадках и реплицировать данные между ними. И точно так же как и с vSAN простой будет минимальным или его не будет.
                                                            • 0

                                                              К сожалению, серебряной пули не существует и наши проектировщики каждый конкретный случай всегда рассматривают отдельно, на сколько мне известно.
                                                              В вашей ситуации я бы выбрал shared datastore. На чем он будет лежать — нужно смотреть подробнее.
                                                              Нюансов много — latency, iops, стоимость оборудования и поддержки, требования ко времени простоя и срокам ремонта, наличие компетенции внутри компании.
                                                              Последний момент не менее важен. Представьте себе, что вы всю жизнь работали с Solaris и тут боевую систему за которую вы отвечаете переводят на AIX. Я такое видел — перестроиться сложно и это вызовет много проблем просто из-за того, что "как это не умеет?"
                                                              Если у вас есть хорошая компетенция по vSAN — ставьте его, но перед этим все равно сравните с классическими СХД.

                                                              • 0

                                                                Что-то меня переклинило на серебряных пулях :)

                                              • 0
                                                Не вкурсе. Покупкой другое люди занимались.
                                            • 0
                                              У Storwize v7000g1 еще был классный баг (точнее не у нее, а у Linux Kernel) c ребутом раз в 208 дней. СХД работала в режиме 24/7 после установки, страшно было шить, но успели :)
                                              • +1
                                                Имхо, это история не о резервном копировании, а о стратегии руководства компании, которое влило денег в железо, но скроило на квалификации эксплуатирующего персонала и на обеспечении эксплуатации. А кроилово ведёт к попадалову (с)…
                                                • +2
                                                  Тут на железе тоже экономия, поддержку не купили. Очень сложно обосновать покупку поддержки на железо руководству (особенно если все работает), желательно сразу при покупке заложить ее на максимальный срок.
                                                  • 0
                                                    Поддержка- это как раз и есть обеспечение эксплуатации. Обосновывать тяжело. Ещё надо помнить о горячем/холодном резерве и времени восстановления при отказе (иметь план восстановления). Поэтому каждое утро молитва и медитация :) В итоге приходим к тому, что организационные проблемы аппаратными средствами не решаются ( с), а из принципа Парето следует, что на технику приходиться 20% беды. Остальное — ручки шаловливые, головы буйные да начальники скаредные…
                                                  • 0

                                                    Мой задачей было рассказать. Выводы читатель волен делать сам.

                                                  • –1
                                                    Согласен с выводом 1. Том более 2 ТБ. под VMware.Удачи при ремонте. Накроется — молитесь.

                                                    Для больших данных есть же другие технологии.
                                                    • 0
                                                      Согласен с выводом 1. Том более 2 ТБ. под VMware.Удачи при ремонте. Накроется — молитесь.

                                                      А есть ли какие то зависимости от размера дисков? например в СХД 12 дисков по 1,2 ТБ.
                                                      как из правильно собирать в RAID? Размер тома не должен превышать 2ТБ?
                                                      то есть надо делать 4 LUN по 3 диска в RAID5?
                                                      Или еще вариант 12 SSD по 400 гигабайт. делаем 2 LUN по 6 дисков RAID5?
                                                      И есть ли какая — то информация на эту тему?
                                                      И связанно ли это с тем что меньший массив дисков проще собрать обратно?
                                                      • 0
                                                        2Тб для вари — это ограничение на размер диска было.
                                                        The limits that apply to VMFS-5 datastores are: The maximum virtual disk (VMDK) size is 2 TB minus 512 B for ESXi 5.0 and 5.1. In ESXi 5.5, the size is increased to 62TB.

                                                        как из правильно собирать в RAID? Размер тома не должен превышать 2ТБ?

                                                        значение имеют в первую очередь требуемые IOPS, которые считаются от нагрузки.
                                                        • 0
                                                          В моих рекомендациях имеется в виду именно размер LUN — на одной RAID-группе вы можете создавать любое, удобное Вам количество LUN-ов, ограниченное только прошивкой Вашего массива.
                                                          А рекомендации по размерам томов даются из следующих соображений:
                                                          1. Длительная проверка ФС. ФС поменьше можно проверять параллельно.
                                                          2. У LUN-ов есть параметр «очередь команд», если много хостов (например, VMware-кластер) одновременно будут обращаться к одному тому — производительность будет заметно ниже, варианта с несколькими datastore-ами поменьше. (особенно это хорошо заметно на HDS AMS и HUS).
                                                          • 0

                                                            RAID5 Еще используют для больших объемов? Встречал информацию, что восстановление полетевшего диска весьма накладно получается по временным затратам, а это все тормоза системы сутками.

                                                          • 0
                                                            https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2058287

                                                            • 0
                                                              Да, диски больше 2 Тб давно поддерживаются «всеми». Я не об этом. Я о том, что зачастую дробление LUN часто позволяет повысить производительность дисковой подсистемы.
                                                            • 0
                                                              А пост-то в тему! Вчера только диск полетел. Сижу, копирую что осталось, седые волосы фломастером подкрашиваю… Обещаю себе обзавестись NAS… ага…
                                                              • 0
                                                                Я так себе домой обещал ИБП купить лет 5… Вчера БП умер, после очередного отключения питания.
                                                              • +1
                                                                И у меня вопрос про два терабайта. Под классическими SAN имелись в виду те которые не поддерживают размещение одного луна сразу на нескольких массивах RAID? Я правильно понимаю что подобное утверждение не относится к, например, MSA2040, работающей в режиме виртуальных пулов?
                                                                • 0
                                                                  К сожалению, ничего не могу сказать про MSA — c HP СХД работал «мимо проходил».
                                                                • 0
                                                                  Потерянные данные на ВМ электронного документооборота ещё актуальны? Интересуюсь в плане целесообразности подключения к работе специалистов по восстановлению данных
                                                                  • 0
                                                                    Нет =) Истории уже несколько лет.
                                                                  • +1
                                                                    СХД была спроектирована некорректно. Один том на ~12 Тб не будет нормально работать ни на одной классической СХД. Всегда разбивайте общую ёмкость на тома порядка 1-2 Тб. Да, будет меньше полезной ёмкости, но зато будет гораздо меньше шансов открыть заявку «у нас всё тормозит».


                                                                    Заявление громкое, эмоциональное, но, к сожалению, не очень информативное.
                                                                    А можно обоснование посерьёзнее? С примерами, конкретикой и ссылками на вендорские документы типа Best Practice. Буду крайне признателен.

                                                                    • 0

                                                                      Не дождетесь :). Ибо вся суть в вашей первой фразе.

                                                                      • 0
                                                                        Согласен, погорячился с «ни один», но многие массивы из тех, с которыми сталкивался — «предпочитают» луны поменьше. Внесём изменение в стастью, чтобы выглфдело не так провокационно и категорично.
                                                                        К великому своему сожалению, ближайшие 2-3 дня не будет времени на подготовку такого основательного ответа. Но на скорую руку ниже примеры. Я рассматриваю случай когда много хостов работают с одним LUN.
                                                                        Один из примеров — массивы HDS midrange (до последнего поколения VSP G точно). У них есть ограничение очереди команд на LUN равное 32, соответственно, при 8 хостах работающих с одним луном очередь команд на лун у каждого хоста должна быть не больше 4, а это маловато, согласитесь.
                                                                        У EMC VNX с этим получше — queue depth per LUN = 224, но упереться в этот лимит некоторые администраторы тоже умудряются.
                                                                        У IBM Storwize я не смог найти в своё время значения этого параметра, но во избежание проблем — так же стараюсь делить данные.
                                                                        • 0

                                                                          Если вы значение queue depth per LUN = 224 для VNX взяли из этого документа (https://www.emc.com/collateral/hardware/technical-documentation/h8229-vnx-vmware-tb.pdf) стр. 39, то вы читали не очень внимательно. Там речь про лун расположенный на пуле из 20 дисков, а не про максимум для LUN на массиве VNX.

                                                                          • +1

                                                                            Ну и для справки из документации вендора.
                                                                            Расчет QD для Clariion CX4 и VNX1 с прошивкой v.31 идет по формуле QD=32+(14 умножить на количество дисков под данные)
                                                                            Для VNX1 и VNX2 c прошивками v.32 и v.33 соответственно QD=(14 умножить на количество дисков под данные).


                                                                            Отсюда для луна, расположенного на пуле из 20 дисков в Raid5 (4+1) (т.е. в пуле 4 приватные RG в указанной конфигурации) мы и получаем то самое значение 224=14 умножить на 16. Что как вы понимаете не является максимальным значением для LUN на массиве. Если возьмем пул из 60 дисков в той же конфигурации Raid5 (4+1), то соответственно получим QD для LUN=672.


                                                                            Еще для справки, максимальный QD для одного порта FC на VNX = 1600. Что реально является ограничением. Правда слабо верится что вы сможете его достигнуть, учитывая, что для подключения хостов обычно используется несколько портов на СХД одноверменно.

                                                                            • 0
                                                                              Да, именно оттуда.
                                                                              Без иронии, спасибо, что просветили. Слишком давно не общался с EMC, а этот документ быстро нагуглился.
                                                                      • 0

                                                                        Да не за что в общем то :). На многих хостах и HBA кстати QD ограничен 64-256 на том. Эти максимумы быстрее станут бутылочным горлышком, при наличии большом количестве VM, по сравнению с нормальной СХД.

                                                                        • 0
                                                                          Для всех «нормальная СХД» разная. Для кого-то midrange маловат, для кого-то сервак с 4 дисками, отдающий LUN по iSCSI избыточен. Видел многое.
                                                                        • 0
                                                                          «Зачем бэкап? У нас же NetAPP» :)

                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                          Самое читаемое