Несчастливое число SVC/V7000 – 208

Главная Форумы Storage SAN, Disk & Tape Несчастливое число SVC/V7000 – 208

Просмотр 17 веток ответов
  • Автор
    Сообщения
    • #15196
      uxTuaHgp
      Участник
    • #15197
      andrewk
      Участник

      это хороший баг – чтобы админы не забывали о существовании железок в своем хозяйстве 😉

    • #15220
      byldozer
      Участник

      Это фишка 🙂

    • #15223
      Sever
      Участник

      семейство систем с «интегрированной экспертизой»

    • #15442
      uxTuaHgp
      Участник

      Выпущен код 6.3.0.2, исправляющий эту ошибку.

    • #15455
      Oldnick
      Участник

      Выпущен код 6.3.0.2, исправляющий эту ошибку.

      исправляет также код 6.2.0.5

      вообще говоря можно перегружать систему раз в 200 дней, и проблемы не будет. 🙂

    • #15460
      uxTuaHgp
      Участник

      Про 6.2.0.5 в курсе, но мы уже на 6.3.0.1

      Перегружать СХД, на которой крутится куча систем, хоть и без даунтайма – развлечение спорное.
      На время пока узел перегружается все тома будут работать в Write-through режиме, то есть производительность записи упадет на порядок.

    • #15461
      Сергей
      Участник

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

    • #15601
      Oleg
      Участник

      кто-то уже обновлялся до 6.3.0.2?
      я обновил до 6.3.0.2, для начала, две своих V7K – проблем не было

    • #15604
      uxTuaHgp
      Участник

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

    • #15606
      Pavel Alexei
      Участник

      на developerworks пару человек жаловались что при переходе с 6.2.x на 6.3.0.1 были downtime и тома отвалились.

    • #15607
      uxTuaHgp
      Участник

      Ячестно признаюсь, что пока шился с даунтаймом запланированным.

    • #15609
      Stanley
      Участник

      Ячестно признаюсь, что пока шился с даунтаймом запланированным.

      и это хорошо 🙂

    • #15610
      Oldnick
      Участник

      я шил около десятка раз. никогда ничего не отваливалось. полное время прошивки обеих нод – около 1 часа. перед выключением каждой ноды очень долго в автоматическом режиме проверятся работоспособность оставшейся ноды… только после этого первая переходит в офлайн. и далее наоборот.

    • #15612
      Pavel Alexei
      Участник

      тоже шил, хоть и немного.
      По чем купил..
      https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14792512

    • #15616
      Oleg
      Участник

      на developerworks пару человек жаловались что при переходе с 6.2.x на 6.3.0.1 были downtime и тома отвалились.

      ага,
      именно в 6.3.0.2 заявлен фикс и данной проблемы

    • #15639
      uxTuaHgp
      Участник

      6.3.0.2 сразу с первых секунд процесса обновления кидает обновляемый узел в Offline и соответственно рвет половину путей на всех подключенных хостах.
      5.1 шилась так же?

    • #15914
      Artem Smirnov
      Участник

      Да, 5.1 и даже 4.3 прошивались абсолютно также.

Просмотр 17 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.