Рубрика «надежность» - 6

Начинать чинить надо, пока не сломалось — сломанное поддаётся ремонту гораздо неохотней.
Юрий Татаркин

Риски ЦОД: резервирование инженерных системПосле того как обеспечены надежные стены и крыша над головой для ЦОД (статья «Риски ЦОД: выбираем месторасположение»), следующим шагом на пути обеспечения его отказоустойчивости должно стать резервирование инженерных систем. Строя дата-центры более 10 лет, мы убедились, что не все заказчики в полной мере осознают важность дублирования основных коммуникаций. Космические корабли и те падают, а оборудование в ЦОД в идеале должно работать 365 дней в году и 24 часа в сутки. Любая вышедшая из строя или нуждающаяся в профилактике деталь должна быть заменена без остановки работы всех критичных сервисов.

Как справедливо отметили наши читатели, далеко не всем компаниям нужен надежный ЦОД. Для некоторых его бесперебойная работа не предмет переживаний, а многие предпочтут хранить свои данные в публичном облаке. Данный паблик предназначен в большей степени для тех, кто по тем или иным соображениям безопасности или проходимости каналов связи сделал свой выбор в пользу собственного дата-центра и работы сервисов с уровнем доступности не менее трех девяток (простоя не более 1,6 часов в год).

Читать полностью »

«Избежать катастрофы может только тот, кто считает ее возможной».
В. Швебель

Мы все больше зависим от достижений прогресса: читаем почту в кинотеатрах, отмечаем места своего присутствия в foursquare. И бизнес стал не менее зависим от технических достижений. И если для нас поломка телефона становится небольшим неудобством, то для компаний выход из строя любого элемента ИТ-инфраструктуры оборачивается колоссальными убытками. Один час простоя российского банка, входящего в ТОП-100, равен стоимости автомобиля представительского класса. А теперь представьте, размер убытков и упущенную прибыль, если у корпоративного ЦОД рухнули стены или рядом с ним прорвало теплотрассу. Быстро ли запустятся там сервисы? Сколько времени потребуется для восстановления работоспособности, если нет резервного ЦОДа?

Избежать такой катастрофы можно, изначально правильно спроектировав ЦОД, обратив внимание на его месторасположение, эффективность применяемых в нем решений, энергоемкость, надежность и окупаемость.

Риски ЦОД: выбираем месторасположение

Читать полностью »

Облачные сервисы Windows Azure и убийственная звездочкаОдной из удобных плюшек облачных сервисов Windows Azure (PaaS, так называемые web и worker роли) является отсутствие необходимости устанавливать, настраивать и поддерживать операционную систему. Вместо этого разработчик может сосредоточиться на разработке начинки сервиса, которую затем в виде специального пакета он публикует в облако, после чего инфраструктура Windows Azure разворачивает его на виртуальных машинах с уже установленной, настроенной и оптимально пропатченной операционной системой, которую затем при необходимости сама же может обновить.

За все приходится платить. Если что-то звучит слишком хорошо, это неспроста. По умолчанию инфраструктура Windows Azure может в произвольный момент обновить операционную систему и далеко не факт, что после обновления ваш сервис сможет продолжить работу.

Рассмотрим подробно, как это происходит.Читать полностью »

Облака, ответственность и неожиданные ситуации с SSL сертификатамиПри обсуждении облачных платформ вполне естественно возникает вопрос о надежности платформы и об ответственности провайдера за ее неполадки. При этом ожидания пользователей самые высокие – все должно идеально работать 25 часов в сутки, 9 дней в неделю и все дни в году. В реальном мире возникают всевозможные проблемы – то при отключении внешнего электроснабжения не отработает переход на резервное, то на дне емкости с дизтопливом окажется конденсат (вода), то 29 февраля «через год» вычислят увеличением года на единицу.

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

Кто виноват, и что делать?

Читать полностью »

Проектирование высокопроизводительных систем: о чем не расскажут в книгах

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

