Storwize 7000


Главная Форумы Storage SAN, Disk & Tape Storwize 7000

В этой теме 96 ответов, 16 участников, последнее обновление  uxTuaHgp 3 года/лет, 11 мес. назад.

Aliexpress INT
  • Автор
    Сообщения
  • #13741

    Sever
    Участник
    Aliexpress INT

    Сейлов со сторвайзами от IBM гоните в шею.
    Это говно!
    Саппорт этих железок IBMом не оказывается.

  • #13742

    roman
    Участник

    а можно поподробнее?

  • #13743

    Sever
    Участник

    Хранилище самопроизвольно ушло в даун без какой либо диагности. Сервису потребовалось две недели для определения причины – сбойная батарея. Прислали батарею и сервис уперся рогом, что мы сами должны её менять. Утверждает, что все сервисные действия по этому железу – это обязанность клиента. За все время с возникновения проблемы ни один инженер IBM даже не появился на прощадке.
    Говносервис по говножелезу.
    IBMовский сервис это @#$$%%&^%$ @#$%%^^^&&^

  • #13744

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

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

  • #13745

    Sever
    Участник

    Сервис по этому железу не оказан и на рубль.
    Приложим все силы, чтоб вправить мозги вашим менеджерам.

  • #13748

    yota
    Участник

    А ну нас работает сторвайз этот, нормальная вроде железка. Не понимаю истерики по сервису, нам вот нахер не нужен инженер на площадке, мы сами все меняем.

  • #13751

    Oldnick
    Участник

    V7000 приравнивается к писюку. то есть, сам собирай, сам разбирай, сам ремонтируй и т.д. А если сломаешь? кто в таком случае крайний, IBM ?

  • #13754

    Alexander Teterkin
    Участник

    Хм… А у меня только положительные отзывы. И железка супер и сервис… БД стала в 4 раза на ней быстрее работать. Там правда SSD диски.

  • #13755

    Victor Sedyakin
    Участник

    Если объективно, то в списке Customer Replaceable Unit (CRU) для V7000 находятся:
    • Блоки питания и охлаждения
    • Диски
    • Контроллеры
    • I/O модули
    • Полки (включая midplane)
    • Батареи
    Эти компоненты заменяются пользователем. IBM тоже может, но за деньги.

  • #13756

    yota
    Участник

    Хм… А у меня только положительные отзывы. И железка супер и сервис… БД стала в 4 раза на ней быстрее работать. Там правда SSD диски.

    А можно вопросы позадавать? 🙂 Сколько, к примеру, вы iops с SSD получили?

  • #13757

    Alexander Teterkin
    Участник

    [quote quote="MrLis" post=13034]Хм… А у меня только положительные отзывы. И железка супер и сервис… БД стала в 4 раза на ней быстрее работать. Там правда SSD диски.

    А можно вопросы позадавать? 🙂 Сколько, к примеру, вы iops с SSD получили?[/quote]
    Честно говоря мне до конца разогнать ее не получилось, времени было в обрез, заказчики на другом проекте уже ждали.
    Oracle ORION смог только 15 kIOPS дать, живая база давала до 30 kIOPS (хотя может это и кэш, т.к. были проблески, а не постоянно), а какой у нее верхний предел не удалось установить (хотел iometer натравить, но не успел). У базы постоянная нагрузка 7-10 kIOPS, так что, думаю на 3-5 лет им за глаза хватит. Самый прикол был что мы в пропускную способность текущей конфигурации оптики у них уперлись – 800 MBs. До этого я таких цифр в AIX не видел.

  • #13758

    Alexander Teterkin
    Участник

    Еще плюс в Storvize это то, что она по сути – SVC, т.е. к ней можно старые СХД цеплять и тогда она становится быстрым промежуточным кэшем на SSD для серверов, а данные остаются на старых полках.
    Плюс интерфейс для домохозяек понравился, а-ля iPhone (на самом деле а-ля IBM XIV).
    Правда с интерфейсом на испытаниях косяк получился: выдергивали оптику на лету и смотрели статус в графическом интерфейсе, когда воткнули обратно – тишина, показывает offline. Пошли в командную строчку и увидели что все нормально, online. Как раз тогда окрытли заявку и нам IBM быстренько рассказал, как перезапустить web server на Storwize и все графический интерфейс починился, а потом вышел патч и проблемы больше не стало.
    А еще, не знаю, минус не минус, чтобы по ssh подцепиться надо сертификат получать на свой login, а при входе употреблять admin (точно не помню, летом было, ну короче стандартный логин).

  • #13759

    yota
    Участник

    [quote quote="yota" post=13036][quote quote="MrLis" post=13034]Хм… А у меня только положительные отзывы. И железка супер и сервис… БД стала в 4 раза на ней быстрее работать. Там правда SSD диски.

    А можно вопросы позадавать? 🙂 Сколько, к примеру, вы iops с SSD получили?[/quote]
    Честно говоря мне до конца разогнать ее не получилось, времени было в обрез, заказчики на другом проекте уже ждали.
    Oracle ORION смог только 15 kIOPS дать, живая база давала до 30 kIOPS (хотя может это и кэш, т.к. были проблески, а не постоянно), а какой у нее верхний предел не удалось установить (хотел iometer натравить, но не успел). У базы постоянная нагрузка 7-10 kIOPS, так что, думаю на 3-5 лет им за глаза хватит. Самый прикол был что мы в пропускную способность текущей конфигурации оптики у них уперлись – 800 MBs. До этого я таких цифр в AIX не видел.[/quote]
    ORION может нагрузку не хуже иометра генерить. Ну у меня 50к выжалось с двух SSD в зеркале. Линейку больше 870 МBps не дала (мож дисков мало было).

  • #13760

    yota
    Участник

    Еще плюс в Storvize это то, что она по сути – SVC, т.е. к ней можно старые СХД цеплять и тогда она становится быстрым промежуточным кэшем на SSD для серверов, а данные остаются на старых полках.

    Там tier’инг, это как бы ниразу не кеш.

    Правда с интерфейсом на испытаниях косяк получился: выдергивали оптику на лету и смотрели статус в графическом интерфейсе, когда воткнули обратно – тишина, показывает offline. Пошли в командную строчку и увидели что все нормально, online. Как раз тогда окрытли заявку и нам IBM быстренько рассказал, как перезапустить web server на Storwize и все графический интерфейс починился, а потом вышел патч и проблемы больше не стало.

    А что за патч, стоит вроде последняя прошивка, а баг этот присутствует 🙁

  • #13761

    Alexander Teterkin
    Участник

    ORION может нагрузку не хуже иометра генерить. Ну у меня 50к выжалось с двух SSD в зеркале.

    Да, я просто ORION первый раз использовал. Видимо, не успел во всех ключиках разобраться. Кстати, если сохранилось, пришлите параметры вызова для ORION.

    Линейку больше 870 МBps не дала (мож дисков мало было).

    Скорее всего в оптику уперлись, а не в количество дисков. Сейчас уже не вспомню, где то читал, что на 2-х кабелях A/A на 4Gbps теоретическая скорость 1024MB/c, но реально должно быть около 800MB/c. У вас даже больше получилось.

  • #13762

    Alexander Teterkin
    Участник

    Там tier’инг, это как бы ниразу не кеш.

    Ну, кеш “в ковычках”.

    А что за патч, стоит вроде последняя прошивка, а баг этот присутствует 🙁

    Хм… спутал. Точно патча не было. Было только обещание от техподдержки, что проблема исправится в следующей прошивке. Ну проблема не критичная, если сумел один раз по ssh зайти. 😉

  • #13763

    yota
    Участник

    Скорее всего в оптику уперлись, а не в количество дисков. Сейчас уже не вспомню, где то читал, что на 2-х кабелях A/A на 4Gbps теоретическая скорость 1024MB/c, но реально должно быть около 800MB/c. У вас даже больше получилось.

    На двух 8Gbps линках? Очень сомневаюсь 😉

  • #13764

    Alexander Teterkin
    Участник

    [quote quote="MrLis" post=13041]
    Скорее всего в оптику уперлись, а не в количество дисков. Сейчас уже не вспомню, где то читал, что на 2-х кабелях A/A на 4Gbps теоретическая скорость 1024MB/c, но реально должно быть около 800MB/c. У вас даже больше получилось.

    На двух 8Gbps линках? Очень сомневаюсь ;)[/quote]
    Да, если 8Gbps, то нет. Но и диски SSD должны больше давать. Может размер IO был маленький?

  • #13765

    yota
    Участник

    Да, если 8Gbps, то нет. Но и диски SSD должны больше давать. Может размер IO был маленький?

    Блок IO был 1МБ, но это не самое интересное. Эта цифра была получена на обычных дисках, с SSD линейка была не больше 420МБ при любых паттернах доступа.

  • #13772

    azar_mike
    Участник

    Сколько примерно стоит Storwize с 24 SSD дисками?

  • #13775

    Pavel Alexei
    Участник

    Еще более интересный вопрос: как расшарить пару SSD (raid1) между несколькоми storage pool. Получается что “внутренние” никак 🙁

  • #13842

    Хранилище самопроизвольно ушло в даун без какой либо диагности. Сервису потребовалось две недели для определения причины – сбойная батарея. Прислали батарею и сервис уперся рогом, что мы сами должны её менять. Утверждает, что все сервисные действия по этому железу – это обязанность клиента. За все время с возникновения проблемы ни один инженер IBM даже не появился на прощадке.
    Говносервис по говножелезу.
    IBMовский сервис это @#$$%%&^%$ @#$%%^^^&&^

    Хм. А батарейка одна что-ли была? Там же вроде по батарейке на управляющую канистру или нет?

  • #13843

    Sever
    Участник

    Их там три штуки.

  • #13844

    Alexander Teterkin
    Участник

    Их там три штуки.

    Each IBM Storwize V7000 system has one control enclosure that contains two node
    canisters, disk drives, and two power supplies. There are two models of the control enclosure
    with one model providing 12 3.5-inch disk slots and the other providing 24 2.5-inch disk slots.
    Within a control enclosure, each power supply unit (PSU) contains a battery. The battery is
    designed to enable the IBM Storwize V7000 system to perform a dump of the cache to
    internal disks in the event of both power inputs failing.

    Хм… а где третья?

  • #13845

    Их там три штуки.

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

  • #13846

    Oldnick
    Участник

    там две батареи в основном ящике. по одной на каждый блок питания.
    каждая батарея представляет собой три последовательных “пальчиковых” элемента. как раз один из трех элементов сдох. при этом понять это можно только если проанализировать полный дамп системы (snap). В данном случае система повела себя не адекватно как раз из-за того что обнаружила сбойный элемент в цепи батареи…. просто ушла в даун…
    по крайней мере так объяснил ситуацию суппорт нижнего уровня. надеюсь этот баг будет ипсправлен в новой версии прошивки…

  • #13848

    А какая у вас версия прошивки?

  • #13849

    Oldnick
    Участник

    6.2.0.3 (build 36.5.1109020000)

    Battery 1 is failed and will need to be replaced:

    Display voltages for each battery
    Battery index : 1
    Cell 1 Voltage : 3369 mV (balance FET: off)
    Cell 2 Voltage : 3346 mV (balance FET: off)
    Cell 3 Voltage : 0 mV (balance FET: off) <<<>>>>

    Battery index : 2
    Cell 1 Voltage : 3452 mV (balance FET: off)
    Cell 2 Voltage : 3443 mV (balance FET: off)
    Cell 3 Voltage : 3448 mV (balance FET: off)

  • #13935

    Oldnick
    Участник

    на днях вышла новая прошивка 6.2.0.4 для V7000, также вышли новые прошивки для 10K SAS-дисков 300/450/600GB/2TB, которые настоятельно рекомендуют обновить….в частности для ST9450404SS SAS 450GB 15K…
    по крайней мере так говорит тул Software Upgrade Test Utility 6.15

  • #13936

    А вашу проблему это исправляет?

  • #13937

    Sever
    Участник

    Наша проблема не в прошивках и не в том, что 7000 упала.
    Проблема в неадекватном поведении локального сервиса IBM.

  • #13938

    Oldnick
    Участник

    А вашу проблему это исправляет?

    пока точно не известно. ждем подтверждения.
    ну а в нотах упоминается что-то близкое к power down…

    IC78842 Node canisters unable to complete power-on process following abrupt
    power-down event

  • #15044

    Господа, кто-нибудь понимает что означает SWMA саппорт для этой железки?

  • #15048

    Andriy
    Участник

    Господа, кто-нибудь понимает что означает SWMA саппорт для этой железки?

    software maintenance. насколько мне известно, туда входит поддержка всяческих фич типа External Virtualization, всяческих миррорингов и т. п.

  • #15049

    Вот как-то непонятно. Поговорили с 5-6 людьми в IBM никто толком сказать ничего не может, а стоит это дело не мало. При это спрашивали: “Наши запросы будут обрабатываться? Будут. К патчам будет доступ? Будет. А чтож блин за опция такая? Ну, понимаете…” Нет не понимаем 🙂

  • #15052

    Alexander Teterkin
    Участник

    SWMA, в общем смылсе, это Software Maintenance Agreement, контракт на поддержку софта.
    Если вы его не купите, то вам будет оказываться поддержка только на проблему с железом, а если будет глюк с софтверной частью (кластер, веб-интерфейс и т.д.), то…

    Действительно информации про это мало даже на Offering Information применительно к V7000.

    Но если взять AIX для примера, то там много чего есть про SWMA:
    Software Maintenance (SWMA) provides end customers with two
    important “entitlements”.
    – The right to receive new major and minor revisions to the
    AIX software products (Upgrades) (5799-SBS)
    – The right to contact the IBM support organization for questions
    about software operation and the investigation of software defects
    (Remote Support) (5799-SPT)
    http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_rp/3/ENUSP91213/index.html&lang=en&request_locale=en

  • #15055

    Да про AIX то все понятно, а вот случай со сторвайзом не ясен.

  • #15056

    Alexander Teterkin
    Участник

    Действительно странная история. Обычно на IBM Offering Information все есть, а тут – ничего. Я по всем парт номерам поискал.

  • #15058

    Alexander Teterkin
    Участник

    Пока вот такой ответ получил из Техлайна:

    It might vary between products what exactly SWMA will give you but in general the below is what you can expect:

    •Access to IBM’s WW support infrastructure and pool of technical support specialists.
    •Enhanced software availability by delivering timely problem resolution.
    •An ability to upgrade to the latest OS.
    •Remote technical support, when needed.
    •Access to software updates, new versions and releases, as they become available

    Запросил уточнений и официального ответа.

  • #15060

    Вот насколько нам объяснили

    •An ability to upgrade to the latest OS.
    •Remote technical support, when needed.
    •Access to software updates, new versions and releases, as they become available

    будет доступен и без SWMA, а с двумя первыми пунктами как-то мутно.

  • #15061

    Oldnick
    Участник

    на сколько я понимаю, SWMA – это фактически анализ проблем выпуск фиксов по проблемам с софтом внутри V7000, если такие возникают. Ну а фиксы представляют собой просто очередную прошивку Firmware для V7000 🙂 которая доступна всем.

  • #15063

    Я тоже склоняюсь к этому выводу. Получается если сломается и проблема в прошивке – никто срочный фикс выпускать не будет.

  • #15064

    Oldnick
    Участник

    по-моему никаких срочных фиксов и нету. все фиксы потом включают в очередную прошивку.

  • #15074

    Alexander Teterkin
    Участник

    Еще пришлел ответ от Техлайн.
    Он взят отсюда: http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=gpateam&supplier=877&letternum=ENUSZP10-0455

    Это типа вопрос:
    Software Subscription and Support (Software Maintenance) applies

    Это ответ:
    Yes. All distributed software licenses include Software Subscription and Support (also referred to as Software Maintenance) for a period of 12 months from the date of acquisition, providing a streamlined way to acquire IBM software and assure technical support coverage for all licenses.
    Extending coverage for a total of five years from date of acquisition may be elected.
    While your Software Subscription and Support (Software Maintenance) is in effect, IBM provides you assistance for your routine, short duration installation and usage (how-to) questions, and
    code-related questions. IBM provides assistance via telephone and, if available, electronic
    access, only to your information systems (IS) technical support personnel during the normal
    business hours (published prime shift hours) of your IBM support center. (This assistance is
    not available to your end users.) IBM provides Severity 1 assistance 24 hours a day, every day
    of the year. For additional details, consult your IBM Software Support Handbook at
    http://www.ibm.com/support/handbook
    Software Subscription and Support (Software Maintenance) does not include assistance for the
    design and development of applications, your use of programs in other than their specified
    operating environment, or failures caused by products for which IBM is not responsible under
    this agreement.

  • #15085

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

    А если по русски, то без софт-поддержки будет осуществляться только ремонт “по лампочкам”. Горит авария на диске – меняем диск.
    Никакого анализа неисправностей производится не будет, замена node canister — тоже едва ли, т.к. для этого надо почитать лог, а это делает software support.
    вот такая вот загогулина. 🙁

  • #16111

    Roman
    Участник

    Хранилище самопроизвольно ушло в даун без какой либо диагности. Сервису потребовалось две недели для определения причины

    Вам повезло – у вас причину нашли. У нас пол-массива в даун ушло и в результате трехнедельного расследования мы получили ответ вида “а хрен его знает почему оно легло, но на всякий пожарный, обновите FW массива”.

    А после обновления (4-е массива) один просто упал, а когда очнулся, то выдал сообщение – программная ошибка. Версия FW – 6.4.0.1.

  • #16112

    Oldnick
    Участник

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

  • #16114

    Roman
    Участник

    Перед началом расследования, к нам приезжал инженер для сбора информации. Так вот инженер проговорился, что сторвайзы очень не любят подключения (LAN) к оборудованию cisco. И в СПб много клиентов, у которых после обновления FW начинаются проблемы с сетевыми подключениями. Московские представители IBM были очень раздражены, когда я начал задавать вопросы на эти темы, ссылаясь на инженера. :dry:

    С другой стороны, железка как таковая – достаточно интересная и шустрая.

  • #16122

    Oldnick
    Участник

    сетевые подключения в данном случае интересуют меньше всего. проблема в том, что Сервис никогда не рапортует клиенту о том в чем была проблема и что они сделали чтобы эта проблема не повторилась. Сервис построен так. Любая проблема решается рестартом ноды. Если проблема ушла после этого, тогда Сервис теряет вообще всякий интерес к расследованию.

  • #16123

    Roman
    Участник

    Любая проблема решается рестартом ноды. Если проблема ушла после этого, тогда Сервис теряет вообще всякий интерес к расследованию.

    А, пардон, за что берутся приличные деньги по поддержке? Приятно поговорить в стиле “протрите фары, попинайте колеса”? Рестартануть ноду можно и без обращения в саппорт.

    проблема в том, что Сервис никогда не рапортует клиенту о том в чем была проблема и что они сделали чтобы эта проблема не повторилась.

    Ну да, хорошая позиция – за деньги клиентов тестировать свои поделки, проданные этим же клиентам 🙂

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

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

    Как-то так…

  • #16124

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

    Вопрос о том, почему при пропадании сети, кластер развалился, хотя должен был сохраниться (FC подключения нод никто не отменял) так и остался открытым.

    Как-то так…

    может быть, Вы что-то неправильно поняли?
    Кластер вообще не использует езернет для общения между нодами.
    Используется pci interconnect в качестве основного средства, внешняя связь через SAN в качестве запасного.
    Про проблемы сторвайза с кискосвичами тоже слышу первый раз.
    Нет, они были, но у svc, и в коде 4.хх. Тоесть давно..

    А что вы собственно хотите услышать от сервиса в качестве причины аварии?
    Номер баги? Или обещание что “такая фигня больше не повторицца”?
    Просто описание того что же собственно произошло обычно видно из ивент лога, описание всех ивентов доступно в инфоцентре…

  • #16125

    Oldnick
    Участник

    А что вы собственно хотите услышать от сервиса в качестве причины аварии?
    Номер баги? Или обещание что “такая фигня больше не повторицца”?
    Просто описание того что же собственно произошло обычно видно из ивент лога, описание всех ивентов доступно в инфоцентре…

    вы озвучили позицию Сервиса. Примерно так он и ведет себе с клиентами, которые ему платят за это деньги. Более того, чаще всего вообще никак не ведет себя…

  • #16126

    Roman
    Участник

    может быть, Вы что-то неправильно поняли?
    Кластер вообще не использует езернет для общения между нодами.
    Используется pci interconnect в качестве основного средства, внешняя связь через SAN в качестве запасного.
    Про проблемы сторвайза с кискосвичами тоже слышу первый раз.
    Нет, они были, но у svc, и в коде 4.хх. Тоесть давно..

    А что вы собственно хотите услышать от сервиса в качестве причины аварии?
    Номер баги? Или обещание что “такая фигня больше не повторицца”?
    Просто описание того что же собственно произошло обычно видно из ивент лога, описание всех ивентов доступно в инфоцентре…

    Я то как раз правильно понял.
    Ибо как есть привычка записывать (тезисно) то, что мне говорят инженеры.

    Что я хотел услышать? Самое элементарное – объяснение причин произошедшего.
    Другое дело, что представители IBM не дураки и понимают, что одно неверное слово, и их натянут так, что мало не покажется, ибо как простой бизнеса в течение 60 минут и потери, пусть 1-2 млн вечно зеленых, могут простить, но больше заказов на новое оборудование не видать как своих ушей.. А еще есть антиреклама. И уверяю Вас, хоть мы и небольшая компания, но владельцы имеют достаточный вес, что бы испортить настроение многим. И отмазки вида “а хрен его знает” могут стоить очень дорого.
    Поэтому и начинаются “заходы” со стороны IBM – “мы вам скажем, только вы никому!” (С) менеджеры ИБМ.

    Мне, как эксплуатирующему это “инновационное” оборудование, важно понимать, что и по какой причине с ним происходит. В противном случае, я оказываюсь в ситуации, когда оборудование одного из крупнейших и ведущих поставщиков HW ведет себе просто не предсказуемо и необъяснимо самим разработчиком. О каком бизнес-критикал применении может идти речь?

  • #16127

    Roman
    Участник

    может быть, Вы что-то неправильно поняли?
    Кластер вообще не использует езернет для общения между нодами.
    Используется pci interconnect в качестве основного средства, внешняя связь через SAN в качестве запасного.

    Если не затруднит, киньте ссылку на документ, где упоминается pci-interconnect в 4-х и 8-и нодовой конфигурации кластера V7000.

  • #16129

    uxTuaHgp
    Участник

    Storwize может и через PCI интерконнект… неужели правда?
    Если исходить из тесного родства SVC и 7000, то как-то сомнительно.

  • #16130

    uxTuaHgp
    Участник

    Тоже, кстати, случилась беда с SVC – узел потерял связь с UPS.
    Поменяли кабель сериальный – все прошло.
    Кто бы мог подумать!

  • #16133

    Тут по-моему, два человека о разном говорят. Канистры в управляющей ноде соеденены через внутреннюю шину (наверное pci), а с другими V7000 он соединяется по FC.

  • #16173

    Sever
    Участник

    Из недр переписки саппорта…

    On 9.4.2012 at around 8:22 node1 (78G0042s1) was missing from the
    cluster.After reseating of this node the problem was solved.
    Trace file for this node is emptry for this time frame.
    .
    Only error that I found is written SEL log

    .
    3 | 04/09/2012 | 04:21:23 | OS Stop/Shutdown #0x46 | Run-time
    critical stop | Asserted
    4 | 04/09/2012 | 04:21:23 | Critical Interrupt #0x32 | State Asserted
    5 | Pre-Init |0000000031| System ACPI Power State #0x20 | S0/G0:
    working | Asserted
    6 | Pre-Init |0000000031| Unknown #0x31 |
    7 | Pre-Init |0000000032| Platform Alert #0x1b | State Asserted
    8 | Pre-Init |0000000032| Reset #0x1f | State Asserted
    9 | Pre-Init |0000000032| FRU State #0x24 | Activation in Progress
    | Asserted
    a | 04/09/2012 | 12:05:34 | System ACPI Power State #0x20 | S0/G0:
    working | Asserted
    .
    On Wiki sead that this is karnel panic isssue with the OS on box.
    .

    Продукт УГ, саппорт занимается гаданием на кофейной гуще и контекстным поиском по линуксовым wiki…

  • #16175

    uxTuaHgp
    Участник

    Ну в общем да.
    Диагностики подробной как у взрослых машин нет как у 7000, так и у SVC.
    В нашем сбое было три варианта решения:
    замена кабеля
    замена UPS
    замена материнской платы.

    Поддержка собиралась решать проблему итерационно при том что у нас тома были в write-through…

  • #16178

    Andriy
    Участник

    Продукт УГ, саппорт занимается гаданием на кофейной гуще и контекстным поиском по линуксовым wiki…

    ну почему сразу линуксовым. может у них свой, внутренний 🙂

  • #16392

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

    Я то как раз правильно понял.
    Ибо как есть привычка записывать (тезисно) то, что мне говорят инженеры.

    Что я хотел услышать? Самое элементарное – объяснение причин произошедшего.

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

    поэтому и ответы иногда от инженеров приходят весьма странные, часто на основе FUD’а. Потому как клиент просит причину, а ему, саппорту, и самому никто не говорит.

    Если не затруднит, киньте ссылку на документ, где упоминается pci-interconnect в 4-х и 8-и нодовой конфигурации кластера V7000

    если не затруднит, киньте ссылку на документ, где упоминается что v7000 сейчас поддерживает 8-way 🙂
    По-моему, 4-way только-только начал поддерживаться без RPQ. Я не слышал чтобы в России были такие инсталляции.
    ну и про кластер я говорил подразумевая кластер между двумя нодами одной controller enclosure. между двумя энкложами уже не кластер, а аналог iogroup на свц.

    Продукт УГ, саппорт занимается гаданием на кофейной гуще и контекстным поиском по линуксовым wiki…

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

  • #16409

    Roman
    Участник

    [quote quote="Solinger2" post=15386]
    Если не затруднит, киньте ссылку на документ, где упоминается pci-interconnect в 4-х и 8-и нодовой конфигурации кластера V7000

    если не затруднит, киньте ссылку на документ, где упоминается что v7000 сейчас поддерживает 8-way 🙂
    По-моему, 4-way только-только начал поддерживаться без RPQ. Я не слышал чтобы в России были такие инсталляции.
    ну и про кластер я говорил подразумевая кластер между двумя нодами одной controller enclosure. между двумя энкложами уже не кластер, а аналог iogroup на свц.
    [/quote]

    Так, для прояснения смысла терминов: что понимается под “4-way” и “8-way”?

    Я написал про ноды, они же канистры – по две штуки в каждом controller enclosure.

    Где написано про 8-и нодовую конфигурацию?

    На сайте, в разделе спецификаций (тут) указано, что максимальное число дисков на одну управляющую полку (т.е. две ноды) – 240, а общее число дисков – 960. Ответ, про 4-е контроллерные полки (8 нод), думаю, очевиден.
    Ну и на очередном семинаре, представитель IBM в захлеб рассказывал о новых фичах – удвоение числа нод (с 4 до 8), а так же появление функционала компрессии и безостановочной смены io-групп для тома…

  • #17145

    Remus
    Участник

    Доброе время суток!
    Может кто-нибудь подскажет про кластер из 2-х Storwize V7000.
    Имеется 2 I/O-группы, в каждой группе 2 ноды. Создан mirror volume на 2-х пулах(1-й пул из io_grp0, 2-й пул из io_grp1).
    В свойствах voluma такие параметры:
    Caching I/O Group: io_grp1
    Accessible I/O Groups: io_grp0, io_grp1
    Preferred Node: node3
    Если выключить Enclosure_2 c io_grp1, то volume переходит в состояние offline.
    Почему volume не доступен с Enclosure_1 c io_grp0?

  • #17150

    Roman
    Участник

    Нормальное поведение этого т.н. кластера.
    Кластерная система позволяет потерять до двух нод (в 4-х нодовой конфигурации), но “вертикально”: по одной из разных enclosure.
    При “горизонтальной” потере: в пределах одного enclosure, происходит потеря половина массива.

  • #17151

    Oldnick
    Участник

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

  • #17152

    Andriy
    Участник

    горизонтальная потеря – это потеря целой управляющей полки, обеих ее нод.

  • #17154

    Roman
    Участник

    Кластер состоит из минимум двух частей. В каждой части есть управляющие полки.
    В каждой управляющей полке – два контроллера (ноды). Итого, имеем 4-е ноды. Общение между контроллерами обеспечивается через оптику ( должны быть созданы зоны в фабриках, объединяющие только FC порты нод). Полки расширения подключаются к контроллерной полке, поэтому выключение контроллерной полки (две ноды – горизонтальная потеря (с) саппорт IBM) приведет к потере части массива. Если выключаются по одной ноде в каждой контроллерной полке (вертикальная потеря (с) саппорт IBM), то работа массива возможна.

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

    ЗЫ. извините за сумбурность 🙂

  • #17155

    Remus
    Участник

    Если у тома две копии и каждая копия расположена на разных контроллерных полках (enclosure), то при потере целой контроллерной полки, почему том переходит в offline? другая же контроллерная полка рабочая, пул, который содержит копию, рабочий.

  • #17156

    Victor Sedyakin
    Участник

    Для начала, если массив на гарантии, откройте кейс в IBM.
    Это не нормальное поведение кластера, т.к. при отказе одной IO-группы, вторая должна предоставлять доступ к secondary pool и volume должен быть доступен хостам на чтение-запись. Изменения впоследствии автоматически синхронизируются при подъеме отказавшей IO-группы. Переход тома в offline при отвале одной IO-группы скорее всего вызван недоступностью кворумных дисков, если они все находились на отказавшей IO-группе – проверьте конфигурацию quorum disk.
    См. http://pic.dhe.ibm.com/infocenter/storwize/ic/index.jsp?topic=%2Fcom.ibm.storwize.v7000.doc%2Fsvc_vdiskmirroring_3r7ceb.html и http://pic.dhe.ibm.com/infocenter/storwize/ic/index.jsp?topic=%2Fcom.ibm.storwize.v7000.doc%2Fsvc_scsiquorumdiskovr_1bchni.html

  • #17157

    Roman
    Участник

    К вопросу о выключении одной управляющей полки:
    “In systems with exactly two control enclosures, an uncontrolled shutdown of a control enclosure might lead to the entire system becoming unavailable because two node canisters become inaccessible simultaneously. It is therefore vital that node canisters are shut down in a controlled way when maintenance is required.” (взято из последней ссылки предыдущего поста).

  • #17160

    Remus
    Участник

    Есть два кворумных диска в 1-й IO-группе и один диск во 2-й IO-группе. При выключении обоих нод 2-й IO-группы, то один кворумн диск доступен из первой IO-группы. Или этих кворумных дисков не достаточно?

  • #17166

    Victor Sedyakin
    Участник

    А какие-то Event ID (error/warning) при этом генерируются?

  • #17182

    azar_mike
    Участник

    Было при тестировании падение всего кластера SVC,
    оказалось, что все кворумные дикски были на одной IBM DS из четырех.
    Потом распределили их как положено, заработало на ура, на ходу оптику выдергивали из свичей, кластер жил.
    Если коротко, то на кворумных дисках хранятся таблицы синхронизации блоков volume group, если ни одна из них не доступна, то кластер считает volume group degraded.

  • #17252

    Andriy
    Участник

    наткнулся вчера на чудесную фичу. storwize запоминает расположение виртуализуемых DS’ок по контроллерам. т. е. если у вас случайно при первом выполнении detectmdisk диски находились не на своих preferred контроллерах, то по выполнении redistribute logical drive, диски DS’ки сваляться обратно на non-preferred контроллеры.

    разруливал квадратно-гнездовым военным методом:

    while true ; do detectmdisk ; done

    в консоли storwize и перекидывать диски по-человечески… в конечном итоге запомнится “нужная” конфигурация расположения логических дисков по контроллерам.

  • #17253

    uxTuaHgp
    Участник

    есть такое
    SVC по барабану что там думает DS – как привык, так и будет тянуть.
    Я повторно перетаскивал на преферред и делал FC discovery

  • #17267

    Oleg
    Участник

    если кому интересно – на реальных бизнес-приложениях, в плане производительности снимаю со Storwize V7000 результат значительно лучше, чем показали IBM на SPC-1

  • #17268

    uxTuaHgp
    Участник

    что-то на реальном приложении больно записи мало

  • #17273

    Sever
    Участник

    +1

  • #17274

    Oleg
    Участник

    с чего вдруг там должно быть много записи? это ж не процессинг где R/W может быть ~50/50 и не архивная система c 10/90
    традиционно наибольшую нагрузку в финансовых приложениях создают разного рода аналитеги
    в период пересечения месяца, квартала или другого отчетного периода

  • #17275

    azar_mike
    Участник

    Вышли обновления 6.1.0.10 – SVC/Storwize,
    я конечно обновлять не буду, интересен опыт,
    как обновлять систему на которой все …
    У нас только vios грузится с локальных дисков,
    а остальное с SVC и распределено между 2 серверными.

  • #17277

    Oleg
    Участник

    Вышли обновления 6.1.0.10

    в прошлом году 🙂

    интересен опыт,
    как обновлять систему на которой все …

    кроме актуальной версии и детального изучения описания к ней
    нужен работающий мультипассинг на хостах
    и отсутствие серьезной нагрузки
    т.к. из-за смены write back -> write true
    время отклика дисковой будет просто эпическим

  • #17278

    Oldnick
    Участник

    для V7000 актуальная прошивка 6.4.0.4

  • #17279

    azar_mike
    Участник

    Она стабильна?
    В продакшене сколько используется?

  • #17280

    Oldnick
    Участник

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

  • #17281

    Michael
    Участник

    для V7000 актуальная прошивка 6.4.0.4

    Насколько я вижу, Межделмаш сейчас параллельно ведёт две ветки SVC: 6.3 и 6.4, для тех, кому по душе 6.3, выкатили 6.3.0.5 одновременно с 6.4.0.4

  • #17284

    Oldnick
    Участник

    New features in Storwize V7000 6.4.0.0

    * Support for non-disruptive movement of volumes between I/O groups
    (control enclosures)

    * Support for Fibre Channel over Ethernet (FCoE)

    Note that clustered systems must have all control enclosures connected
    using a native fibre channel fabric, although secondary connectivity
    over FCoE is supported for redundancy purposes

    * Support for Real-time compression

    __________________________________________________

    New features in Storwize V7000 6.3.0.x

    * Support for multi-session iSCSI host attachment

    * Language Support for Brazilian Portuguese, French, German, Italian, Japanese,
    Korean, Spanish, Turkish, Simplified Chinese and Traditional Chinese

    * Global Mirror with Change Volumes

    * Native LDAP Authentication

    New service features in Storwize V7000 6.3.0.0

    * This release contains a fix to address an issue that can result in incorrect data
    being read from a Volume under extreme conditions of drive timeout and offline events.

    This issue has only been observed under test conditions involving large amounts of
    simultaneous error injects.

    _________________________________________

    New features in Storwize V7000 6.2.0.x

    * Support for 3PAR Storage Arrays – F200, F400, T400, T800

    * Support for OpenVMS hosts.

    * Language Support for Brazilian Portuguese and Korean

    * Language Support for French, German, Italian, Japanese, Spanish, Simplified
    Chinese and Traditional Chinese

    * Real-time performance monitoring

    * Support for VMware vStorage APIs for Array Integration (VAAI)

    * Support for FlashCopy targets as Metro or Global Mirror sources

    * Support for 1PB LUNs on IBM DS3000, DS4000 and DS5000 storage systems

    * Support for 2076-312 and 2076-324 control enclosures, providing 10Gbps iSCSI
    functionality

    * Support for clustering of two Storwize V7000 systems

    * Support for small form factor 15K RPM 146GB drives

  • #17285

    Michael
    Участник

    Language Support for Brazilian Portuguese, French, German, Italian, Japanese, Korean, Spanish, Turkish, Simplified Chinese and Traditional Chinese

    Даже на турецком сбацали, ёпрст… А русский никак не могут осилить? :angry:

  • #17286

    Oldnick
    Участник

    кстати, а как там язык переключить? в меню что-то не могу найти…

  • #17437

    Victor Sedyakin
    Участник

    IBM заявил, что в новой версии прошивки 6.4.1 для V7000/SVC наконец-то появилась официальная поддержка FC direct attach. Напомню, ранее V7000 подключить напрямую можно было только через RPQ; официально поддерживалось только коммутируемое подключение через SAN-свичи.
    См. “Direct Attach” http://www-01.ibm.com/support/docview.wss?uid=ssg1S1004113

  • #18577

    Oldnick
    Участник

    три таких батарейки стоят в каждом блоке питания V7000

    [/URL]

    Nano-Phosphate LiFePO4 A123 ANR26650M1A Cell
    Nominal voltage: 3.3V
    Nominal capacity: 2.5Ah

    Параметры встроенного UPS:
    Max Discharge: voltage 9.9V, 48A/12s then 35A/200s: total 212s

    [/URL]

    [/URL]

  • #18578

    Oleg
    Участник

    три таких батарейки стоят в каждом блоке питания V7000

    а в IBM когда-то рассказывали, что там не требующие замены супер-конденсаторы 🙂
    но эти “батарейки” кстати, тоже очень качественные, (10USD штука, не у IBM ессно – у производителя этих аккумуляторов) в отличие от того сугубо китайского копеечного гавна (пардон, за мой “французский”), которое ставилось в DS4800 и его родственников

  • #18579

    Oldnick
    Участник

    а в IBM когда-то рассказывали, что там не требующие замены супер-конденсаторы 🙂
    в

    в контроллерах SCSI и SAS, которые обычно использовались в IBM i всегда применялись аккумуляторы. сначала никель-кадмий, потом литий…
    аккумуляторы нужны были для питания кеша в случае отключения основного питания.
    в последних hi-end контроллерах 5913 (CCIN 575B, PCIe2 1.8 GB Cache RAID SAS adapter Tri-port 6 Gb, анонсированы осенью 2011) были применены суперконденсаторы.
    https://twitter.com/Sever_i/status/307201973168521217/photo/1

  • #18995

    Oldnick
    Участник

    обновился документ

    Hints and Tips: V7000 in an IBM i Environment

    http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102305

  • #19000

    Oleg
    Участник

    недавно тестировал Easy Tier на V7000

  • #19001

    uxTuaHgp
    Участник

    Не понял как при 100% Random операциях Tiering чего-то там перемещает.
    Или я постановки не понял?
    Общий объем пула какой был?
    Увидел 2 пула по 15ТБ. Так?

    Тома на хосты какого объема выделены?
    Два по 2ТБ с каждого пула?
    То есть каждый тестируемый том был по 4ТБ?

    100% случайные операции по всему объему выделенного хосту тома?

    В SSD ярусе на каждом пуле было по 600ГБ получается?
    Для пущей красивости попугаев может быть надо было тома выделять не по 2ТБ, а по 300ГБ, чтобы вся активная зона заехала в SSD, а не 1/7 часть?

    Как долго мучили массив случайной записью?
    Интересно было бы достоверно забить все ячейки SSD и начать их переписывать.
    Наверное надо было посмотреть что будет через сутки-двое случайной записи.
    Вроде бы один SSD диск не способен дать более 1000 IOPS при 100% Random Write?

    Вообще конечно синтетика, но я не знаю софта, который бы моделировал именно красивую кривую распределения активных блоков по пространству тома.

    Мы тестировали Hitachi Dynamic Tiering на энтерпрайзе с реальной нагрузкой продуктивной – получили сокращение времени отклика и прирост производительности порядка 25% всего.

  • #19009

    Oleg
    Участник

    Не понял как при 100% Random операциях Tiering чего-то там перемещает.

    а вот так – находит более горячие блоки и мувит 🙂
    не существует идеального random-генератора
    все равно получается какое-то распределение

    Два по 2ТБ с каждого пула?
    То есть каждый тестируемый том был по 4ТБ?

    да

    100% случайные операции по всему объему выделенного хосту тома?

    всего объема, занятому файлами (1.2ТB на каждом из 2ТB волюм)
    волюмы на сторадже – “тонкие”
    это на скриншотах видно

    В SSD ярусе на каждом пуле было по 600ГБ получается?

    да

    Для пущей красивости попугаев может быть надо было тома выделять не по 2ТБ, а по 300ГБ, чтобы вся активная зона заехала в SSD, а не 1/7 часть?

    зачем?
    “заехали” все горячие блоки (с двух соответствующих волюмов на сторадже)

    Как долго мучили массив случайной записью?
    Интересно было бы достоверно забить все ячейки SSD и начать их переписывать.
    Наверное надо было посмотреть что будет через сутки-двое случайной записи.

    это не бытовые SSD – аллокейшн 100% емкости их не убьет по производительности, контроллеру SSD все равно будет доступна большая резервная область
    через сутки единственное что произошло – мне надоело 🙂
    может и будет снижение производительности – но во временных рамках других порядков

    Вроде бы один SSD диск не способен дать более 1000 IOPS при 100% Random Write?

    как бы очень зависит от размера блока, но в любом случае
    тот который установлен в неттопе, с которого я набираю этот текст – наверняка нет 🙂
    а вот современные энтерпрайз SSD – в основном могут больше
    кстати, в STEC тут пару документов на эту тему обновилось http://www.stec-inc.com/downloads/whitepapers/Benchmarking_Enterprise_SSDs.pdf
    обратите внимание на Figure A

    Мы тестировали Hitachi Dynamic Tiering на энтерпрайзе с реальной нагрузкой продуктивной – получили сокращение времени отклика и прирост производительности порядка 25% всего.

    а не поделитесь более детальной информацией?
    что понимается под прирост производительности 25%?
    если рост иопс на 25% – то это не совсем показатель, может все дело в самом приложении
    в реальном продуктиве может быть важнее снижение время отклика – сокращение было в сколько раз?
    не говоря уже о времени выполнения каких-то операций для конечного пользователя – тайминг до/после не сравнивали?

  • #19010

    uxTuaHgp
    Участник

    Мы статистически обсчитывали за неделю иопсы, потребление CPU, время обслуживания по чтению и записи. Даже на СХД и ОС разницы в разы не получилось, хотя горячая зона была красивая и 90% активных данных переезжало в SSD ярус.
    К сожалению, если на уровне СХД, ОС и БД еще какое-то преимущество видно, то на пользовательских операциях это практически никак не отразилось, потому что задержки на СХД – капля в море.
    Наверное, если бы мы СУБД загнали в угол, сократив кэш в несколько раз – разница и получилась бы в разы.

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