После недавнего отключения электроэнергии мы пересмотрели вопрос о том, как наиболее эффективно предоставлять, обслуживать и поддерживать наши ИТ-ресурсы.
Мы обдумывали одну идею - переместить некритическую инфраструктуру в облако. Например, мы могли поддерживать только следующие услуги на территории кампуса:
...и это все. С таким планом, даже в случае бедствия, мы просто сосредоточимся на поддержании подключения к Интернету, и все наши другие услуги будут по-прежнему доступны.
Я искал Amazon EC2, но пока ни к чему не привязан. Как другим колледжам или компаниям удалось сделать что-то подобное? Есть ли «ловушка» или препятствие, о котором мы должны знать? Существуют ли какие-либо блоги / форумы, в которых можно подробно описать миграцию в облако на уровне предприятия?
Возможные уловы / препятствия:
Пропускная способность: Когда вы говорите о переносе ресурсоемких сервисов, таких как базы данных и файловые серверы, за пределы площадки, вам нужно внимательно посмотреть на то, насколько толстый канал вам понадобится для поддержания существующего уровня производительности. В зависимости от типа учреждения, которое вы представляете, у вас может быть или нет гигабитный или 10-гигабитный оптоволоконный кабель в вашем кампусе. Если вам нужна гарантированная пропускная способность и вы можете позволить себе вложения, частное подключение через AWS Direct Connect может быть что-то рассмотреть.
Задержка: У ваших пользователей могут быть приложения, управляемые базой данных, которые делают умные вещи, например, выполняют несколько запросов на лету для заполнения раскрывающихся списков (хуже всего, если они работают с файлами .mdb вместо серверов SQL). Или у них может быть общий файловый ресурс Windows, содержащий 10 000 документов Word со стратегическими названиями, и просмотр может внезапно занять минуты, а не секунды. Эти проблемы можно устранить только частично гарантируя, что у вас есть чистое соединение с вашей размещенной средой с малой задержкой / низким уровнем дрожания. Однако окончательным решением является использование приложений, которые должным образом разработаны для облака (например, Google Apps вместо MS Office или веб-интерфейс базы данных вместо базы данных Access).
Стоимость: Вам нужно будет тщательно оценить, сопоставима ли стоимость аренды виртуальных серверов со стоимостью обслуживания вашей локальной инфраструктуры. Существует множество переменных, от капитальных затрат до электроэнергии и затрат на техническое обслуживание, и все они должны быть учтены при сравнении яблок с яблоками. Не забывайте, что EC2 выставляет счет за исходящую пропускную способность, и что сервисы, которые традиционно работают «локально», могут потреблять ее очень много.
Надежность: Ваше подключение к Интернету более надежно, чем существующая серверная инфраструктура? Если нет, сколько избыточности вам нужно добавить и какой ценой? Как сбой EC2, подобный тем, которые произошли в апреле и августе 2011 года, повлияет на вашу работу?
Мне очень нравится EC2 для аварийного восстановления, но я всегда скептически отношусь к переносу на него больших частей инфраструктуры. Что мне действительно нравится в EC2, так это DR - копирование всего критического. Если вы действительно заложите основу для планирования, вы можете разместить свои операционные системы на EC2 и локально. Если в вашем ИТ-здании возникнет великолепный пожар, вы можете включить несколько экземпляров EC2, перенаправить свой DNS и начать обслуживание. Красота в том, что в автономном режиме они не стоят ничего, кроме статической платы за хранение.
Если вы действительно все делаете правильно, вы можете включать системы в любом месте по мере необходимости. Это также позволяет вам свободно экспериментировать и легко использовать наименее дорогие системы.
Где ты в университетском городке, ты можешь пойти действительно большой с тактикой DR. Я не знаю его семантики для работы с Amazon, но многие колледжи используют адресное пространство класса B. Вы можете исключить маршрут BGP для класса C, который зарезервирован для зеркальных служб. Если ваш веб-сервер находится в этом адресном пространстве, все, что находится в кампусе или напрямую подключено, будет маршрутизироваться на компьютер кампуса, и все, что находит Amazon ближе, направится туда. (по состоянию на март 2010 года это было невозможно. Это было очень востребовано, и, возможно, сейчас это возможно, а может и нет.). Фактически, вы можете установить это строго в кампусе без маршрутов BGP, если сосредоточитесь только на своих внутренних таблицах маршрутизации.
Несомненно, это добавляет сложности, но определенно сделает вас очень устойчивым.
Первичный веб-сервер, старый веб-сервер, сервер Moodle, сервер Mahara, серверы VoIP, сервер печати, файловый сервер, сервер Wordpress, веб-сервер студента, два сервера баз данных и два сервера SharePoint. Если увеличение задержки при перемещении серверов VoIP в облако неприемлемо, его также необходимо будет разместить на месте и считать «критически важной» инфраструктурой. В противном случае в идеале это была бы еще одна вещь, которая «просто работает», пока мы поддерживаем это Интернет-соединение.
Рассмотрим следующее как пункты дальнейшего обсуждения; здесь нет конкретных ответов, просто вещи из моей головы, о которых вам следует подумать и обсудить со своими сверстниками:
Вероятно, вы можете исключить VoIP, а также сервер печати и файловый сервер из облака. Я подозреваю, что задержка для VoIP была бы неприемлема без большого количества работы. Тем не менее, ваш провайдер телефонной связи / SIP может предложить собственную услугу, на которую стоит обратить внимание. Файл и печать, вероятно, связаны с устаревшим программным обеспечением (например, для управления изображениями), которое для правильной работы полагается на скорость / задержку LAN. Я уверен, что вы столкнетесь с рядом проблем, если рассмотрите это дальше.
Базы данных могут быть в порядке, но опять же задержка может быть неприемлемой для приложений, которые их используют.
Веб-серверы, вероятно, будут нормально работать в облачной среде (Wordpress, Moodle и т. Д.), Но если они зависят от основных сервисов, которые на данный момент находятся только в сети кампуса, вам нужно будет посмотреть на репликацию или безопасный удаленный доступ к этим службам (что вам все равно придется делать в форме частного облака и туннелирования VPN).
И большое ошибочное название облака состоит в том, что люди ожидают, что их программное обеспечение и сервисы будут вести себя по-другому только потому, что они находятся «в облаке», когда, если ваш стек сервисов не был оптимизирован для использования преимуществ распределенной архитектуры, предлагаемой облаком, вы столкнетесь с единым точки отказа, когда экземпляр выходит из строя.
Конечно, всегда есть лицензирование программного обеспечения, которое может создавать или не создавать дополнительные препятствия.
И, очевидно, существует конфиденциальность информации и защита указанной информации, которая может существовать, а может и не существовать в этих некритических сервисах, что может вызвать у вашего юриста беспокойство.
И вам все еще нужно улучшить восстановление / непрерывность ваших основных сервисов: это настоящая основная проблема, не так ли? И добавьте к этому тот факт, что ваши основные сервисы теперь будут включать избыточное, приоритетное, высококачественное подключение к Интернету, потому что без этого ваши облачные сервисы фактически бесполезны.
Объем работы, просто определяющий, являются ли какие-либо из этих «некритичных» сервисов (и это может быть некритичным для вас, но для другого отдела, может быть их наиболее важным; соглашения об уровне обслуживания могут быть здесь полезны. если у вас их еще нет) будет успешным кандидатом в облако нетривиально.
Хорошо то, что вы будете проводить полноценную инвентаризацию / обнаружение вашей ИТ-инфраструктуры (что всегда полезно), чтобы определить, что вы можете или не можете делать (или, по крайней мере, пилотировать). А поскольку вы тратите деньги только на плату за время выполнения в облаке, ваш пилотный проект не требует больших денежных затрат.