Пользователи суперкомпьютера Киотского университета лишились 77 Тбайт информации из-за сбоя в работе системы резервного копирования, который произошёл по вине японского подразделения HPE. Из-за ошибки было потеряны данные за 1,5 дня работы — более 34 млн файлов. В результате инцидента пострадали данные 14 групп пользователей, для четырёх из которых информация утеряна безвозвратно.

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

Изображение: gizchina.com

Обновлённая версия скрипта была записана поверх старого варианта в тот момент, когда он уже выполнялся. По словам HPE, которая признала проблему после её изучения, значения переменных были утеряны, а новая версия скрипта была загружена с середины, что и привело к удалению файлов, а не связанных с ними журналов. При этом стандартных мер, которые смогли воспрепятствовать такому поведению (проще говоря, остановка выполнения скрипта с сообщением об ошибке), видимо, принято не было.

Суперкомпьютерная группировка Киотского университета. Изображение: monitaana.com

На текущий момент система резервного копирования приостановлена, а возобновление её работы запланировано на конец января 2022 г. после устранения проблем в ПО и принятия мер по предотвращению повторения случившегося. В будущем планируется использовать не только резервное копирование посредством зеркалирования, но и внедрение дополнительной, более совершенной системы инкрементальных бэкапов. Специалисты центра будут работать над улучшением не только функциональности, но и управляемости системы, чтобы минимизировать риски.

Компания Fastly сообщила о сокращении выручки и потере клиентов из-за того, что в июне произошёл крупный сбой в её сети доставки контента (CDN). Fastly использует периферийные точки присутствия для хранения контента с целью сокращения задержек в передаче данных и защиты клиентов от DDoS-атак, что помогает им справляться с пиками трафика. Но 8 июня из-за ошибки в конфигурации вся система вышла из строя.

В числе компаний, пострадавших от сбоя — Amazon, Twitch, Reddit, веб-сайты правительства Великобритании, а также множество других сайтов и сервисов. Сбой привёл к снижению объема трафика. «Мы ожидаем увидеть влияние сбоя на выручку в краткосрочной и среднесрочной перспективе, поскольку мы работаем с нашими клиентами, чтобы вернуть их трафик к нормальному уровню», — написал генеральный директор Fastly Джошуа (Joshua Bixby) Биксби в письме к акционерам.

Fastly

Он добавил: «У нас есть несколько клиентов, один из которых входит в Топ-10 заказчиков, которые пока не вернули свой трафик на платформу. У нас также было несколько клиентов, которые отложили запуск новых проектов, что приведёт к задержке времени поступления трафика на нашу платформу».

Fastly отметила, что сбой и эти задержки повлияли на её прогноз на третий квартал и весь год. Стоимость акций компании упала в конечном итоге на 19 %, хотя они показали резкий рост вскоре после инцидента. Несмотря на непредвиденные затраты, связанные со сбоем, выручка компании выросла на 14 % до $85 млн по сравнению с аналогичным периодом прошлого года, что немного ниже прогноза Уолл-стрит, равному в $85,7 млн.

IBM сообщила причины сбоя в работе облачного сервиса IBM Cloud во вторник, длившегося несколько часов и приведшего к обрушению сайтов и систем клиентов компании по всему миру. Слухи о возможной хакерской атаке не подтвердились, хотя компания обвинила в происшедшем инциденте «третью сторону».

В кратком уведомлении на странице состояния облачного сервиса компании было приведено следующее объяснение сбоя: «Подробный анализ первопричин ведётся. Расследование показывает, что провайдер внешней сети превысил нагрузку на сеть IBM Cloud из-за неправильной маршрутизации, что привело к серьезной перегрузке трафика и негативно сказалось на сервисах IBM Cloud и наших центрах обработки данных. Были предприняты меры по устранению проблем, чтобы предотвратить повторение. Анализ первопричин не выявил каких-либо проблем с потерей данных или кибербезопасностью».

Это довольно расплывчатое объяснение, но вполне допустимое. Наплыв трафика может произойти, когда некорректная настройка маршрутизации направляет пакеты в ошибочное место. Перехват BGP или неправильная конфигурация — известная проблема, хотя такая компания, как IBM, казалось бы, должна была предусмотреть возможность возникновения такого рода ошибки и иметь защиту или контрмеры, чтобы смягчить её последствия.