Почему так происходит? Обеспечение высокой производительности и надежности ошибочно почитается многими за «черную магию». И неспроста — чуть ли не в каждой книге или статье на эту тему вы первым делом наткнетесь на утверждение типа «нельзя просто так взять и повысить производительность».

Читать полностью »

Исходя из недавнего отчета IWGCR (International Working Group on Cloud Computing Resiliency) каждый год сервисы облачных вычислений недоступны, в среднем, в течение 7.5 часов. Компании, которые частично или полностью используют облака для своих приложений и сервисов, в этом году пострадали несколько раз. Давайте рассмотрим самые большие отказы в работе облачных сервисов в 2012 году.
Читать полностью »

Во-первых, что понимать под надежностью применительно к программам? Понятие надежности изначально было исключительно инженерным. Согласно определению из Wiki, надежность – это свойство объекта сохранять работоспособное состояние в течение некоторого времени. Под «объектом» здесь понимается некая физическая система. И, как правило, чем сложнее эта система, те есть, чем большее количество элементов в нее входит, тем менее она надежна, поскольку вероятность отказа системы равна произведению вероятностей отказа ее частей (грубое приближение, если не учитывать дублирования и разной степени критичности компонентов). То же самое вполне применимо и к программным системам – чем сложнее программа, тем больше количество ошибок в ней. Однако между физическими системами и программными есть одно принципиальное различие.
Читать полностью »

За последние несколько лет привычные настольные компьютеры трансформировались в десятки вариантов конфигураций и форм-факторов для любых задач: от настоящих «монстров» для ресурсоемких работ в офисе до ультратонких легких ультрабуков и планшетов для тех, кто постоянно в движении. На этом фоне всегда интересны устройства, которые, по тем или иным причинам, выделяются из всего этого многообразия. Одним из таких, безусловно, является ноутбук Dell Latitude E6430 ATG — настоящий универсальный солдат для работы в сложных условиях, но с привычной офисной продуктивностью. Ноутбуки Dell Latitude ориентированы на корпоративных клиентов, их нет в свободной продаже в обычных супермаркетах электроники. Однако, при всей кажущейся узости аудитории, Latitude наверняка найдет своих ценителей. В масштабах России, где морозы, жара или повышенная влажность случаются неожиданно
и для ЖКХ, и для обычных граждан, возможность «завести» ноутбук в самых жестких
условиях оценят многие.
Осторожно! Трафик!
Читать полностью »

Вояджер 1 нащупал границу Солнечной системыВояджер-1 — автоматический зонд, запущенный в 1977 году, достиг границ гелиосферы. Гелиосфера — это область околосолнечного пространства, где солнечный ветер всё ещё преобладает над “галактическим ветром” — потоком частиц межзвёздной среды. Два года назад аппарат вошёл в зону гелиопаузы, где давление солнечного ветра и уравновешивает давление межзвёздной среды. В июне этого года датчики Вояджера зарегистрировали резкий рост уровня галактических космических лучей — аппарат вышел из под защиты солнечного ветра.

Вояджер-1 находится на расстоянии 121 астрономической единицы (18 миллиардов километров) от Солнца и движется со скоростью 17 километров в секунду. Это самый удалённый от Земли и самый быстрый объект, когда либо построенный человеком. Радиосигнал от Вояджера достигает Земли за 16 часов 38 минут.
Читать полностью »

Одна из причин, по которой язык Erlang так эффективен для построения сверхнадёжных больших телекоммуникационных систем — принцип “let it crash”. Ошибки и падения неизбежны, и вместо того, чтобы предотвращать их, лучше сделать так, чтобы одни части системы падали, не затрагивая других, и легко перезапускались. За счёт такой терпимости к ошибкам отдельных процессов достигается высокая надёжность системы в целом.

Похожий подход использовали учёные из лаборатории интеллектуальных систем Швейцарского Федерального Технологического Университета, когда создавали прототип летающего робота для работы в трудных и опасных условиях. Вместо того, чтобы городить сложную навигационную систему предотвращения столкновений, они просто защитили несущие роторы углепластиковым каркасом и добавили механизм, который позволяет упавшему и перевернувшемуся роботу взлететь без посторонней помощи.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js