16 Replies Latest reply: Nov 21, 2013 11:24 PM by GERA.SUKHOV RSS

Проблемы с дедупликацией

GERA.SUKHOV
Currently Being Moderated

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

Итак, есть FAS2020 под DOT 7.3.7 P1, на которой в 3-х разных томах содержатся блочные ресурсы. И все, вроде, замечательно с дедупликацией, если бы иногда не вылазило аномально большое время процесса дедупликации.

Так, например, на томе vol_VI_Win среднее время дедупликации обычно в районе 30 минут (разброс от 14 минут до 40 минут). Но иногда, как вот например сегодня, время дедупликации составило свыше 6 часов! Вот ниже информация по двум томам за сегодня:

Path:                    /vol/vol_VI_Win

State:                   Enabled

Status:                  Idle

Progress:                Idle for 04:20:22

Type:                    Regular

Schedule:                sun-sat@1

Minimum Blocks Shared:   1

Blocks Skipped Sharing:  0

Last Operation Begin:    Thu Sep  5 01:00:00 MSK 2013

Last Operation End:      Thu Sep  5 07:16:18 MSK 2013

Last Operation Size:     39 GB

Last Operation Error:    -

Changelog Usage:         0%

Checkpoint Time:         No Checkpoint

Checkpoint Op Type:      -

Checkpoint stage:        -

Checkpoint Sub-stage:    -

Checkpoint Progress:     -


 

Path:                    /vol/vol_VI_Lin

State:                   Enabled

Status:                  Idle

Progress:                Idle for 11:25:44

Type:                    Regular

Schedule:                sun-sat@0

Minimum Blocks Shared:   1

Blocks Skipped Sharing:  0

Last Operation Begin:    Thu Sep  5 00:00:00 MSK 2013

Last Operation End:      Thu Sep  5 00:10:56 MSK 2013

Last Operation Size:     10 GB

Last Operation Error:    -

Changelog Usage:         0%

Checkpoint Time:         No Checkpoint

Checkpoint Op Type:      -

Checkpoint stage:        -

Checkpoint Sub-stage:    -

Checkpoint Progress:     -