Можно предположить, что вина на минувшем сбое лежит на Akamai, провайдере платформ доставки контента и приложений, сотрудничающем с IBM. Тем не менее, сама IBM пока не всегда справляется с резкими скачками трафика. Например, при проведении электронной переписи населения в Австралии, компания по ошибке определила поток входящих соединений как (D)DoS-атаку.

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

Облачный сервис IBM Cloud столкнулся с продолжительным сбоем, который привёл к обрушению сервисов клиентов компании по всей планете. Не работали многие площадки, размещённые на платформе, включая агрегатор технологических новостей Techmeme.

На странице IBM, отражающей статус сервиса, появилось сообщение об ошибке, поэтому было сложно определить, насколько сильным являлся сбой и причину проблемы. «Извините, мы столкнулись с ошибкой с нашей стороны, и наши разработчики работают над её устранением. Пожалуйста, попробуйте перезагрузить страницу», — сообщалось на странице IBM Cloud.

Согласно данным ресурса DownDetector, первые жалобы пользователей на сбои в работе сервиса начали поступать во вторник, примерно в 14:30 PT (в среду в 0:30 мск). В аккаунте IBM Cloud в Twitter сохранялось молчание, но ресурс TechCrunch нашёл страницу подразделения IBM Aspera, размещённую на стороннем сервере, которая подтвердила наличие проблемы с сервисом по всему миру. «Мы были предупреждены о сбое в работе службы, затронувшем IBM AoC Managed Storage. Наши инженеры в настоящее время проводят расследование инцидента и будут предоставлять обновления, когда появится больше информации», — сообщалось на этой странице.

По словам Aspera, AoC Managed Storage столкнулся со «серьёзным сбоем» в Амстердаме, Далласе, Франкфурте, Мельбурне и Торонто. В числе пострадавших были указаны облачные кластеры IBM в Амстердаме, Ченнаи, Далласе, Франкфурте, Гонконге, Лондоне, Мельбурне, Мексике, Милане, Монреале, Осло, Сан-Хосе, Сан-Паулу, Сеуле, Сиднее, Токио, Торонто, Вашингтоне, Париже и Сингапуре.

В конечном итоге сервис IBM Cloud воспользовался Твиттером, чтобы известить пользователей о сбое и о том, что его специалисты занимаются решением проблемы. «Службы IBM Cloud восстанавливаются после того, как сегодня утром было зарегистрировано отключение. Мы нацелены на восстановление полных служб как можно скорее», — сообщалось в аккаунте IBM Cloud в 4:30 мск. А уже в 4:54 мск в Твиттере появилось сообщение о полном возобновлении работы всех служб IBM Cloud.

«Ростелеком» объявил о крупном сбое, который затронул несколько регионов России. Устранить неполадки планируется не раньше субботы.

«Произошла массовая авария, которая затронула сразу несколько регионов. Ведутся восстановительные работы. Ориентировочный срок решения 17.08 в течение дня», — сообщил оператор в Twitter-блоге.

Какие именно регионы были затронуты, в сообщении не уточняется. Согласно данным сервиса Downdetector, который отслеживает неполадки на различных сайтах, а также жалобы пользователей в социальных сетях, на сбои в работе оператора жалуются пользователи из Иркутска, Читы, Владивостока, Хабаровска и некоторых других городов.

Большинство абонентов (91 %), которых коснулась проблема, говорят, что не могут подключиться к Интернету. Ещё 6 % пожаловались на сбой в работе всех сервисов, 2 % пользователей указали на проблемы с телевидением.

Судя по статистике на Downdetector, массовые сбои начались около 9:00 по московскому времени. Они достигли пика в районе 14:00, когда было получено 460 отчетов о неполадках.

В Telegram-канале «ЗаТелеком» появилось сообщение о том, что причиной масштабного сбоя у «Ростелекома» стал обрыв на магистрали в районе посёлка Емельяново, недалеко от Красноярска. Точка обрыва находится на линии от Красноярска до Хабаровска, протяжённость которой составляет порядка 3 тыс. км.

Команда разработчиков «Яндекса» раскрыла детали инцидента, произошедшего 16 мая и повлёкшего негативные последствия для ряда пользователей cloud-платформы «Яндекс.Облако», лишившихся доступа к своим виртуальным машинам (ВМ) и данным.

