да сверхлегких самолетов и дельталетов используют спасательные капсулы, которые выстреливают в сторону парашют и целиком самолет приземляется на нем, эффективны даже на малых высотах. без них сертифицировать для полетов аппарат вроде уже не получится
пример — www.aviajournal.com/arhiv/1999/799/st5_799.html
нет, читая ваш блог, как-то наоборот с подозрением к данному решению отношусь :) просто хотел понять как это сделано у HP, может что-то новое придумали.
со спасением понятно — дело то совсем в другом. при использовании это вроде бы очень вкусной опции получается можем получить проблемы там, где они совсем никак не ожидались. и казалось бы мелкий алярм с тестовой виртуалкой обернется большим геммороем с боевой БД
хранилища hp всегда растягивают 1 raid на все имеющиеся диски или возможны ситуации с 2-я и более raid?
мой вопрос был про случай, когда мы теряем полностью по какой-то причине первый raid, то если была дедубликация 2-го на первый успешно сдохнет и 2-ой.
Спасибо за очередной маркетинг.
обьясните плиз, каким образом ваше решение дедубликации защищается от случая потери блока, на который по индексу ссылаются куча лунов?
в прошлом году переносил БД как раз на 24-х ядерник G5, в данный момент сервер себя уже оправдал на все сто, проблем после запуска никаких.
одно но — уже не в первый сервер приходит с неисправной матерью, хорошо хоть по гарантии относительно быстро решают.
п.с. если возможно — было бы намного интереснее прочитать про реальные примеры построения инфраструктуры на вашем оборудовании, а не просто маркетинговые обзоры. например, в данный момент очень интересуют примеры построения SAN на Eva, как выбирать, как лучше конфигурить в разных ситуациях, варианты как бекапить/резервировать это чудо? ваши сейлеры естественно сразу же радостно втюхивают 2-е 6400/8400 а надо ли оно? связаться с вашими инженерами, которые реально знают и работают с этими железками — почему то очень сложно, хотя сейчас вроде как попроще стало чем раньше.
Спасибо.
нет — коннект может занять длительное время, что неприемлемо с точки зрения бизнеса. там gprs линк поднят постоянно — и постоянно идут «пинги» центрального сервера (хотя зависит от реализации конечно). и не так то и дорого это стоит кстати — наше оборудование укладывается в 7-8$ с экземпляра.
какой-то бестолковый мобильник с такой батарейкой… если только как гиковский гаджет…
имхо полезней была бы отдельная емкость и подключаешь ее к тому, что нужно зарядить/поддержать… правда токи там наверное не очень то и большие…
/me размечтался… в поезд берешь кило сахару (вода в бойлере уже есть) и ноут работает всю дорогу :)
Отлично!
вам бы обратную связь реализовать от гусениц к МК с помощью датчика Холла или оптического какого нибудь, сигнал с инфракрасников подать через АЦП — и отслеживая таким образом угол разворота корпуса танка и уровень сигнала с датчиков получится объезжать препятствие чуть ли не впритирку без лишних движений… обалдеть, аж сам загорелся, где там мой детский танк валялся… :)
п.с. кстати… и двигателями управлять через ЦАП можно… сделать либо плавное либо 5-6 скоростей для простоты…
спасибо. Очень радует появление на хабре статей по Oracle. особенно по одной из вкусных технологий :)
разрешите побрюзжать маленько :) т.к. статья позиционируется для начинающих — было бы неплохо основные термины вывести отдельным списком/таблицей и сгруппировать их (процессы, различные кеши и тому подобное) — чтобы по мере чтения текста была возможность к ним быстро обращаться
SCO UnixWare 7.1.3!
эх было же… пару лет назад тоже разворачивал ее в esx, т.к. c старая железка умерла а на новых ее запустить не получилось. (приложение 90-х годов)
п.с. такое ощущение, что сервер собран из потолстевших процессорных модулей 580-ой серии :)
пример — www.aviajournal.com/arhiv/1999/799/st5_799.html
мой вопрос был про случай, когда мы теряем полностью по какой-то причине первый raid, то если была дедубликация 2-го на первый успешно сдохнет и 2-ой.
обьясните плиз, каким образом ваше решение дедубликации защищается от случая потери блока, на который по индексу ссылаются куча лунов?
одно но — уже не в первый сервер приходит с неисправной матерью, хорошо хоть по гарантии относительно быстро решают.
п.с. если возможно — было бы намного интереснее прочитать про реальные примеры построения инфраструктуры на вашем оборудовании, а не просто маркетинговые обзоры. например, в данный момент очень интересуют примеры построения SAN на Eva, как выбирать, как лучше конфигурить в разных ситуациях, варианты как бекапить/резервировать это чудо? ваши сейлеры естественно сразу же радостно втюхивают 2-е 6400/8400 а надо ли оно? связаться с вашими инженерами, которые реально знают и работают с этими железками — почему то очень сложно, хотя сейчас вроде как попроще стало чем раньше.
Спасибо.
п.с. помечтать уже нельзя :)
имхо полезней была бы отдельная емкость и подключаешь ее к тому, что нужно зарядить/поддержать… правда токи там наверное не очень то и большие…
/me размечтался… в поезд берешь кило сахару (вода в бойлере уже есть) и ноут работает всю дорогу :)
п.с. Ежик из камрадов прикольный :)
спасибо большое за статью :)
вам бы обратную связь реализовать от гусениц к МК с помощью датчика Холла или оптического какого нибудь, сигнал с инфракрасников подать через АЦП — и отслеживая таким образом угол разворота корпуса танка и уровень сигнала с датчиков получится объезжать препятствие чуть ли не впритирку без лишних движений… обалдеть, аж сам загорелся, где там мой детский танк валялся… :)
п.с. кстати… и двигателями управлять через ЦАП можно… сделать либо плавное либо 5-6 скоростей для простоты…
разрешите побрюзжать маленько :) т.к. статья позиционируется для начинающих — было бы неплохо основные термины вывести отдельным списком/таблицей и сгруппировать их (процессы, различные кеши и тому подобное) — чтобы по мере чтения текста была возможность к ним быстро обращаться
эх было же… пару лет назад тоже разворачивал ее в esx, т.к. c старая железка умерла а на новых ее запустить не получилось. (приложение 90-х годов)