К моему недоумению такое поведение наблюдается на разных томах, на разных объемах изменений, и в разное время. Уловить закономерности я пока не смог. А судя по этим данным 10GB дедуплицировалось 10 минут, а 39 GB - более 6 часов! Как так может быть?

  • Re: Проблемы с дедупликацией
    nicholas4704
    Currently Being Moderated

    Добрый

     

    Какого рода данные на томах, где дедупликация затягивается?

    Рекомендую собрать  perfstat во время затянувшейся дедупликации и послать в суппорт.

     

    Повышенное время дедупликации может быть связано с ограниченными ресурсами FAS2020, т.е. может что параллельно работало, может быть с кол-вом изменений во время дедупликации - например "свопится" вируальная машина.

    Perfstat должен помочь определить проблему.

     

    Nick

    • Re: Проблемы с дедупликацией
      GERA.SUKHOV
      Currently Being Moderated

      На всех томах - блочные ресурсы раздаваемые по FC и iSCSI. На блочных ресурсах размещены ВМ под разными гипервизорами (Xen и VMware). Дедупликация выполняется в ночное время, когда на этих ВМ никто не работает. Идет обычная фоновая активность на уровне нескольких процентов. Когда затянется очередной процесс дедупликации предугадать невозможно. Заметил я это совершенно случайно в первый раз 16.07.2013 и стал каждый день наблюдать. За это время я наблюдал 4 раза когда процесс дедупликации длился 3,5-4 часа, 1 раз - чуть более 5 часов и вот сегодня третий раз когда он длился более 6 часов. Все остальное время процесс завершается за 15-35 минут в зависимости от объема дневных изменений.

      На всех трех томах, на которых включена дедупликация, такие явления, аномально долгого выполнения дедупликации, случаются время от времени и не коррелирует с другими томами. По крайней мере я, на первый взгляд, не вижу никакой зависимости. Они случаются спорадически и даже в воскресенье может произойти (суббота и воскресенье - выходной).

      Я пробовал собирать почасовую статистику по записи на луны и опять-же, в некоторых случаях, как сегодня, нет такого объема изменений, чтобы они дедуплицировались более 6 часов.

      • Re: Проблемы с дедупликацией
        GERMAN.MARKOV
        Currently Being Moderated

        А что если попробовать сделать reallocation. А потом снова сделать замеры по дедупликации.

        • Re: Проблемы с дедупликацией
          GERA.SUKHOV
          Currently Being Moderated

          А каковы тут могут быть показания к reallocation? Том существует изначально. Диски в агрегат не добавлялись. Аномально большое время дедупликации наблюдается далеко не каждый день. Я вот файлик статистики приложил тут. Из него видно, что на томе vol_VI_Win за последнее время было 2 случая:

          1. 25.10.2013 - 9 часов 33 минуты
          2. 10.11.2013 - 9 часов 21 минута

          Что характерно, на другом томе vol_VI_Lin тоже наблюдается такой эффект. НО! В другие дни! Что наводит на мысль, что это системный дефект в процессе дедупликации. Ну или я совсем ничего в ней не понимаю... :-(

          • Re: Проблемы с дедупликацией
            GERMAN.MARKOV
            Currently Being Moderated

            я предположил, что вы либо добавляли диски, либо меняли vol size.

            • Re: Проблемы с дедупликацией
              GERA.SUKHOV
              Currently Being Moderated

              А при изменении размера тома вроде нет необходимости в reallocation... Том же в любом случае на всех дисках агрегата будет...

              • Re: Проблемы с дедупликацией
                GERMAN.MARKOV
                Currently Being Moderated

                но ведь вы могли давно добавить диски, а вольюмы только сечас ресайзить. и неравомерность заполнения дисков появится. я на своих системах делаю reallocation.  по диагностике есть идея - если есть возможность, то делайте снапшоты. как только обнаружится "аномалия" - сделайте vol clone. потом рестор на снапшот, и потом sis start. таким образом попробуем поймать проблему.

                • Re: Проблемы с дедупликацией
                  GERA.SUKHOV
                  Currently Being Moderated

                  Нет, диски не добавлялись.

                  Ну на продуктовом томе никто рестор не разрешит делать. :-) А вот на клоне сделанном со снапшота, который сделан до дедупликации - вполне возможно было-бы... Только снапшот влияет на дедупликацию... И не факт, что дедупликация на клоне сама не содержит проблем. В параллельной ветке обсуждали проблему дедупликации после удаления клона. У меня с этих томов никогда клонов не делалось...

                  Ну и потом... Допустим проблема повторится. Или не повторится. Что это нам даст в плане диагностики?

                  • Re: Проблемы с дедупликацией
                    GERMAN.MARKOV
                    Currently Being Moderated

                    а разве у вас нет снапшотов для виртуалок ?! в плане диагностики - если проблема повторилась - то допишем 1кб данных и запустим по новой. если не повторилась, то проблема в размещении блоков на аггрегате, и  лечим с помощью reallocation. :-)

                    • Re: Проблемы с дедупликацией
                      GERA.SUKHOV
                      Currently Being Moderated

                      Э-э-э... А можно поподробнее с выводами? Я что-то связи не уловил... Т.е. предположение, что все измененные/дописанные блоки за день, каким-то чудесным образом, в отдельные дни, собираются со всего тома на одном шпинделе? А в другие дни звезды светят по другому?

                      Бэкап виртуалок делается сторонним софтом без снапшотов СХД. Поэтому на томах снапшотов нет вообще. Да и, по большому счету, толку со снапшота в варианте использования блочного доступа для VI мало...

          • Re: Проблемы с дедупликацией
            mikhailf
            Currently Being Moderated

            Насколько я знаю дедуп периодически делает чистку базы отпечатков (stale fingerprint cleanup). Это происходит не каждый раз, а после определенного процента, не помню точно какого, но в районе 30-40% (можно видеть в поле stale fingerprints из вывода команды 'sis status -l'). Это операция съедает достаточно много ресурсов.

            Поэтому разное время не означает какого-либо дефекта...

            • Re: Проблемы с дедупликацией
              GERA.SUKHOV
              Currently Being Moderated

              Может и не означает. :-) А может...

              Вот, сегодня, как раз тот день, когда этот процесс идет чрезвычайно долго. Вот что выдала команда sis status -l (с priv diag)

               

              Path:                    /vol/vol_VI_Win

              State:                   Enabled

              Status:                  Active

              Progress:                65% Merged

              Type:                    Regular

              Schedule:                sun-sat@2

              Minimum Blocks Shared:   1

              Blocks Skipped Sharing:  0

              Last Operation Begin:    Wed Nov 20 21:00:00 MSK 2013

              Last Operation End:      Wed Nov 20 21:41:26 MSK 2013

              Last Operation Size:     19 GB

              Last Operation Error:    -

              Changelog Usage:         0%

              Checkpoint Time:         Fri Nov 22 09:32:38 MSK 2013

              Checkpoint Op Type:      Start

              Checkpoint stage:        Checking_pass2

              Checkpoint Sub-stage:    -

              Checkpoint Progress:     -

              Stage:                   Checking_P2

              Fingerprints Gathered:   0

              Gathering Begin:         -

              Fingerprints Sorted:     440330281

              Duplicate Blocks Found:  1528555

              Sorting Begin:           Fri Nov 22 02:00:01 MSK 2013

              Blocks De-duplicated:    431057

              De-duping Begin:         Fri Nov 22 02:11:57 MSK 2013

              Fingerprints Deleted:    75565650

              Checking Begin:          Fri Nov 22 02:36:57 MSK 2013

               

              Из вывода можно видеть, что вчера эта операция заняла 41 минуту и 26 секунд. Вчера вечером, по не связанным с постом соображениям, перенес время начала с 21 вечера на 2 ночи. И вот идет с 2 ночи и только завершилось (заняло 8 часов 51 минуту). Теперь вывод той-же команды:

              Path:                    /vol/vol_VI_Win

              State:                   Enabled

              Status:                  Idle

              Progress:                Idle for 00:20:28

              Type:                    Regular

              Schedule:                sun-sat@2

              Minimum Blocks Shared:   1

              Blocks Skipped Sharing:  0

              Last Operation Begin:    Fri Nov 22 02:00:00 MSK 2013

              Last Operation End:      Fri Nov 22 10:51:07 MSK 2013

              Last Operation Size:     27 GB

              Last Operation Error:    -

              Changelog Usage:         0%

              Checkpoint Time:         No Checkpoint

              Checkpoint Op Type:      -

              Checkpoint stage:        -

              Checkpoint Sub-stage:    -

              Checkpoint Progress:     -

              Stage:                   Done

              Fingerprints Gathered:   0

              Gathering Begin:         -

              Fingerprints Sorted:     440330281

              Duplicate Blocks Found:  1528555

              Sorting Begin:           Fri Nov 22 02:00:01 MSK 2013

              Blocks De-duplicated:    431057

              De-duping Begin:         Fri Nov 22 02:11:57 MSK 2013

              Fingerprints Deleted:    75565650

              Checking Begin:          Fri Nov 22 02:36:57 MSK 2013

               

              И вот что это такое? Дефект или закономерность?...

              Да, по поводу нагрузки СХД другими процессами... Не смотря на то, что СХД слабенькая, она отлично справляется с той нагрузкой, что требуется для работоспособности нашей виртуальной инфраструктуры. Ночью никто не работает. Только бэкап нескольких серверов делается. Но он отработал шустро.

              Утром, пока не завершился процесс дедупликации, профиль нагрузки выглядел как средняя загрузка CPU при равномерно небольшом чтении с периодически возникающей записью. Если кому интересно, то файлики прикладываю.

  • Re: Проблемы с дедупликацией
    GERA.SUKHOV
    Currently Being Moderated

    Я консолидирую ответ. :-)

    GERMAN.MARKOV

    т.е. вы считаете что на LUN-ах снапшоты ненужны?

    У меня мнение такое, что если на лунах лежат VM, вместо полноценного бэкапа которых достаточно crash консистентного снапшота, то можно и СХД склонить к этому. :-) Однако в большинстве случаев для виртуальных серверов нужен полноценный бэкап. И в этом случае снапшоты лунов как-бы бесполезны...

    GERMAN.MARKOV

    предположение в том, что в отдельные дни, расположение блоков wafl, затрудняет работу алгоритма дедупликации.

    У меня тоже было такое предположение. Сразу после того, как я снял подозрение в том, что слишком много блоков перезаписывается. :-) Но я не нашел ни одной теоретической причины, почему это может возникать раз в 5-15 дней... Да и вообще, просто возникать исходя из принципов записи в WAFL, учитывая, что том был создан на чистом агрегате и дисков не добавлялось.

     

    nicholas4704

    Соберите перфстат 5 итераций по 5 мин  ... и пошлите в суппорт.

    Может быть в это время массив занят чем-то еще...

    Послал-бы, коли бы купили поддержку, которая закончилась в начале этого года. :-(

    Тоже было такое предположение (на счет занятости контроллера). Я даже собирал статистику по загрузке операциями в разрезе LUN-ов. Которая, кстати, позволила снять предположение об большом количестве перезаписанных блоков... Так что если говорить об внешней загрузке, то нет, не занята. А что она делает внутри в это время - не мониторил. Пока не представляю как получить картинку (что и чем мониторить) которая мне что-нибудь бы сказала отличное от того, что я уже видел... Есть идеи?

More Like This

  • Retrieving data ...