Минимизируйте время простоя в Azure - PullRequest
4 голосов
/ 09 декабря 2010

Сегодня мы испытываем очень серьезное незапланированное время простоя нашего приложения Azure, которое сейчас составляет до 9 часов.Мы сообщили в службу поддержки Azure, и оперативная группа активно пытается решить проблему, и я не сомневаюсь в этом.Нам удалось запустить наше приложение на другом «тестовом» размещенном сервисе, который у нас есть, и перенаправить наш CNAME, чтобы он указывал на экземпляр, чтобы наши клиенты были довольны, но «основной» размещенный сервис по-прежнему недоступен.

МойСобственный инстинкт "пальца в воздухе" заключается в том, что проблема связана с сетью в нашем центре обработки данных (западная Европа), и, действительно, позже в тот же день панель индикаторов обслуживания стала красной для этого региона с сообщением об этом.(Наше приложение отображается как «Здоровое» на портале, но недоступно через наш URL-адрес cloudapp.net. Кроме того, потоки в нашем приложении регистрируют исключения подключения SQL в нашей учетной записи хранения, поскольку оно не может связаться с БД)

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

Я бы хотелспросите сообщество, есть ли что-нибудь, что я мог бы сделать лучше, чтобы избежать этого простоя?Я повиновался руководству относительно наличия по крайней мере 2 экземпляров ролей на роль, но я все еще был сожжен.Должен ли я перейти на более надежный центр обработки данных?Должен ли я развертывать свое приложение в нескольких центрах обработки данных?Как бы я справился с тем фактом, что моя БД SQL-Azure находится в том же центре обработки данных?

Буду признателен за любое конструктивное руководство - будучи технарем, у меня никогда не было такого разочаровывающего дня, когда я мог ничего , чтобы помочь решить проблему.

Ответы [ 4 ]

7 голосов
/ 10 декабря 2010

В европейском дата-центре произошел сбой в работе SQL Azure.Некоторые из наших клиентов пострадали и были вынуждены перейти в другой центр обработки данных.

Если вы используете критически важные приложения, которые не могут быть недоступны, я бы развернул приложение в нескольких регионах.Разрешение DNS, очевидно, сейчас является слабым звеном в Azure, но его можно обойти (если вы только запускаете веб-сайт, это можно сделать очень просто с помощью Response.Redirects или аналогичного)служба от Microsoft, которая будет синхронизировать несколько баз данных SQL Azure.Отметьте здесь .Таким образом, вы можете создать зеркальные сайты в разных регионах и синхронизировать их с перспективой SQL Azure.

Кроме того, рекомендуется использовать стороннюю службу мониторинга, которая обнаруживала бы проблемы с развернутыми экземплярами извне., AzureWatch может уведомить или даже развернуть новые узлы, если вы решите, когда некоторые экземпляры перестанут "Не отвечать"

Надеюсь, это поможет

1 голос
/ 03 июня 2012

Я могу предложить некоторые рекомендации, основанные на нашем опыте:

  1. Разместите ваше приложение в нескольких центрах обработки данных, в комплекте с базами данных Sql Azure.Вы можете подключить каждое приложение к своему Sql-серверу для своего центра обработки данных.Вы также можете кэшировать любые внешние ресурсы (изображения / JS / CSS) на компьютере Windows Azure, предназначенном для центра обработки данных, или использовать хранилище блогов Azure.Примечание. Дополнительные расходы будут понесены.
  2. Настройка односторонней репликации SQL между вашей основной БД Sql Azure и экземпляром в другом центре обработки данных.Если вы хотите выполнить двунаправленную репликацию, посмотрите руководство на сайте MSDN.
  3. Используйте диспетчер трафика Azure для маршрутизации трафика в ближайший к пользователю центр обработки данных.Он обладает возможностями геообнаружения, которые также улучшат время ожидания вашего приложения.Таким образом, вы можете перенаправить карту http://myapp.com на внутренний URL-адрес вашего центра обработки данных, и пользователь в Европе должен автоматически перенаправиться в европейский центр обработки данных и наоборот для США.Примечание. На момент написания этого поста не было способа автоматически обнаружить центр обработки данных и перейти на другой ресурс.Шаги будут выполняться вручную, как только обнаружится аварийное переключение, и аварийное переключение станет полным набором (то есть вы переключите как экземпляры Windows Azure, так и Sql Azure).Если вы хотите аварийного переключения на микроуровне, то я предлагаю поместить все ваши настройки в файл конфигурации службы и зашифровать значения, чтобы вы могли редактировать строку подключения для подключения экземпляра X к БД Y.
  4. Все готовосейчас.Я бы создал или установил локальное приложение, чтобы определить доступность сайта.Лучшим решением было бы создать страницу для проверки доступности компонентов приложения, написав страницу диагностики или веб-службу, а затем опросить ее с локального компьютера.

