`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Игорь Дериев

Проценты, в которые мы попадаем

+99
голосов

Вроде бы пустяк: очередной сбой Gmail. Хуже, когда под раздачу попадаешь именно ты. Печально, когда при этом вскрываются принципиальные недостатки.

Началось все с внутреннего письма нашего главного редактора, почему некоторые респонденты жалуются на невозможность отправить ему электронные письма. Жалуются, естественно, уже по другими каналам. Слава богу, их почтовые серверы отвечают нечто вроде «Recipient address rejected: Domain not found». По крайней мере наличие проблемы очевидно.

Почтовый домен ko.com.ua хостится в Google Apps. Локальные проверки ничего особого не показали, кроме того, что письмо с outlook.com шло более получаса. Ну, бывает. Тем более, что визуально вроде бы все работает.

Затем, ближе к вечеру выяснилось, что наш веб-мастер так и не получил отправленную мной публикацию. Причем, выяснилось случайно – к первому письму я забыл приложить файлы и оно как раз дошло. А вот следующее, с файлами (буквально через несколько секунд), уже где-то зависло.

Тогда уже заглянул в Интернет прицельно. Все сторонние, сервисы действительно сигнализируют о проблемах с Gmail:

Проценты, в которые мы попадаем

http://downrightnow.com/gmail

Проценты, в которые мы попадаем

http://downdetector.com/status/gmail

Но они основываются на жалобах пользователей, так что реальный масштаб проблем оценить сложно. А что нам говорят первоисточники? Не знаю, будет ли жива эта ссылка, поэтому сделаю копию:

Официальная хронология событий

Одно из первых сообщений: затронуто 0.024% пользователей. Но как же прицельно эта скромная цифра должна была наложиться на ko.com.ua! Впрочем, несколько часов спустя ситуация проясняется: «The email delays are affecting less than 50% of Gmail users». Приз за обтекаемость формулировки.

Буквально в момент написания этой строчки уже появилось сообщение, что проблема локализована и в пределах часа сервис будет (вероятно) восстановлен для всех пользователей. Собственно, в этом никто и не сомневался. Не впервые такое с Gmail, и Gmail не один такой. Из-за чего сыр-бор-то?

Меня, к примеру, неприятно удивила разница между распределенно-частной организацией электронной почты и интегрированно-облачной. Если локальные серверы исправно сигнализировали о проблемах с доставкой писем на Gmail, то внутри сервиса о них ничто не говорило. Т.е. как только письмо уходит из моего браузера, я полностью теряю над ним контроль. А как реагировать на молчание адресата? А как отреагирует он на мое?

И чем больше мы будем полагаться на облачные сервисы, тем больше, по-видимому, будет таких вот «черных ящиков». При этом архитектура сервисов и так уже сложна, но вынужденно будет еще усложняться. Трудно представить, к чему это может привести.

К счастью, здравый смысл еще существует. На недавнем киевском EMC Forum 2013 прозвучала такая оценка: даже в 2016 г. только 10% нагрузок будут крутиться в публичных облаках, а 78% в частных и 12% в виртуальных частных. И слава богу, если так.

+99
голосов

Напечатать Отправить другу

Читайте также

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

Категорически не согласен, что это проблема облачных вычислений.
Это следствие того, что Гугл это компания, фокус которой реклама.
И они против приватных и гибридных облаков.
Можно ли доверять рекламной компании так же как технологической типа IBM, HP, Microsoft?
Гугл заигрался в ИТ вот и все.

igor.palamarchuk@i-klass.com
facebook.com/igorpal

А книжной компании доверять можно? ;)
Т.е. вы полагаете, что в облаках Microsoft, HP и подобных все обстоит _принципиально_ иначе?

Может не принципиально, но немного честнее.

http://microsoftvolumelicensing.com/Downloader.aspx?DocumentId=6530

1) У меня тоже начала почта ходить с задержкой. Теперь буду знать причину.
2) Вы пишите что корень зла в облаке. Так поднимите свой почтовый сервер. Это не так долго и дорого. Думаете в этом случае получите в свои руки контроль за ситуацией? Не уверен. А вы?

2) "разруха - в головах". там же и корень любого зла :)
когда взаимодействуют несколько независимых серверов, они замечают проблемы друг у друга. в облаке почему-то не так: то ли архитектурные ограничения, то ли разработчики понадеялись что подобного не случится. но о невозможности доставить письма в течение нескольких часов конечно хотелось бы знать.

Вот виртуальная машина у вас на сервере, а вот у Майкрософта. Хоть убейте не понимаю в чем разница.
Если она есть - ставьте на свой. Что не так?

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

Если "виртуальная машина у вас на сервере", то когда падает сервер - падает ваша машина, а если она у Микрософта на сервере - она пинками перелазит на соседний хост.

Вот-вот. И какая-тогда претензия к облакам?

Кроме случая когда падает весь Azure.

Где гарантия что ваши инженеры лучше чем у MS?

Инженерам МС и самой МС в принципе-то наплевать на ваши проблемы и ваш бизнес, они рискуют только тем что вы не продлите контракт, то что вы из-за их проблем можете уложить свой бизнес на несколько дней или недель их абсолютно не волнует.

Это да. Но и Вася Пупкин тоже ничего не гарантирует. Вы пользовались нашими хостерами?

Я ничего не говорю о "хостерах", для них клауд это более чем адекватная замена, собственно это и все что клауд сейчас реально предлагает - замена традиционному веб-хостингу. Хотя тут тоже вопросы есть - я пользуюсь виртуальных хостингом с 2000 года и никаких отличий от того что сейчас называют клауд не вижу.

Я говорю о случаях когда нужно развернуть эксчендж на 10К+ пользователей или сиквелсервер, или еще какой бизнес-апп от которого зависит продуктивность бизнеса. Стандартные апачи с мускулями идит в клауд стройными шагами, все остальные строят свою частную инфраструктуру.

МС перенесла Скайп в облако. Эксчендж и сиквелсервер уже давно там.

Я не буду спорить, то что оно там есть и можно ли на него рассчитывать это совсем разные вещи. Попробуйте посидеть без почты 12 часов когда вам CIO каждые полчаса голову долбит и поймете.

Это реальный или гипотетический случай? По чьей вине?

Реальный. По чьей вине как вы думаете может потерять доступ к интернету весь клауд сайт ?

Зачем гадать? Это вы мне скажите

Поделитесь, пожалуйста, ссылкой на перевод Skype в "облако".

Спасибо за информацию. Правда вопросов появилось больше, чем ответов ... но это дело вторичное.

Я говорю о случаях когда нужно развернуть эксчендж на 10К+ пользователей или сиквелсервер, или еще какой бизнес-апп от которого зависит продуктивность бизнеса. Стандартные апачи с мускулями идит в клауд стройными шагами, все остальные строят свою частную инфраструктуру.

Ну да, конечно, Office365, Exchange online, Lync, Bing, Skype, Microsoft Store - не являются высоконагруженными системами, и от них не зависит продуктивность бизнеса владельцев. Куда им до ваших 30-40 стоек оборудования.
Облако проглотит ваши 10к мейлбоксов и не заметит.

И почему-то Яббл не строит свою инфраструктуру, а использует клауд для iCloud, например.

Спасибо за ссылку. Не знал

Не поверишь, у меня в датацентре прям в соседней клетке стоят Эксадаты и Эксалоджики Эппла, они второй крупнейший покупатель этого добра у Оракла после Сэйлсфорса. АйТюнс на них работают и Мапс. Так что не надо рассазывать о том чего не знаешь.

Сперва кричим "облака, облака", затыкая рты (общая тенденция в обзорах ИТ, упрек не автору) тем, кто указывает на объективные недостатки и описывает ....
А когда "в дупу клюнет жареный петух" и оказывается, что зависимость от "дяди" намного круче, чем предполагалось и эта зависимость уже начинает будет похуже "vendor lock-in", начинается "плач в жилетку".
Каждый выбирает свою судьбу сам и тот, кто разворачивает свои сервисы в облаке, должен понимать цену и осознавать все + и -. И помнить, что уровень доступности сервиса даже в Google ну никак не 100%, а не более 99,99%

эдвин, тут можно провести прямую аналогию - жить в собственном доме или арендовать, хранить деньги в своем кармане или в банке.
просто с ИТ-облаками мы в самом начале пути, а в них ломанулась уже хренова туча кастомеров. когда создавались первые банки, то к ним доверие масс приходило существенно медленее :)

Вот с банками аналогия как раз более подходящая. Противники облаков - это те кто держат деньги под подушкой, радетели за облака - это те кто несут деньги в банк...

Я знаю одно - после того как моя инфраструктура улетела в Azure, у меня перестала болеть голова что в УПСе надо батарею поменять, что кондиционер на выходных сдохнет ... и появился нормальный здоровый сон.

Если бы ваш бизнес зависил от, скажем, перформанса базы в клауде или необходимости иметь ее синхронную репликацию или гарантированную скорость доступа к сторэджу то сон бы вы как раз потеряли. Для "инфраструктуры" 2 апача и постфикс где нужно менять батареи в УПСе клауд самое оно, для вариантов с 30-40 стоек оборудования - не применимо в принципе.

Я не был бы столь категоричным - в нашем Облаке (De Novo) работает изрядное количество core-бизнес приложений, включая SAP, фронт-систему страховой компании, электронную торговую площадку (есть публичные пресс-релизы, их легко найти). А уж 1С, IT-предприятие, инфраструктура MS (включая SQL) - несть числа. Хотите попробовать под свои задачи?

1) Насколько ваши цены конкурентоспоcобны в сравнении с Azure например?
2) С паспортом к вам приходить или достаточно кредитки?

1) Прямое сравнение сделать трудно - у нас несколько разная структура сервисного каталога. Например, мы не предлагаем "инстансы" фиксированных размеров, мы предлагаем виртуальные датацентры (виртуальное частное облако) - ресурсные пулы, из которых сам клиент создает VM произвольной конфигурации, сети, сетевые устройства и т.д. Так что сравнивать можно только в контексте стоимости решения конкретной задачи (бизнес-кэйс). Уже просчитанные кэйсы показывают, что мы дешевле на 10-20%.

2) Мы работаем только с юридическими лицами, поэтому приходить с контрактом. Наше Облако не относится к классу публичных, это модель Trusted Enterprise Cloud и заточено оно под задачи корпоративного сегмента.

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

Ну, на нет и суда нет. А касательно DR я могу ответить на конкретный вопрос, ибо комментарии к статье не место для абстрактных рассуждений. Другими словами, прежде чем говорить о DR необходимо определиться с моделью угроз - от чего мы, собственно, защищаемся. Например, потеря сайта - это не угроза, а возможный результат срабатывания целого спектра возможных угроз. И от этого перечня в очень сильной степени зависят методы защиты (или же вывод о принятии риска).

Чушь. Потеря сайта это потеря сайта - пожар, метеор, маски-шоу, не важно. Важно что он не может дальше функционировать, полностью. Ну и ? Я так понимаю что бэкап у вас будет на ленте, есть куда эту ленту вставить ? Есть куда с этой ленты восстанавливать информацию ? Я не буду возиться с перенастройкой всех сетевых параметров каждой из сотен виртуальных машин, мне нужно чтобы оно все работало автоматом. Если мне нужна DR Exadata то эта Exadata должна стоять под парами и единственное что делать это реплицировать базу с прод системы. Это то что называется энтерпрайз-класс решения.

Собственно об этом то и речь - я могу полностью отключить питание на одном сайте и большинство моих пользователей ничего даже не заметят. Вы можете мне предложить подобный вариант ? Мне нужна синхронная репликация сторэджа с латентностью не более 4 мс, полное резервирование железа, фэйловер кластеризация плюс L2 сети, везде. Я более чем уверен что предложить это мне дешевле чем у меня уже есть вы не сможете.

Облака все это могут. А вот как вы все это организовали без облака я с удовольствием послушаю

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

1) Хорошо. Я отвечу за вас. У вас все стоит в одной комнате и достаточно простого перерезания кабеля чтобы все это накрылось медным тазом. Правильно?
2) Теперь облако. Извержение вулкана уничтожает датацентр в Ирландии - инстансы в Гонконге спокойно продолжают работать.
Где я не прав?

"Гладко было на бумаге, да овраги помешали" ... не стоит идеализировать поставщиков Cloud сервисов. Факт - самая упрямая в мире вещь. Знаменитое падение датацентра Amazon EC2 2011 года с простоем до 4-х суток - ни на какой резервный ДЦ работа не переместилась, убытками исчислялись круглыми суммами и т.д. показали, что маркетинг - это одно, а технологическая реальность несколько иное.

Это да. И Амазон платит за это своей репутацией. Ниже я писал про Васю Пупкина. Чем заплатит Вася Пупкин?

2) Теперь облако. Извержение вулкана уничтожает датацентр в Ирландии - инстансы в Гонконге спокойно продолжают работать.
Где я не прав?

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

1) А как у вас?
2) Ага

Совершенно не понятно, к чему ломаются копья.
Технологически все с-ва географического распределения и резервирования были до облаков. Вопрос синхронизации, распределения и т.д. - все это решалось и решается и прямого отношения к облакам не имеет. Разница в том, что без облаков для этого необходимо платить деньги грамотному человеку + решать вопросы организационного характера (где и как размешать или арендовать свои сервера и т.д.).
В облаках эти вопросы взяли на себя поставщики сервисов.

100500

"В облаках эти вопросы взяли на себя поставщики сервисов."

В том то и дело что они это на себя не взяли, вы просто предполагаете что они это сделали. Пример как крутится маркетолого ДеНово на вопрос о ДР более чем показателен.

Dain Bramaged, давайте осторожнее с ярлыками. Или хотя бы представьтесь, чтобы я знал кто на мои слова ярлыки вешает. Теперь по делу.

Потеря сайта с точки зрения управления бизнес-рисками - не первичная угроза, а результат. Поэтому прежде чем строить второй сайт как метод противодействия необходимо определиться против чего мы защищаемся и единственный ли это метод. Пример: есть понятие локальной катастрофы, когда действию деструктивного фактора подвергается одно или группа рядом стоящих зданий. Как правило, локальные катастрофы непродолжительны (до нескольких дней) и обратимы (длительное обесточивание, отказ системы охлаждения, локальное возгорание, маски-шоу). Со значительной частью этих угроз можно справиться без второго сайта - несколько периметров физической безопасности (не турникеты, бетонные стены с бронедверью), система раннего обнаружения угрозы возгорания (типа VESDA), дизель-генераторная станция без ограничения моторесурса и возможностью дозаправки "на лету" и другие. Все перечисленное и еще много чего реализовано в ЦОД, в котором размещено наше Облако. Поэтому локальная катастрофа, которая однозначно выведет из строя Ваш сайт, не является таковой для Облака. Надеюсь, я донес мысль.

Второй (а иногда и третий) сайты необходимы для противодействия региональным катастрофам, но их вероятность крайне невелика (типа Чернобыля), а социальные и экономические последствия столь велики (не до ИТ), что вопрос защиты от них поднимается только после того, как со всеми более вероятными угрозами разобрались и только после тщательного бизнес-анализа целесообразности такой защиты.

Из того что Вы перечислили - что-то можем, что-то не можем. Но это не имеет большого значения - это все инструменты, а не цель. Инструментами не торгуем. Мы продаем решения значимых бизнес-задач. В данном случае задача называется "непрерывность ИТ как часть непрерывности бизнеса". И ее мы можем решить. А конкретный болт с левой резьбой у нас может и отсутствовать - у нас не склад болтов.

В целом, мы оба правы, только с разных позиций. Просто Вашу логику чаще можно услышать из уст системного администратора, мою - CIO или COO. Целевой для нас является вторая группа, и именно на ее языке мы пытаемся говорить.

Потеря сайта с точки зрения управления бизнес-рисками - не первичная угроза, а результат.

Бла-бла-бла.

Все что вы написали можно было сказать одной фразой - ДР у нас нет, зато у нас есть вахтер и дизель. СОО счастливы, про ДР они никогда не слышали.

Аналогия неверна, ибо деньги, лежавшие дома, работы не делают.
Наиболее полная аналогия - это снимаете ли Вы квартиру, где все есть или живете в своем доме, где отвечаете за все сами.
Что выбрать, дело каждого.
Но суть моих претензий была не к самой технологии, а людям, которые сперва вешают "облака нас всех спасут" а потом смакуют новости "от сбоя сервиса компании ... пострадали ... человек"
(это не упрек автору, его упрекать не в чем, это общая картина публикаций).

затронуто 0.024% пользователей

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

О чем писать? Вася козел! А кто такой Вася?

Это я к тому что за каждый фэйл Гугл платит своей репутацией, а кого интересует репутация Васи Пупкина? Наоборот у него в резюме появится строка - адимнистрировал ko.com.ua
Вот такие пироги.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT