Это зависит от реализации. И описание про "power of 2" применимо именно к там, где написано (в данном случае документация на СХД MSA и родственников). Существуют реализации, где такого правила вовсе нет и 3+1 или 7+1 может быть наоборот рекомендованным размером для RAID5 из-за внутренних оптимизаций. Про zfs не скажу.
Вы не правы, и в свою очередь приводите ненужную, ложную, даже мешающую аналогию про классы. TCP/IP не является ни наследованием, ни реализацией OSI, как и многие другие стеки. Как раз именно реализации модели OSI вроде и нет.
Модель OSI, если не подводит память, планировалась изначально именно реализовывать. Но по факту - осталась именно как удобная модель для изучения / пояснения. А в реализациях совсем не она: и уровней может быть другое число, и разделение может быть совсем по-другому.
История слегка похожа на выдуманную.
И не пойму зачем выдуманную, ладно бы идею дельную выдуманная история показывала.
Может не осознал я чего. Но меня после прочтения бомбануло, т.к. с темой СХД и алертов чуть знаком.
Но извиняйте, гугль выдал в рекомендацию заинтересовавший заголовок, прочитал и меня бомбануло, поэтому многобукв:
1. И СХД какая-то сомнительная, как тут уже ответили.
Которой не достаточно, чтобы контроллер поменяли и сама прочитать настройки не умеет.
И которая при фактически неработающем втором контроллере алерт гасит.
И что при умершем контроллере только через пару месяцев кто-то что-то заметил.
И придумать, что такое «контроллер сбоит, но ошибки исправляет на лету» вот сходу не могу.
Ежели это не ECC ошибки памяти или не SCSI ошибки по шине.
Но это значит, что он (или его компонент) приговорён и таймер запущен.
И зачем СХД выключать (на это делается акцент: что меняли не выключая, что зачем-то нужно менять, чтобы заменить второй).
Да и по факту, если уж действительно СХД такая нежная, что надо на контроллер настройки восстанавливать (откуда?) отдельной процедурой, то если один контроллер в боевой режим не завели (не всосал настройки ip и например карту мапинга томов и рейдов на диски или ещё чего (наверное это понимается под «пустым новым»), а второй умер…
То восстановление тут скорее всего мягко говоря нетривиальным будет — т.к. имеем два «пустых» контроллера и либо им достаточно только ip-шники дать. Ну или просто вывести контроллер из какого-нибудь «режима обслуживания».
Короче либо вся техническая соль тут опущена, либо…
Про СХД, которая получает ip адреса (управления или доступа к данным?) по DHCP, который лежит на ней же — тоже история сомнительная. Как аллегорическая иллюстрация идиотизма — да, как в жизни — очень сомнительно (это надо с одной стороны заморочиться сильнее, чем чтобы выдать статику, с другой — не думать головой совсем).
2. Непонятен статус помогающих: вроде попросили их всё-таки помочь, рассказчик говорит о том, какие они крутые во всём: и диагноз поставили, и с кейсом помогли, и серийник запротоколировали, и контроллеры прямо с таможни заместо вендора получали (чёй-то?). Да и вендор то какой-то, у которого контроллеров «как водится» нет на складе.
Но в итоге то не помогли, не сумели, позволили факапу случиться.
Сумели похвастаться.
Непонятен и статус конкретного помогающего (литературного героя): кто он — инженер, что гайки и СХД крутит и на память все настройки помнит? пресейл? менеджер? Человек-оркестр?
А то про «бесплатную работу» и «спасибо не буркнули» — вызывает вопросы. Ежели инженер — зачем впрягался? (и зачем по телефону за спасибо ДЦ 24х7 поднимал? а ежели бы на тот конце провода не туда жамкнули — и данным всё — кто бы отвечал?). Ежели менеджер — почему инженер работал за бесплатно? Если пресейл — ну тогда нужно грамотнее байки на habr сочинять =)
Но вот было бы правдой, врядли стали бы писать историю на habr, где можно угадать заказчика. И где откровенно поливаете и называете глубоко некомпетентным их технического директора.
Если правда с ним регулярно работаете.
Или там и habr никто не читает.
Да и всё-таки не верю:
Ни про «пару минут безответного стука» чтобы понять, что вся инфраструктура лежит (а не сетевушка в ноуте или порт коммутатора неисправны).
Ни про то, что на восстановление суммарно ушло «четыре десятка минут».
И что решено это было всё не по удалёнке, а по телефону.
контрастирует такая скорость с тотальной некомпетентностью сотрудников на месте.
Так как представляю реальные тайминги решения проблем и статистику имею не один год. Особенно если в это время профи искал базовые сетевые настройки СХД, а не взяли их например из диагностики, которой помогали при открытии кейса, ага.
Ну и если бы правда мы имели бы СХД вот с двумя голыми контроллерами (без конфигов) и продуктивными данными внутри. Это работа где ошибаться не стоит — в общем случае легко можно сделать так, что данных больше не будет (решит контроллер диски переинициализировать например, не то нажмут на том конце провода). Не делают такого вслепую по телефону, имея на том конце провода того, кто не осилил контроллер корректно заменить.
Хотя ладно, это просто моя зависть, придётся поверить и смириться, что есть спецы покруче и отважнее меня на порядок.
3. Мораль или польза истории непонятна. История по сути про тотальную некомпетентность по кругу.
Про некомпетентность технического руководителя заказчика.
Про некомпетентность того, кто контроллер менял (или это руководитель и был?)
Кто не смотрел в управлялку СХД.
Кто не смотрел в управлялки среды виртуализации (чай там не всё в порядке с путями было).
Кто кейс в поддержке у вендора закрывает без подтверждения по диагностике, что с СХД всё ок.
Вендора, у которого регулярно контроллеров на замену нет.
И сомнительный героизм лирического героя.
А рецептом предлагается ввести некоторую бюрократию и ответственность.
Что в целом то хорошо и инновацией не является.
Но кто ответственно и вдумчиво составит такие планы?
Сотрудники, некомпетентность которых продемонстрирована?
Или консалтинг, что всё проанализирует, денег возьмёт, означенные талмуды схемы и картинки нарисует?
Инструментарий ведения и поддержания в актуальном виде не предлагается. Excel?
Или брошюрованные талмуды в сейфе под роспись?
Вот про хороший и удобный инструментарий для не самой большой в мире компании было бы интересно.
А уж ежели даже про инструментарий. Коли рассказали подробно про категории алертов — то можно было бы например сказать, что во многих системах алертов: в том числе и на некоторых (не всех) СХД, и не только, есть часто такие функции как:
— aknowledge -подтвердить, что сообщение кто-то видел
— resolve — снять алерт, если система сама не сняла по устранению проблемы
Ну и комментарий во многих можно оставить (почти как комментарий к тому, почему Win собираетесь перезагрузить).
Да и что заходить в управлялку желательно под индивидуальной (доменной например) учёткой.
И чтобы правилом было, что алертов или warning неразрешённых висеть не должно.
И в результате не быть алерта, про который все знают, что есть, но никак не дойдут руки снять (а новый потом не заметят).
Т.е. сами эти алерты отчасти задачу планов решают.
Не говоря уже про системы мониторинга, CMDB и прочая по пути к светлому ITIL.
А если админ говорит, что боссу доложил и задачу выполнил, а реакции два месяца нет — планы не помогут.
А рецепт чтобы было всё нормально с СХД.
1) Компетентные сотрудники.
2) Нормальные СХД.
3) Нормальная поддержка и настройка отправки алертов тому, кто в них понимает.
Над примером планов, где «Потеря данных (продуктивных)» это средняя вероятность нарушения работы.
И которое индицируется «Всплывающим уведомлением».
И решается «Автоматическим восстановлением»…
поржал и призадумался. С этим то другой вопрос связан, на который ответа для себя толком за многие годы не нашёл за долгое время общения с СХД.
Бомбануло и поржал, поржал и бомбануло.
История выдуманная, много нестыковок, зачем написано — непонятно.
Единственный вывод — если в некомпетентные сотрудники, а тем более в руководстве — будет печально.
А лирический герой — д'Артаньян.
И при этом зачем-то про какие-то планы, какие-то СХД, какие-то алерты, которые лишь антураж для этой сюжетной линии.
Это зависит от реализации. И описание про "power of 2" применимо именно к там, где написано (в данном случае документация на СХД MSA и родственников). Существуют реализации, где такого правила вовсе нет и 3+1 или 7+1 может быть наоборот рекомендованным размером для RAID5 из-за внутренних оптимизаций. Про zfs не скажу.
Вы не правы, и в свою очередь приводите ненужную, ложную, даже мешающую аналогию про классы. TCP/IP не является ни наследованием, ни реализацией OSI, как и многие другие стеки. Как раз именно реализации модели OSI вроде и нет.
Модель OSI, если не подводит память, планировалась изначально именно реализовывать. Но по факту - осталась именно как удобная модель для изучения / пояснения. А в реализациях совсем не она: и уровней может быть другое число, и разделение может быть совсем по-другому.
И не пойму зачем выдуманную, ладно бы идею дельную выдуманная история показывала.
Может не осознал я чего. Но меня после прочтения бомбануло, т.к. с темой СХД и алертов чуть знаком.
Но извиняйте, гугль выдал в рекомендацию заинтересовавший заголовок, прочитал и меня бомбануло, поэтому многобукв:
1. И СХД какая-то сомнительная, как тут уже ответили.
Которой не достаточно, чтобы контроллер поменяли и сама прочитать настройки не умеет.
И которая при фактически неработающем втором контроллере алерт гасит.
И что при умершем контроллере только через пару месяцев кто-то что-то заметил.
И придумать, что такое «контроллер сбоит, но ошибки исправляет на лету» вот сходу не могу.
Ежели это не ECC ошибки памяти или не SCSI ошибки по шине.
Но это значит, что он (или его компонент) приговорён и таймер запущен.
И зачем СХД выключать (на это делается акцент: что меняли не выключая, что зачем-то нужно менять, чтобы заменить второй).
Да и по факту, если уж действительно СХД такая нежная, что надо на контроллер настройки восстанавливать (откуда?) отдельной процедурой, то если один контроллер в боевой режим не завели (не всосал настройки ip и например карту мапинга томов и рейдов на диски или ещё чего (наверное это понимается под «пустым новым»), а второй умер…
То восстановление тут скорее всего мягко говоря нетривиальным будет — т.к. имеем два «пустых» контроллера и либо им достаточно только ip-шники дать. Ну или просто вывести контроллер из какого-нибудь «режима обслуживания».
Короче либо вся техническая соль тут опущена, либо…
Про СХД, которая получает ip адреса (управления или доступа к данным?) по DHCP, который лежит на ней же — тоже история сомнительная. Как аллегорическая иллюстрация идиотизма — да, как в жизни — очень сомнительно (это надо с одной стороны заморочиться сильнее, чем чтобы выдать статику, с другой — не думать головой совсем).
2. Непонятен статус помогающих: вроде попросили их всё-таки помочь, рассказчик говорит о том, какие они крутые во всём: и диагноз поставили, и с кейсом помогли, и серийник запротоколировали, и контроллеры прямо с таможни заместо вендора получали (чёй-то?). Да и вендор то какой-то, у которого контроллеров «как водится» нет на складе.
Но в итоге то не помогли, не сумели, позволили факапу случиться.
Сумели похвастаться.
Непонятен и статус конкретного помогающего (литературного героя): кто он — инженер, что гайки и СХД крутит и на память все настройки помнит? пресейл? менеджер? Человек-оркестр?
А то про «бесплатную работу» и «спасибо не буркнули» — вызывает вопросы. Ежели инженер — зачем впрягался? (и зачем по телефону за спасибо ДЦ 24х7 поднимал? а ежели бы на тот конце провода не туда жамкнули — и данным всё — кто бы отвечал?). Ежели менеджер — почему инженер работал за бесплатно? Если пресейл — ну тогда нужно грамотнее байки на habr сочинять =)
Но вот было бы правдой, врядли стали бы писать историю на habr, где можно угадать заказчика. И где откровенно поливаете и называете глубоко некомпетентным их технического директора.
Если правда с ним регулярно работаете.
Или там и habr никто не читает.
Да и всё-таки не верю:
Ни про «пару минут безответного стука» чтобы понять, что вся инфраструктура лежит (а не сетевушка в ноуте или порт коммутатора неисправны).
Ни про то, что на восстановление суммарно ушло «четыре десятка минут».
И что решено это было всё не по удалёнке, а по телефону.
контрастирует такая скорость с тотальной некомпетентностью сотрудников на месте.
Так как представляю реальные тайминги решения проблем и статистику имею не один год. Особенно если в это время профи искал базовые сетевые настройки СХД, а не взяли их например из диагностики, которой помогали при открытии кейса, ага.
Ну и если бы правда мы имели бы СХД вот с двумя голыми контроллерами (без конфигов) и продуктивными данными внутри. Это работа где ошибаться не стоит — в общем случае легко можно сделать так, что данных больше не будет (решит контроллер диски переинициализировать например, не то нажмут на том конце провода). Не делают такого вслепую по телефону, имея на том конце провода того, кто не осилил контроллер корректно заменить.
Хотя ладно, это просто моя зависть, придётся поверить и смириться, что есть спецы покруче и отважнее меня на порядок.
3. Мораль или польза истории непонятна. История по сути про тотальную некомпетентность по кругу.
Про некомпетентность технического руководителя заказчика.
Про некомпетентность того, кто контроллер менял (или это руководитель и был?)
Кто не смотрел в управлялку СХД.
Кто не смотрел в управлялки среды виртуализации (чай там не всё в порядке с путями было).
Кто кейс в поддержке у вендора закрывает без подтверждения по диагностике, что с СХД всё ок.
Вендора, у которого регулярно контроллеров на замену нет.
И сомнительный героизм лирического героя.
А рецептом предлагается ввести некоторую бюрократию и ответственность.
Что в целом то хорошо и инновацией не является.
Но кто ответственно и вдумчиво составит такие планы?
Сотрудники, некомпетентность которых продемонстрирована?
Или консалтинг, что всё проанализирует, денег возьмёт, означенные талмуды схемы и картинки нарисует?
Инструментарий ведения и поддержания в актуальном виде не предлагается. Excel?
Или брошюрованные талмуды в сейфе под роспись?
Вот про хороший и удобный инструментарий для не самой большой в мире компании было бы интересно.
А уж ежели даже про инструментарий. Коли рассказали подробно про категории алертов — то можно было бы например сказать, что во многих системах алертов: в том числе и на некоторых (не всех) СХД, и не только, есть часто такие функции как:
— aknowledge -подтвердить, что сообщение кто-то видел
— resolve — снять алерт, если система сама не сняла по устранению проблемы
Ну и комментарий во многих можно оставить (почти как комментарий к тому, почему Win собираетесь перезагрузить).
Да и что заходить в управлялку желательно под индивидуальной (доменной например) учёткой.
И чтобы правилом было, что алертов или warning неразрешённых висеть не должно.
И в результате не быть алерта, про который все знают, что есть, но никак не дойдут руки снять (а новый потом не заметят).
Т.е. сами эти алерты отчасти задачу планов решают.
Не говоря уже про системы мониторинга, CMDB и прочая по пути к светлому ITIL.
А если админ говорит, что боссу доложил и задачу выполнил, а реакции два месяца нет — планы не помогут.
А рецепт чтобы было всё нормально с СХД.
1) Компетентные сотрудники.
2) Нормальные СХД.
3) Нормальная поддержка и настройка отправки алертов тому, кто в них понимает.
Над примером планов, где «Потеря данных (продуктивных)» это средняя вероятность нарушения работы.
И которое индицируется «Всплывающим уведомлением».
И решается «Автоматическим восстановлением»…
поржал и призадумался. С этим то другой вопрос связан, на который ответа для себя толком за многие годы не нашёл за долгое время общения с СХД.
Бомбануло и поржал, поржал и бомбануло.
История выдуманная, много нестыковок, зачем написано — непонятно.
Единственный вывод — если в некомпетентные сотрудники, а тем более в руководстве — будет печально.
А лирический герой — д'Артаньян.
И при этом зачем-то про какие-то планы, какие-то СХД, какие-то алерты, которые лишь антураж для этой сюжетной линии.