HTH

0 голосов
/ 10 декабря 2010

При развертывании в Azure у вас мало контроля над настройкой SQL-сервера.MS уже настроила его так, чтобы он был высокодоступным.

Сказав это, похоже, что у MS были некоторые проблемы с SQL Azure в течение последних нескольких дней.Нам сказали, что это затронуло только «небольшое количество пользователей» .В какой-то момент на служебной инструментальной панели возникла проблема с 5 центрами обработки данных.У меня было три базы данных в одном из этих центров обработки данных дважды в течение примерно часа каждый раз, но одна база данных в другом центре данных затрагивала работу без перебоев.

Если подключение к базе данных является критически важным для вашего приложения, тоединственный способ в среде Azure избежать проблем, против которых MS не подготовилась (эта последняя техническая проблема, землетрясения, удары метеоритов), - это разместить данные sql в другом центре обработки данных.На данный момент наиболее практичным способом сделать это является использование synch framework .Существует возможность копировать базы данных SQL Azure , но это работает только в центре обработки данных.С вашими данными, расположенными в другом месте, вы могли бы затем направить свое приложение на новую базу данных, если основная станет недоступной.

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

(я бы опубликовал этот ответ по вине сервера, но не смог найти вопрос)

0 голосов
/ 09 декабря 2010

Это просто проблема программирования / архитектуры, но вы также можете задать вопрос на webmasters.stackexchange.com

Вам необходимо выяснить причину, прежде чем делать какие-либо выводы.

Тем не менее. мое предположение одна из двух вещей была проблема

  • Подключение провайдера отличается для тестовой системы и вашей производственной системы. Либо они используют разных провайдеров, либо разные линии от одного и того же провайдера. Когда я работал в хостинговой компании, мы позаботились о том, чтобы через IP-соединение проходили как минимум два разных ISPS, которые не разделяли оптоволокно с нашими помещениями (и, где мы могли, у них были разные физические маршруты к зданию - возможность возврата в обратном направлении, когда есть критический кусок волокна, чтобы выкопать это хорошо доказано

  • В вашем центре обработки данных возникла проблема с некоторой общей производственной инфраструктурой. Это могут быть граничные маршрутизаторы, межсетевые экраны, балансировщики нагрузки, системы обнаружения вторжений, формирователи трафика и т. Д. Как правило, они также часто устанавливаются только в производственных системах. Защиты здесь подразумевают понимание архитектуры и обеспечение того, чтобы у провайдера был (протестированный!) План аварийного восстановления для восстановления НЕКОТОРЫХ сервисов, когда дела идут в паре. Самым неприятным взломом, который я здесь увидел, было убеждение IPS (системы предотвращения вторжений) в том, что его собственные серверы управления являются вредоносными. И поэтому вы вообще не могли его перенастроить.

Просто мысль - ваш DC не содержит ни одного из зеркал Wikileaks или Paypal / Mastercard / Amazon (которые получают DDOS от сторонников wikileaks в данный момент)?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...