Как работает механизм перестроения MAC-таблиц при смене топологии?
Конкретнее:
Вот у свитча в MAC-таблице записано, что MAC-адрес получателя назначен такому-то порту. И он там, действительно, находился некоторое время назад, но был подключен не непосредственно, а через цепочку других свитчей.
Но с тех пор топология изменилась. Может быть хост с этим MAC-адресом физически переключили на другое плечо. А может быть путь к нему изменился в результате коррекции STP.
Как в этом случае происходит перестроение таблицы MAC-адресов?
Вот пришел на свитч Ethernet-кадр для данного MAC. Свитч посмотрел свою MAC-таблицу и определил, что в ней есть этот MAC-адрес и он находится на таком-то порту. Он пересылает его по этому порту… А в ответ — тишина.
Что происходит дальше? Какие таймауты существуют? Предусмотрены ли попытки повторного посыла перед перестроением таблицы? Сколько их? Как именно потом происходит перестроение таблицы?
В данном случае мы имеем вероятность выигрыша очка (7/(11+7)) ~=0.39.
Существенная неточность…
Из того факта, что мы выиграли 7 и проиграли 11 очков вовсе не следует, что вероятность выигрыша очка равна ровно 7/(7+11).
Вообще о точном значении вероятности исходя из этих данных утверждать нельзя. Можно только утверждать, что данная вероятность имеет некоторое непрерывное распределение, называемое бета-распределением.
А уж дальше можно заниматься монте-карлой. Только придется брать не конкретное значение вероятности, а некоторые интегральные значения на узеньких диапазонах с некоторыми вероятностями каждое.
Из данного фрагмента кода видно, что вычисляется наибольший вес, но не видно, какому потомку или самому узлу он принадлежит. А, следовательно, при попадании в узел все равно придется просматривать всех потомков, чтобы определить, по какой именно ветви следует продолжить поисковый спуск.
Можно подумать вот над чем: Не хранить в узле его собственный вес и дополнительно лучший вес, а только лучший вес и флаг, где он лежит:
0 — лучший вес принадлежит этому узлу (узел является листом и не имеет потомков);
1 — лучший вес находится в левой ветви;
2 — лучший вес находится в правой ветви;
3 — лучший вес принадлежит этому узлу (узел не является листом и имеет 1 или 2 потомка).
Надеюсь, под словами «бинарное дерево» вы понимаете именно то, что каждый узел имеет не более двух потомков, жестко разделенных на «правый» и «левый»?
Тогда процедура рекурсивного подъема с корректировкой чуть усложнится, но общая структура будет проще и сам рекурсивный спуск с поиском будет проще.
Ага… Т.е. при рекурсивном подъеме после «схлопывания» мы не только корректируем собственные коэффициенты выгодности в каждом узле, но и переписываем в них информацию о положении и величине наибольшего коэффициента выгодности в их подветвях?
Насчет вставки — пожалуй что соглашусь. Если не список, а бинарное дерево, то эффективность будет несколько выше. Но до идеала будет далеко, т.к. многие ветви будут вырожденными — просто не будет их в реестре.
А вот «стрелочка» внушает мне опасения…
Вот мы схлопнули псевдосеть с наибольшим коэффициентом выгодности… а где находится следующая по выгоде псевдосеть с наибольшим оставшимся коэффициентом? В какой ветви и подветви? Как нам эта стрелочка поможет? Она ведь знала только где находилась наибольшая, но ее уже нет.
Вот поэтому и не стоит заморачиваться с нулевыми хостами. Все равно объединение в подсети в данной утилите является искусственным и может не соответствовать реальным подсетям. Если в реале такой подсети нет, то нулевой (или со всеми единицами в номере хоста) адрес в искусственно введенной подсети вполне допустим.
А вот насчет повышения скорости вполне стоит подумать. Я не разбирался с алгоритмом, но как мне кажется, при добавлении нового адреса в список происходит его сравнение со всеми адресами из этого списка на предмет выявления наилучшего совпадения. Т.е. временная сложность уже не менее O(n^2).
Но на самом деле список еще и пополняется псевдоподсетями, с которыми этот новый IP тоже будет сравниваться. Таким образом производительность будет еще хуже. Как бы не O(log(n)*n^2).
Надо подумать о структуре данных, которая бы позволила хранить коэффициенты выгодности, быстро искать максимальные и корректировать их «на лету» при схлопывании.
Если маска не /24, а, к примеру, /23, то вполне могут существовать хосты с адресами 192.168.1.0 и 192.168.0.255.
Так что, лучше не заморачиваться с этими адресами, а попытаться ускорить работу за счет эффективного хранения данных. Например, в виде перестраиваемого дерева.
Если мы сожмём сеть 192.168.20.0/29, тогда мы уберём 5 записей из списка ...
Корректнее было бы говорить «уберем 6 записей из списка и добавим одну». Результат тот же, но суть действий описана точнее.
Насчет пересчета коэффициентов еще раз поясню. Возможно, пересчитывать и надо, но совсем по другому.
Вот после схлопывания сетей 192.168.20.0/30 и 192.168.20.4/30 имеем такую структуру-кандидата на следующее схлопывание:
192.168.20.0/29 (станет 8 IP из них 2 лишних)
192.168.20.0/30 (4 IP из них 1 лишний)
192.168.20.4/30 (4 IP из них 1 лишний)
Но на самом деле при схлопывании этой структуры этих двух лишних адресов не появится — они и так уже были лишними в подсетях 192.168.20.0/30 и 192.168.20.4/30.
И наше новое объединение позволило объединить 2 IP в один без дальнейшего увеличения числа лишних IP. Т.е. Кв такого схлопования будет Inf.
P.S. А еще у Вас не принимается во внимание, что адреса со всеми нулями и единицами в номере хоста не надо учитывать в числе «лишних», т.к. в подсети их и так нет. Но это уже сложно и неоднозначно, т.к. наше искусственное объединение адресов в подсети далеко не всегда соответствует реально существующим подсетям.
Родительские Кв плывут потому что не учитывают, что в объединяемых записях (если они не отдельные хосты с маской 32 или изначально заданные подсети представляют, а уже «схлопнутые» ранее) уже присутствует некоторое количество фиктивных IP, попавших туда «за компанию».
Если это учитывать, то окажется, что новое схлопывание добавит не так уж много новых лишних IP по сравнению с ранее добавленными предыдущими схлопываниями, т.е. для него Кв будет выше, чем на приведенных рисунках.
Может быть удастся даже таким образом вычислять родительские Кв, что они совсем не будут изменяться при схлопывании «деток».
Но для этого надо в каждой схлопнутой записи хранить не только IP/MASK, но и число подпадающих под нее «лишних» адресов.
Можно — то можно. Весь вопрос в том, как это реализовать?
В случае IP-адресов мы имеем строго определенное число октетов строго определенной длины. И порядок старшинства и октетов и двоичных цифр в них совпадает — уменьшается слева направо.
В случае FDNS начинается уже свистопляска. Зоны, домены, поддомены — имеют разную длину имен. В их иерархии старшей является зона. Но она находится справа FDNS. Но естественный порядок сортировки каждой части — сначала по левым символам. Уже заставляет задуматься.
Возможно ли в этом случае создание подобного эффективного подхода?
Чтобы использовать такие диски-ветераны, они должны сначала поработать где-нибудь в «тренировочном лагере» годика 2. Причем, под адекватными нагрузками. Только после чего их можно будет ставить на боевой сервер.
Т.е. у них на эти самые 2 года уменьшится ресурс, не говоря уже о гарантии.
Т.к. гарантия в большинстве случаев для SSD составляет 60 месяцев, то такие меры можно было бы считать оправданными, если бы выход из строя в процессе «тренировки» превышал 40%.
Но что-то мне подсказывает, что эта цифра окажется явно завышенной.
Поэтому, может быть для снижения риска геморроя это и имеет смысл, но с экономической точки зрения впустую профукать 2 года жизни накопителя явно невыгодно.
Если гибель одного пассажира — трагедия, то гибель целого коллектива — невосполнимая утрата. А на моей памяти только у нас были «Пахтакор», «Локомотив», хор Александрова.
Так и с информацией… бывает такая, которую можно и потерять, но при этом работоспособность будет восстановлена с нуля. В таком случае простого RAID-1 из двух дисков даже без HotSpare достаточно. А бывает и так (чаще всего), когда потеря информации будет критической. В таком случае без регулярных бэкапов не обойтись.
У меня самого было два случая, когда сбой одного диска в RAID-1 приводил к нарушениям ФС. А один раз сказёвый диск отказал в процессе восстановления RAID. Если бы не бэкапы — было бы все крайне плохо.
Очень просто… Вам не нужно обеспечить, в лучшем случае, бесперебойную работу десятка серверов, а в худшем — восстановление критической информации (и работоспособности) в течение нескольких часов.
А вот когда такая потребность появится, то будут и RAIDы, и регулярные автоматические локальные бэкапы, и удаленные и облачные. И резервирование провайдеров и ЗИПы не из б/у дисков, а из новья. И контроль S.M.A.R.T. где это возможно и фоновая верификация…
У меня дома неописуемый зоопарк флешек — Тресценды, АДата, Кингстоны, СанДиски и прочие, у которых я даже на брэнд не смотрю. Потому что понял, что везде можно напороться на лажу.
Купил как-то SD-Card Transcend 16 Gb дочке в читалку. Вставил в слот, читалка увидела ее, сказала, что надо отформатировать, после чего выдала ошибку. И видит у нее только несколько мегов. В компьютере — то же самое. Попытки восстановления всякими утилитами ни к чему хорошему не привели. Сходил в магазин (благо он в моем доме же располагался) — заменили. Принес домой, вставил в комп — тоже самое. После того, как я пришел возвращать третью, продавцы дали мне тоже Transcend, но не в «зеленой упаковке, а в синей»… Говорят, партия была бракованная.
Хотя я сильно подозреваю, что это был просто контрафакт.
Один раз планка памяти нам даже новая пришла дохлая. Закупили 4 планки по 16 Gb для расширения сервера… Вставили, а он не включается. Очко слегка взыграло (мало ли, что там в мамке могло треснуть, когда их вставляли), но начали разбираться. Выяснили, что с тремя запускается, а с одной — никак. Кое-как распределили память по слотам, чтобы на каждый процессор было поровну и отправили эту планку на замену.
А так да… От времени. Работает нормально, вдруг начинает вываливаться в BSOD или перестает загружаться. Память поменяли — снова дышит.
Но чаще — от кривых ручек. Когда криво в слот вставляют и питание подают. Хорошо, если при этом она ничего больше за собой не утянет. На YouTube видел ролик по ремонту, когда в результате криворукой замены памяти половину мамки вышибло.
Кстати, грех не воспользоваться тем, что здесь столько знатоков RAID собралось. Задам а я несколько вопросов, которые как-то стремно проверять на практике. Все относится к контроллерам с поддержкой MegaRAID:
1. Вставляем б/у девайс, который ранее был на нем в составе RAID-1. В настройке Foreign удаляем с него конфигурацию RAID. После этого ОСь (на другом компе и через SATA) увидит на нем разметку MBR и ФС? Если нет, то как это можно сделать, чтобы не терять информацию?
2. Отдельный диск из RAID-1 вынимаем, несем на другой комп и подключаем к SATA. Увидит ли на нем ОСь MBR-разметку и ФС? Можно ли будет снять образ диска со всеми файлами, например Акронисом? Вроде бы мне удавалось прочитать с него информацию (а может быть даже образ снять), но это было так давно, что я уже в этом не уверен.
3. А вот следующее не получалось сделать:
Как известно, LSI-контроллеры не поддерживают non-RAID диски. Т.е. если надо подключить к нему одиночный диск, то рекомендуют создать фиктивный RAID-0 и поместить в него этот единственный физический диск.
Но вот снять образ с такого физического диска, подключив его к SATA на другом компе мне не удалось. Acronis просто не распознал разметку, написал, что ФС диска не распознана, и сделал посекторню копию. Но, кажется, эта копия LSI-контроллером за корректную не воспринялась. В результате пришлось создавать новый VD с потерей всех данных.
Кто-нибудь пытался сделать образ одиночного диска из RAID-0 через SATA? Как успехи?
Так тут наоборот было… Сервер был самомсборным, ни разу не брендовым. Но все было сделано на совесть. Хоть на Caviar (неплохие модели, кстати у них были).
А вот на замену привезли как раз под наклейкой HP. Хотя, HP, как всем известно, сама HDD не производит. И они прослужили очень недолго
Ну, тут возможны варианты. Либо эти HP долго лежали на складе где-то невостребованные лет 10 и их решили в розницу спихнуть. Либо сам сервер комплексно стал загибаться — эти сказёвые скоростные диски сами по себе неслабо грелись, а тут на них почти до 70°C температура стала подниматься, несмотря на кулеры в корзинах.
Про седьмую модель Барракуды не слышал. А вот у одиннадцатой и в самом деле была «болезнь ЦеЦе» из-за кривой фирмвари. А еще у них был слишком тонкий шпиндель, из-за чего при малейших толчках головки «играли» и падали на блины.
Что интересно, одиннадцатых у нас было полно, но «зацецекали» только один-два. Остальные тихо помирали с ростом количества бэдов. Наверное, как раз из-за механики.
Так что, не все из них выходили из строя одинаково быстро. Не удивлюсь, если еще парочка где-то до сих пор крутится.
По поводу «дурдома»: Нужны были на замену сказёвые диски с разъемом Ultra-320 на 15K rpm. Уж не помню, чьи стояли на сервере изначально (может быть даже Caviar или Seagate), а привезли нам HP. Так вот, мы под лупой смотрели на контроллер — разница была только в напечатанных надписях и одной микрушке.
Так что, все они друг у друга всё передирают или перекупают.
А по той причине, что для некоторых целей серверные SSD/HDD и не нужны — только лишняя трата денег.
Например, есть сервер 1С/SQL. По рекомендации той же 1С базы данных нужно держать на одном RAID, журналы транзакций — на другом, временные таблицы — на отдельном диске или RAID, так же отдельные диски под временные файлы системы, Pagefile, кэш 1С и т.д. Но большинство этих «и т.д.» не являются критическими. В крайнем случае лечатся заменой диска и перегрузкой сервера. Держать под них отдельные серверные диски, тем более RAIDы — только корзины забивать и деньги тратить. А заполнены эти диски — на несколько гигов, максимум. И нагрузки на них нет совершенно.
Поэтому из 14 дисков на этом сервере у нас 9 серверных, объединенных в RAID-1 с HotSpare, и 5 десктопных (2 в RAID-1 без HotSpare и 3 отдельных).
Один Vertex OCZ 4, как я уже писал, иногда отваливался. То раз в пару месяцев, то 2 раза в месяц. Т.к. на нем были кэши 1С, то это в самом деле было неприятно — требовало физически отсоединить его, втыкнуть обратно, пошаманить в RAID-менеджере, восстановить ФС, если есть ошибки, может быть почистить кэш. Мелочь на 10-15 минут, но нервировала. Но после замены на Kingston проблем уже полгода нет.
Как работает механизм перестроения MAC-таблиц при смене топологии?
Конкретнее:
Вот у свитча в MAC-таблице записано, что MAC-адрес получателя назначен такому-то порту. И он там, действительно, находился некоторое время назад, но был подключен не непосредственно, а через цепочку других свитчей.
Но с тех пор топология изменилась. Может быть хост с этим MAC-адресом физически переключили на другое плечо. А может быть путь к нему изменился в результате коррекции STP.
Как в этом случае происходит перестроение таблицы MAC-адресов?
Вот пришел на свитч Ethernet-кадр для данного MAC. Свитч посмотрел свою MAC-таблицу и определил, что в ней есть этот MAC-адрес и он находится на таком-то порту. Он пересылает его по этому порту… А в ответ — тишина.
Что происходит дальше? Какие таймауты существуют? Предусмотрены ли попытки повторного посыла перед перестроением таблицы? Сколько их? Как именно потом происходит перестроение таблицы?
Или все на самом деле не так работает? А как?
Существенная неточность…
Из того факта, что мы выиграли 7 и проиграли 11 очков вовсе не следует, что вероятность выигрыша очка равна ровно 7/(7+11).
Вообще о точном значении вероятности исходя из этих данных утверждать нельзя. Можно только утверждать, что данная вероятность имеет некоторое непрерывное распределение, называемое бета-распределением.
А уж дальше можно заниматься монте-карлой. Только придется брать не конкретное значение вероятности, а некоторые интегральные значения на узеньких диапазонах с некоторыми вероятностями каждое.
В общем, все не так просто, как на самом деле…
Можно подумать вот над чем: Не хранить в узле его собственный вес и дополнительно лучший вес, а только лучший вес и флаг, где он лежит:
0 — лучший вес принадлежит этому узлу (узел является листом и не имеет потомков);
1 — лучший вес находится в левой ветви;
2 — лучший вес находится в правой ветви;
3 — лучший вес принадлежит этому узлу (узел не является листом и имеет 1 или 2 потомка).
Надеюсь, под словами «бинарное дерево» вы понимаете именно то, что каждый узел имеет не более двух потомков, жестко разделенных на «правый» и «левый»?
Тогда процедура рекурсивного подъема с корректировкой чуть усложнится, но общая структура будет проще и сам рекурсивный спуск с поиском будет проще.
А вот «стрелочка» внушает мне опасения…
Вот мы схлопнули псевдосеть с наибольшим коэффициентом выгодности… а где находится следующая по выгоде псевдосеть с наибольшим оставшимся коэффициентом? В какой ветви и подветви? Как нам эта стрелочка поможет? Она ведь знала только где находилась наибольшая, но ее уже нет.
А вот насчет повышения скорости вполне стоит подумать. Я не разбирался с алгоритмом, но как мне кажется, при добавлении нового адреса в список происходит его сравнение со всеми адресами из этого списка на предмет выявления наилучшего совпадения. Т.е. временная сложность уже не менее O(n^2).
Но на самом деле список еще и пополняется псевдоподсетями, с которыми этот новый IP тоже будет сравниваться. Таким образом производительность будет еще хуже. Как бы не O(log(n)*n^2).
Надо подумать о структуре данных, которая бы позволила хранить коэффициенты выгодности, быстро искать максимальные и корректировать их «на лету» при схлопывании.
Если маска не /24, а, к примеру, /23, то вполне могут существовать хосты с адресами 192.168.1.0 и 192.168.0.255.
Так что, лучше не заморачиваться с этими адресами, а попытаться ускорить работу за счет эффективного хранения данных. Например, в виде перестраиваемого дерева.
Корректнее было бы говорить «уберем 6 записей из списка и добавим одну». Результат тот же, но суть действий описана точнее.
Насчет пересчета коэффициентов еще раз поясню. Возможно, пересчитывать и надо, но совсем по другому.
Вот после схлопывания сетей 192.168.20.0/30 и 192.168.20.4/30 имеем такую структуру-кандидата на следующее схлопывание:
192.168.20.0/29 (станет 8 IP из них 2 лишних)
192.168.20.0/30 (4 IP из них 1 лишний)
192.168.20.4/30 (4 IP из них 1 лишний)
Но на самом деле при схлопывании этой структуры этих двух лишних адресов не появится — они и так уже были лишними в подсетях 192.168.20.0/30 и 192.168.20.4/30.
И наше новое объединение позволило объединить 2 IP в один без дальнейшего увеличения числа лишних IP. Т.е. Кв такого схлопования будет Inf.
P.S. А еще у Вас не принимается во внимание, что адреса со всеми нулями и единицами в номере хоста не надо учитывать в числе «лишних», т.к. в подсети их и так нет. Но это уже сложно и неоднозначно, т.к. наше искусственное объединение адресов в подсети далеко не всегда соответствует реально существующим подсетям.
Что-то не ладно
в Датском королевствес ними.Родительские Кв плывут потому что не учитывают, что в объединяемых записях (если они не отдельные хосты с маской 32 или изначально заданные подсети представляют, а уже «схлопнутые» ранее) уже присутствует некоторое количество фиктивных IP, попавших туда «за компанию».
Если это учитывать, то окажется, что новое схлопывание добавит не так уж много новых лишних IP по сравнению с ранее добавленными предыдущими схлопываниями, т.е. для него Кв будет выше, чем на приведенных рисунках.
Может быть удастся даже таким образом вычислять родительские Кв, что они совсем не будут изменяться при схлопывании «деток».
Но для этого надо в каждой схлопнутой записи хранить не только IP/MASK, но и число подпадающих под нее «лишних» адресов.
В случае IP-адресов мы имеем строго определенное число октетов строго определенной длины. И порядок старшинства и октетов и двоичных цифр в них совпадает — уменьшается слева направо.
В случае FDNS начинается уже свистопляска. Зоны, домены, поддомены — имеют разную длину имен. В их иерархии старшей является зона. Но она находится справа FDNS. Но естественный порядок сортировки каждой части — сначала по левым символам. Уже заставляет задуматься.
Возможно ли в этом случае создание подобного эффективного подхода?
https://ru.wikipedia.org/wiki/Интенсивность_отказов
Но тут есть нюанс…
Чтобы использовать такие диски-ветераны, они должны сначала поработать где-нибудь в «тренировочном лагере» годика 2. Причем, под адекватными нагрузками. Только после чего их можно будет ставить на боевой сервер.
Т.е. у них на эти самые 2 года уменьшится ресурс, не говоря уже о гарантии.
Т.к. гарантия в большинстве случаев для SSD составляет 60 месяцев, то такие меры можно было бы считать оправданными, если бы выход из строя в процессе «тренировки» превышал 40%.
Но что-то мне подсказывает, что эта цифра окажется явно завышенной.
Поэтому, может быть для снижения риска геморроя это и имеет смысл, но с экономической точки зрения впустую профукать 2 года жизни накопителя явно невыгодно.
Если гибель одного пассажира — трагедия, то гибель целого коллектива — невосполнимая утрата. А на моей памяти только у нас были «Пахтакор», «Локомотив», хор Александрова.
Так и с информацией… бывает такая, которую можно и потерять, но при этом работоспособность будет восстановлена с нуля. В таком случае простого RAID-1 из двух дисков даже без HotSpare достаточно. А бывает и так (чаще всего), когда потеря информации будет критической. В таком случае без регулярных бэкапов не обойтись.
У меня самого было два случая, когда сбой одного диска в RAID-1 приводил к нарушениям ФС. А один раз сказёвый диск отказал в процессе восстановления RAID. Если бы не бэкапы — было бы все крайне плохо.
А вот когда такая потребность появится, то будут и RAIDы, и регулярные автоматические локальные бэкапы, и удаленные и облачные. И резервирование провайдеров и ЗИПы не из б/у дисков, а из новья. И контроль S.M.A.R.T. где это возможно и фоновая верификация…
Купил как-то SD-Card Transcend 16 Gb дочке в читалку. Вставил в слот, читалка увидела ее, сказала, что надо отформатировать, после чего выдала ошибку. И видит у нее только несколько мегов. В компьютере — то же самое. Попытки восстановления всякими утилитами ни к чему хорошему не привели. Сходил в магазин (благо он в моем доме же располагался) — заменили. Принес домой, вставил в комп — тоже самое. После того, как я пришел возвращать третью, продавцы дали мне тоже Transcend, но не в «зеленой упаковке, а в синей»… Говорят, партия была бракованная.
Хотя я сильно подозреваю, что это был просто контрафакт.
Один раз планка памяти нам даже новая пришла дохлая. Закупили 4 планки по 16 Gb для расширения сервера… Вставили, а он не включается. Очко слегка взыграло (мало ли, что там в мамке могло треснуть, когда их вставляли), но начали разбираться. Выяснили, что с тремя запускается, а с одной — никак. Кое-как распределили память по слотам, чтобы на каждый процессор было поровну и отправили эту планку на замену.
А так да… От времени. Работает нормально, вдруг начинает вываливаться в BSOD или перестает загружаться. Память поменяли — снова дышит.
Но чаще — от кривых ручек. Когда криво в слот вставляют и питание подают. Хорошо, если при этом она ничего больше за собой не утянет. На YouTube видел ролик по ремонту, когда в результате криворукой замены памяти половину мамки вышибло.
1. Вставляем б/у девайс, который ранее был на нем в составе RAID-1. В настройке Foreign удаляем с него конфигурацию RAID. После этого ОСь (на другом компе и через SATA) увидит на нем разметку MBR и ФС? Если нет, то как это можно сделать, чтобы не терять информацию?
2. Отдельный диск из RAID-1 вынимаем, несем на другой комп и подключаем к SATA. Увидит ли на нем ОСь MBR-разметку и ФС? Можно ли будет снять образ диска со всеми файлами, например Акронисом? Вроде бы мне удавалось прочитать с него информацию (а может быть даже образ снять), но это было так давно, что я уже в этом не уверен.
3. А вот следующее не получалось сделать:
Как известно, LSI-контроллеры не поддерживают non-RAID диски. Т.е. если надо подключить к нему одиночный диск, то рекомендуют создать фиктивный RAID-0 и поместить в него этот единственный физический диск.
Но вот снять образ с такого физического диска, подключив его к SATA на другом компе мне не удалось. Acronis просто не распознал разметку, написал, что ФС диска не распознана, и сделал посекторню копию. Но, кажется, эта копия LSI-контроллером за корректную не воспринялась. В результате пришлось создавать новый VD с потерей всех данных.
Кто-нибудь пытался сделать образ одиночного диска из RAID-0 через SATA? Как успехи?
А вот на замену привезли как раз под наклейкой HP. Хотя, HP, как всем известно, сама HDD не производит. И они прослужили очень недолго
Ну, тут возможны варианты. Либо эти HP долго лежали на складе где-то невостребованные лет 10 и их решили в розницу спихнуть. Либо сам сервер комплексно стал загибаться — эти сказёвые скоростные диски сами по себе неслабо грелись, а тут на них почти до 70°C температура стала подниматься, несмотря на кулеры в корзинах.
Что интересно, одиннадцатых у нас было полно, но «зацецекали» только один-два. Остальные тихо помирали с ростом количества бэдов. Наверное, как раз из-за механики.
Так что, не все из них выходили из строя одинаково быстро. Не удивлюсь, если еще парочка где-то до сих пор крутится.
По поводу «дурдома»: Нужны были на замену сказёвые диски с разъемом Ultra-320 на 15K rpm. Уж не помню, чьи стояли на сервере изначально (может быть даже Caviar или Seagate), а привезли нам HP. Так вот, мы под лупой смотрели на контроллер — разница была только в напечатанных надписях и одной микрушке.
Так что, все они друг у друга всё передирают или перекупают.
«Всю контрабанду делают в Одессе, на Малой Арнаутской улице» ©
Но разница все же была… родные проработали к тому времени лет 7, а привезенные HP вышли из строя через полгода…
Например, есть сервер 1С/SQL. По рекомендации той же 1С базы данных нужно держать на одном RAID, журналы транзакций — на другом, временные таблицы — на отдельном диске или RAID, так же отдельные диски под временные файлы системы, Pagefile, кэш 1С и т.д. Но большинство этих «и т.д.» не являются критическими. В крайнем случае лечатся заменой диска и перегрузкой сервера. Держать под них отдельные серверные диски, тем более RAIDы — только корзины забивать и деньги тратить. А заполнены эти диски — на несколько гигов, максимум. И нагрузки на них нет совершенно.
Поэтому из 14 дисков на этом сервере у нас 9 серверных, объединенных в RAID-1 с HotSpare, и 5 десктопных (2 в RAID-1 без HotSpare и 3 отдельных).
Один Vertex OCZ 4, как я уже писал, иногда отваливался. То раз в пару месяцев, то 2 раза в месяц. Т.к. на нем были кэши 1С, то это в самом деле было неприятно — требовало физически отсоединить его, втыкнуть обратно, пошаманить в RAID-менеджере, восстановить ФС, если есть ошибки, может быть почистить кэш. Мелочь на 10-15 минут, но нервировала. Но после замены на Kingston проблем уже полгода нет.
Вообще, о Vertex OCZ 4 я самого низкого мнения…