«16 мая были запланированы регулярные технические работы по остановке и удалению виртуальных машин в облаках пользователей, заблокированных из-за неоплаты или нарушения правил использования сервисов "Яндекс.Облака". Это стандартная процедура по высвобождению ресурсов платформы, — говорится в заявлении компании. — В 16:35 (MSK) была запущена команда по удалению ВМ согласно сформированному списку. В 16:51 была обнаружена ошибка, и в 16:56 выполнение команды было остановлено в срочном порядке. Выяснилось, что при формировании списка был применён неверный принцип фильтрации, и в список попали активные виртуальные машины. Сейчас мы в процессе расследования ситуации и выяснения деталей».

Сообщается, что в результате инцидента были удалены 0,77% от общего числа виртуальных машин и boot-дисков. При этом были затронуты виртуальные машины только в зоне ru-central1-c. «Дополнительно созданные диски остались в сохранности. Пользователи, у которых были сделаны снимки дисков, смогли восстановить свои данные», — уточняют в «Яндексе».

Как бы то ни было, ситуация не из приятных. Для предотвращения подобных инцидентов в будущем в компании обещают принять ряд технических и организационных мер, а также призывают пользователей регулярно создавать резервные копии критически важных данных. «Мы хотим принести извинения каждому, кого затронул технический сбой в работе "Облака", — говорят в Яндексе. — На данный момент наша техническая поддержка работает в формате горячей линии, и мы оперативно помогаем каждому пользователю. В качестве компенсации всем, кого затронул инцидент, будут начислены гранты. Размер гранта будет определен индивидуально для каждого пользователя. Гранты станут доступны в личном кабинете в консоли "Облака" в течение трёх рабочих дней. Кроме того, для пострадавших пользователей снимки дисков не будут тарифицироваться в течение 90 дней (нулевая тарификация вступит в силу также в течение трёх рабочих дней)».

Материалы по теме:

• Платформа «Яндекс.Облако» стала доступна для всех пользователей в России;
• К 2021 году почти все рабочие нагрузки перенесут в облако;
• Услуги облачной платформы «Яндекс.Облако» обойдутся дешевле, чем у конкурентов.

Источник:

• cloud.yandex.ru

Российский оператор связи «МегаФон» устранил неполадки в центре обработки данных (ЦОД), из-за которых сервисы компании были недоступны некоторое время. Об этом со ссылкой на руководителя пресс-службы компании Юлию Дорохину сообщает РИА Новости.

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

«Сейчас все они работают в нормальном режиме», — заявила Дорохина в понедельник, 9 января.

bloomberg.com

Агентство напоминает, что ранее абоненты «МегаФона» начали жаловаться в социальных сетях на сложности при работе с рядом сервисов «МегаФона», таких как «Мультифон», «МегафонТВ» и «Мегафон.Банк». Кроме того, наблюдались проблемы при попытках зайти на сайт оператора и в личный кабинет.

Как сообщил агентству RNS представитель МТС Дмитрий Солодовников, компания усилила мониторинг ключевых элементов сети из-за погодных условий. Он заявил об отсутствии сбоев в работе систем оператора. Их нет и в сети «ВымпелКома», заверила пресс-секретарь компании Анна Айбашева.

Во вторник, 10 июля часть облачных сервисов компании Salesforce.com на некоторое время вышла из строя, что было связано со сбоем в системе энергоснабжения дата-центра Equinix в Кремниевой долине.

Сбой произошел в час ночи по тихоокеанскому времени, при этом доступ к сервисам компании потеряли пользователи из семи регионов Salesforce.com, включая три региона основных сервисов - NA1, NA5 и NA6 (Северная Америка делится на 14 таких регионов), и 4 региона сервисов уровня sandbox ("песочница" Salesforce.com, в которой пользователи изучают сервисы, а также отрабатывают и тестируют свои проекты) - CS0, CS1, CS3 и CS12. В 10:30 специалисты компании сообщили, что им удалось справиться с большинством проблем основных сервисов, и пользователи уже получают доступ к своим инструментальным панелям. Работа последнего из сервисов sandbox была восстановлена ориентировочно в полдень.

Представители Equinix сообщили о кратковременном сбое в системе энергоснабжения своего ЦОД. Результатом сбоя стал отказ примерно четверти серверов дата-центра, но уже через 1 минуту работа всех систем была восстановлена. Специалисты Equinix отметили, что хотя сбой был ликвидирован быстро, возобновление работы клиентских приложений потребовало значительного и разного для различных пользовательских конфигураций времени.

В текущем году это уже второй отказ систем энергоснабжения в дата-центрах Equinix. Первый, результатом которого стал перебой с сервисами Zoho, произошел в январе и также в одном из ЦОД Equinix в Кремниевой долине. Дата-центры Equinix считаются, тем не менее, весьма надежными, а сама компания гарантирует их бесперебойную работу в течение 99,9999% процентов времени, что в пересчете на один год дает 31,5 секунды времени простоя. Для Salesforce.com этот отказ стал вторым за последние два месяца - 12 июня дала сбой система хранения данных компании.

Материалы по теме:

• Настоящее и будущее российского серверного рынка: мнение экспертов;
• Kaspersky Endpoint Security 8 for Windows и Security Center 9: обзор новшеств;
• Готовность IT-инфраструктуры к аварийному восстановлению: исследование Acronis.

Источник:

• datacenterknowledge.com

Представители компании Amazon дали некоторые объяснения по поводу выхода из строя наиболее популярных облачных сервисов компании. Как выяснилось, человеческая ошибка, которая произошла при работах над апгрейдом системы, привела к тому, что резервная сеть сервиса EBS (Elastic Block Service) взяла на себя весь сетевой трафик восточного побережья США, что привело к перегрузке и выходу из строя всей системы. В конечном счете, компании удалось восстановить большую часть данных, но 0,07% данных «не могли быть восстановлены для клиентского доступа в согласованном состоянии». Пользователям предоставляется весьма небольшой срок в 10 дней для проверки контрольных панелей AWS (Amazon Web Services). Нет никаких сомнений, что многие пользователи уже изучают вопросы, связанные с условиями, на которых Amazon предоставляет свои сервисы, и, возможно, этими вопросами занимаются уже их адвокаты. 

EBS является, по существу, системой хранения данных сервиса EC2 (Elastic Compute Cloud), которая и позволяет арендовать компьютерные мощности в облаке Amazon. Для работы EBS используются две сети: основная, пропускающая через себя основной трафик, и вспомогательная, с меньшей пропускной способностью, предназначенная для резервирования (репликации) данных и коммуникаций между узлами EBS. Обе состоят из кластеров, при этом каждый из узлов каждого кластера действует, как отдельный блок памяти. Для того чтобы обеспечить сохранность данных, они всегда хранятся сразу в двух узлах. Из-за ошибки при проведении апгрейда трафик пошел не в первичную сеть, а во вторичную, не рассчитанную на такие нагрузки. Это, в свою очередь, привело к тому, что узлы EBS утратили связь друг с другом и начали искать новые «партнерские узлы» для репликации данных. Это и вызвало своеобразную цепную реакцию зеркального резервирования, которую представители Amazon назвали «зеркальным штормом» («re-mirroring storm»).  

Источник:

• pcworld.com

Доступ к популярным сайтам, таким, как Quora и Reddit, был затруднен или полностью заблокирован 21 апреля из-за проблем с серверами в центре обработки данных Amazon,  обслуживающем сервисы хостинга компании. Amazon начала сообщать о проблемах на своей информационной панели Service Health Dashboard около 5.00 по восточному времени. В 5.16 сайт Amazon сообщил, что проблемы со связью влияют на  службу Relational Database Service, которая используется для управления реляционными базами данными в облаке через множество зон в восточной части США. Amazon также сообщила о проблемах с Elastic Compute Cloud (EC2), сервисом, обеспечивающим вычислительную мощность в облаке, и с Elastic Block Store (EBS), системой хранения данных для сервиса EC2.

«Сетевое происшествие этим утром запустило большой объем повторного зеркалирования томов EBS на US-EAST-1, — сообщила Amazon в 11.54 утра. — Это повторное зеркалирование создало дефицит мощности в одной из зон доступности US-EAST-1, что повлияло на  создание новых томов EBS, а также на темпы, с которыми мы могли бы повторно зеркалировать и восстановить пострадавшие тома EBS». Компания также заявила, что один из его внутренних уровней управления EBS стал перегруженным, и поэтому создание новых томов и сохраненных экземпляров EBS стало затруднительным. «Мы работаем так быстро, насколько это возможно, чтобы добавить мощности в эту зону, и ускорить повторное зеркалирование. Также мы работаем по устранению проблемы c уровнем управления, — добавила компания. — Мы начинаем видеть успех этих усилий. Мы будем сообщать новости по мере их поступления». Проблема имела некоторые широкомасштабные последствия, особенно для некоторых популярных Web 2.0 сайтов, таких как Quora, HootSuite, Foursquare и Reddit.

Источник:

• pcworld.com