У нас есть серверы приличного размера: несколько ProLiant, плюс IBM BladeCentre и SAN, на которых работает среда VMWare. Из-за неизбежного переезда помещения у нас не будет достаточно места для серверной, поэтому я подумывал о том, чтобы переместить все в коло. Моему боссу больше нравится идея облачного хостинга всего, что будет включать в себя пару веб-сайтов с высоким трафиком (около 9 миллионов просмотров страниц в месяц), наш сервер Exchange (около миллиона чистых писем, отправляемых / получаемых ежемесячно), а также файл / печать / AD / все обычные вещи. Мне это не кажется хорошей идеей, но я новичок в способах использования облака. Кто-нибудь может дать совет?
Здесь недостаточно подробностей. При использовании облачного хостинга следует подумать о следующих проблемах:
Проблемы с конфиденциальностью / владением - это нормально, что кто-то другой владеет вашими данными? Подразумевается, что в настоящее время (как и телефонная компания или любой другой поставщик услуг), если для этих данных будет выдана повестка в суд, у вас нет права на уведомление или отмену ходатайства.
нет SLA производительности - Хотя есть SLA, доступные для доступности, я не знаю ни одного поставщика облачных услуг, который предоставляет SLA производительности
Стоимость - очень обычно TCO (от самого дешевого до самого дорогого) - это отдельный хостинг, размещение в одном месте, VPS, облачная среда. Из каждого правила есть исключения, но для внутренней инфраструктуры я еще не видел рентабельного облака.
У облака есть одна реальная привлекательность, и это плата за то, что вы используете, в сочетании с нулевыми расходами на развертывание / предоставление. Для лабораторий, серверов, которые создаются и уничтожаются быстро и часто, вы не можете превзойти облако.
Облачный хостинг, как правило, очень гибкий - это множество способов в зависимости от провайдера. Если вам нужен сервер большего размера, вам, как правило, придется самостоятельно добавить оборудование или даже переключиться на другое устройство для серьезных изменений. В облачном хостинге это обычно делается через простой интерфейс, а изменение размера может занять от нескольких минут до нескольких секунд в зависимости от системы.
Изначально облачный хостинг был разработан для обеспечения высокой доступности, поэтому в случае отказа оборудования время простоя будет очень небольшим - обычно менее минуты в зависимости от системы. Однако сегодня он обычно очень масштабируемый и является отличной альтернативой выделенным серверам.
Облачный хостинг может стать дорогим при модели с оплатой по мере использования, поэтому вам обычно нужно покупать пакет, заключать какой-то контракт или резервирование по более низким ценам. Вы, возможно, захотите изучить два конкретных хоста, которые предоставляют очень удобные услуги:
Я ничего не могу сказать о совместном размещении, так как я не работал с физическими серверами, поэтому вы можете изучить другие ответы для получения информации по этому поводу.
вы можете изучить гибридное решение. Размещение крупных веб-сайтов в облаке может работать, так как вы можете увеличивать и уменьшать масштаб в зависимости от трафика.
Обмен и т. Д., Вы, вероятно, захотите оставить на складе.
Основным преимуществом облака для веб-хостинга является масштабируемость, и вам не нужно беспокоиться о том, что вам придется ехать в коло для замены неисправного HW. Просто удалите узел, установите новый и добавьте его в свой балансировщик нагрузки.
Мое мнение, учитывая, что я не могу знать все факты о вашей конкретной ситуации:
Если вам предстоит неминуемый физический переезд, то вы абсолютно точно не хотите перенести свои системы на другие платформы в неизменный крайний срок, когда вам придется находиться вне помещения. Во-первых, что-то с большей вероятностью пойдет не так под принуждением, а во-вторых, если возникнут проблемы и временные рамки упадут (а когда этого не произошло?), Вы в конечном итоге переместитесь на полпути в процессе миграции, и вам по-прежнему потребуется пространство в центре обработки данных для твой комплект. Звучит как дорогой рецепт к катастрофе, а не как элегантная панацея, позволяющая сэкономить на затратах и хлопотах, которую должно обеспечить облако. Нет, определенно не смешивайте два проекта в один подобным образом, если вы можете этого избежать.
Облачный хостинг (в том смысле, что, как я подозреваю, это видит ваш начальник) - это здорово и имеет свое место, он может хорошо подходить для того, чем вы занимаетесь. Но сейчас я думаю, что у вас достаточно проблем с необходимостью перемещения вашей инфраструктуры. как есть, поэтому я хотел бы дать отпор вашему боссу четким сообщением, что вы не можете просто выбросить все оборудование и системы в мгновение ока, но что переход на облачный хостинг по крайней мере для части вашей инфраструктуры действительно может быть осуществим, поскольку Ваш следующий большой проект, после того, как пыль осядет из переезда помещения.
По поводу самого «Облака». Вы уже используете локальное / внутреннее облачное решение - вашу среду VMWare / SAN. Если вы переместите это в размещенный центр обработки данных, где вы просто арендуете стойку и продолжаете управлять своим собственным комплектом, теперь у вас есть удаленно обслуживаемое частное облачное решение.
Многие нетехнические боссы живут за счет модных словечек, и облачные вычисления не являются исключением (на самом деле, на данный момент это, вероятно, самый большой преступник в категории «чушь бинго»). Вы можете использовать это в своих интересах и направить дела в более разумном направлении, связав то, что вы уже делаете (запускаете виртуальную среду), с представлением вашего начальника об облаке. Это может быть так же просто, как называть ваши виртуальные машины «экземплярами», а хосты ESX - «узлами» всякий раз, когда вы сообщаете об этом.
А как насчет сплит-модели? Я бы использовал облачный источник для моего веб-хостинга, но не для моей инфраструктуры LDAP, Exchange и т. Д. Внутренние приложения являются индивидуальными. Что касается Co-Lo, я бы рассмотрел возможность переноса части моей избыточности в CoLo (например, некоторые из моих серверов AD; если у вас три DC, я бы переместил один в CoLo, но если бы у вас было больше , Я бы хотел отправить более высокий процент в CoLo), но это полностью зависит от вашей инфраструктуры. Если вы используете ESX и V-Motion, возможно, стоит иметь возможность использовать их для аварийного переключения в случае проблем с сайтом. Это может помочь с вашей проблемой перегрузки, если у вас нет места для все вашей текущей инфраструктуры.
Меня больше всего беспокоит то, что я считаю неудачным менеджментом. Планируемый переезд объекта, но они не смогли спланировать соответствующее пространство для инфраструктуры ?! В самом деле?! Если это не было попыткой подтолкнуть кого-то к аутсорсингу (который вопиет о политических манипуляциях), навязывание проблемы подобным шагом просто безответственно.
мы перемещаем большую часть наших «менее используемых» данных в облако для резервного копирования и обеспечения устойчивости / аварийного переключения. Наши основные данные или критически важные данные размещаются локально, и даже некоторые из них автоматически синхронизируются с облачным хранилищем, так что мы можем иметь полный отказ оборудования и по-прежнему иметь возможность работать с облачными данными с некоторой задержкой.
Мне нравится объяснять эту идею, как вы делаете хранилище / память на обычном сервере / ПК.
То же самое касается локального и облачного хранилища, разделите данные / хранилище на группы по приоритету:
Но я хочу сказать, что не думайте, что одно решение подходит для каждой проблемы. Гибридные комбинированные решения - это то, что вам нужно.
Я лично выбрал среду облачного хоста на данный момент - Amazon AWS, но, возможно, стоит обратить внимание на Microsoft Azure - Amazon по-прежнему лидирует. Google Apps Engine тоже интересен, но я бы пока не стал раскрывать важные производственные данные.