Как приручить облака: примеры практического использования. Проблемы облаков

    Второй пост из серии авторских текстов Михаила Михеева "Как приручить облака: примеры практического использования".

    В первом посте я упоминал об основных плюсах облачной инфраструктуры, и обещал рассказать про минусы.

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

      Хорошая цитата:
    Облака и ERP
    Какие преимущества можно получить от использования “облаков” в процессе внедрения ERP системы. Команда внедрения приезжала и приблизительно оценивала потребности в железе – очень грубо оценивала. Дальше ИТ отдел заказчика начинал поиск под эту систему сервера (выбирали производителя, марку, договаривались о поставке). Чаще всего сервер приезжал не быстрее, чем через 2-4 недели, но нередко можно было ждать и пару месяцев. Параллельно решались вопросы с работой удаленных подразделений – или централизованный сервер и каналы связи, или варианты с распределенными базами (которые тоже требуют каналов связи). В то время, пока ждали сервер, система настраивалась или на некоем временном сервере (который уже старый, но еще жаль выбрасывать) или на компьютерах внедренцев (NAV и 1С живут на ноутбуке легко, Axapta с трудом, но тоже может работать – речь про OEBS или SAP не идет – рассматриваем внедрение в мелких или средних фирмах). Дальше два варианта – сервер есть к моменту запуска системы или его еще нет. Если есть, то после приезда сервера начинается процедура установки ОС и ERP, и выполняется настройка и перенос настроек (почти всегда требуется приезд ИТ-специалиста фирмы-внедренца). И дальше уже все настраивается на будущем рабочем сервере. Если еще нет, то система запускается на старом сервере, и через некоторое время, когда приезжает сервер, выполняется перенос (перенос работающей системы – удовольствие ниже среднего). До этого времени есть тормоза и прочие прелести старого железа. Также при начале работы у фирм, где есть удаленные подразделения, начинались различные проблемы, связанные с работой удаленных подразделений. Например, самая распространенная проблема – настройка принтеров при терминальном доступе к серверу. Кроме этого, различные глюки при настройке VPN и т.д. и т.п. – проблемы есть почти всегда. Разумеется, через некоторое время они решаются, но нервы помотают. Ну и в самом конце, примерно через полгода промышленной эксплуатации, выясняется фактическая нагрузка на железо. И в 99,9% случаев обнаруживается одно из трех – или сервер излишне мощный и не используется и на 25% (в пиковых нагрузках до 50%), или сервер в целом слабый и нужна более мощная модель, или не оптимальное соотношение процессор / память / дисковая подсистема (что-то мощнее, чем нужно, а чего то не хватает). Каким может быть аналогичный проект сейчас при использовании облаков (сloud computing)? (Как пишется в титрах некоторых фильмов, сюжет основан на реальных событиях )) …
    продолжение в первоисточнике
    • Сокращение (не увеличение) затрат на обслуживание (зп админов). Обслуживать не надо инфраструктуру нижнего уровня (серверное железо, системы хранения данных, сетевую инфраструктуру, ПО, которое можно назвать низкоуровневым – vSphere, брандмауэры, NAT и некоторые другие системы.
    • Отсутствие проблем с выбором конфигурации – уменьшить или увеличить выделенные приложению (ВМ) ресурсы тривиально.
    • Задешево обеспечение высокой доступности – банальные неприятности типа отказа железки (будь то железка серверной инфраструктуры, сети или системы хранения) не приводит к длительному простою (в каких-то случаях даже минимального простоя нет). Этот плюс, на самом деле, входит в однерку лидеров хит-парада причин выбрать облачную инфраструктуру.
    А теперь – минусы… Пронумерованы просто так, не по «страшности»
    1. Зависимость от канала связи.
    2. Зависимость от чужих студентов, админящих инфраструктуру.
    3. Зависимость от глобальных сбоев хостера (маски шоу, как самый популярный по некоторым данным disaster в наших широтах).
    4. Не любое ПО заработает в виртуальной машине.
    5. Конфиденциальность данных – лидер хит-парада страшилок.
    Разберем по пунктам.

    Проблема 1: зависимость от канала связи.
    Упал интернет между нами и ЦОДом облака – все. Тушите свет.
    Почему эта проблема не очень страшна:
    • канал падает, обычно, не часто. Впрочем, вероятность этого события для своей компании вы можете оценить и сами;
    • канал поддается резервированию, обычно;
    • если канал упал на нашей стороне (обычно падает не в ЦОДе облака и не у его провайдеров) – нормальная работа современной компании не возможна так и так. От вынесения части сервисов в облако хуже не будет, если это предположение верно для вашей компании. Более того, если к части сервисов обращаются извне (например, веб или почтовые сервера), вынос их во внешнее облако позволит получить большую доступность для внешних клиентов этих сервисов.

    Проблема 2: зависимость доступности нашей инфраструктуры от персонала хостера. Вдруг они наняли студентов, которые ничего не зная и не умея убьют наши виртуалки?!
    Нестрашность этой проблемы обосновать, наверное, легче всего. Бизнес сервис-провайдера корпоративного облака это доступность и еще раз доступность, любой простой — это потеря репутации и денег в виде штрафов, поэтому уровень мотивации в организации качества услуг существенно выше чем у внутренней службы ИТ.

    Проблема 3: зависимость от глобальных проблем хостера. А что если, например, к ним придут и унесут все железо?
    Тут нужно смотреть на конкретного сервис провайдера облачных услуг. Где он разместил свое оборудование, какой уровень физической безопасности дата-центра, есть например площадки куда и с решением суда не просто попасть. В частности облака ИТ-ГРАДа находятся именно в такой ЦОДе.

    Проблема 4: не любое ПО заработает в виртуальной машине.
    Если программа требует только процессор, память, диски, сеть, простейшую видеокарту и usb для периферии – все ок. Иначе – иначе. Грустно, но это так. С другой стороны, с этим легко можно не согласиться. «С этим» в смысле что это проблема. Серверных приложений, которым недостаточно того, что дают современные виртуальные сервера – мало. А старых приложений, которые сегодня не заработают нигде, кроме виртуальных серверов – как раз можно найти. К примеру, из опыта наших заказчиков — на данный момент, только благодаря средствам виртуализации VMware можно продолжать эксплуатировать ПО, которое работает, например, только по Windows 3.1.

    Проблема 5: конфиденциальность данных – их админы могут получить доступ к нашей информации.
    По уму, эту проблему стоит переформулировать: «Мы не хотим, чтобы конфиденциальность стала хуже после переноса сервисов из нашей серверной во внешний ЦОД».Далее ситуация разветвляется:а) или мы говорим о чувствительных данных, и говорим о конфиденциальности профессиональноб) или мы говорим в общем, и не профессионально.Первый случай – предмет отдельного обсуждения, итог которого можно втиснуть в рамки твита: «Действительно критичные с точки зрения конфиденциальности сервисы наружу не выносятся».А вот во втором случае – актуальном для большинства сервисов большинства компаний – остановимся чуть подробнее.          Вопрос: "А сейчас у вас как с конфиденциальностью?"          Ответ: "Как-то так?"Или вы можете дать более внятный ответ? Назначены ли ответственные люди? Приняты ли правовые, технические, организационные и психологические меры? Если ответ «нет», это значит что от администраторов внутренних компания не защищена никак, а вот с юрлицом – облакопровайдером – эта область может быть регламентирована намного, намного лучше.

    Резюмируем


    Вопрос: «После переноса сервисов в облако, станет ли хуже ситуация с конфиденциальностью наших данных?»
    Ответ: «Нет. Мы бы сказали, что станет лучше»Помните, в начале я написал фразу «Действительно критичные с точки зрения конфиденциальности сервисы наружу не выносятся»? Она не совсем корректна. Сегодня уже появляются специализированные для vSphere средства обеспечения безопасности, и под конкретные проекты они могут применяться, и применяться успешно. На текущий момент речь идет, преимущественно, о продуктах компании «Код Безопасности». Я к тому, что при экономических и\или прочих плюсах задействования внешнего облака под проект от идеи ни в коем случае не нужно отказываться из за наличия чувствительных данных – стоит поднять этот вопрос, изучить возможности и, часто, увидеть что с помощью специальных инструментов достаточный уровень конфиденциальности реализуем.Первый пост был посвящен введению в вопрос, были описаны плюсы в общем виде, и была поставлена задача – для иллюстрации возможностей. Сейчас мы поговорили о проблемах – и об их решении. Дальше мы вернемся к поставленной задаче – ведь надо ее решить...
    • +11
    • 7,7k
    • 1
    ИТ-ГРАД
    290,72
    vmware iaas provider
    Поделиться публикацией

    Комментарии 1

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

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

      Остается главная проблема: нет интернета — нет системы. Есть интернет, но медленный — аналогично.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое