Назад | Перейти на главную страницу

Несколько физических серверов Linux DB и среда приложений: необходимо ли жить рядом с центром обработки данных?

При наличии физической серверной среды целесообразно ли жить в том же крупном городе, что и центр обработки данных, даже если есть более выгодные варианты центров обработки данных на другом конце страны?

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

Я планирую развертывание приложения в центре обработки данных примерно с дюжиной физических хостов Linux (и еще больше), каждый с определенными ролями сервера базы данных с использованием локального хранилища, резервного сервера базы данных или сервера приложений. Машины будут совместно использовать VLAN и использовать хранилище второй линии DAS для архивирования. Виртуализация не планируется, за исключением, возможно, нескольких резервных ролей, которые сильно не используют физическую машину.

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

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

Подводя итог, можно сказать, насколько выгодно проживание рядом с хорошим центром обработки данных в крупном городе при запуске подобного развертывания? Перевешивает ли это преимущества лучшего / лучшего центра обработки данных в еще более крупном городе?

Спасибо, что поделились своим опытом в этой области.

Джефф

Во-первых, я делаю пару предположений о ваших потребностях. Я предполагаю, что общедоступное облако типа EC2 не является жизнеспособным подходом, и что ваше приложение не будет хорошо работать в двух центрах обработки данных. Отсутствие привязки к одному центру обработки данных дает ряд существенных преимуществ, а также некоторые значительные затраты. Не зная больше о вашем приложении, я не могу сказать, какое из них будет более актуальным, но следует иметь в виду: если у вас есть возможность переключиться на другой центр обработки данных, странные проблемы, на устранение которых требуется время, не так уж и важны.

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

Разница между поддержкой, которую мы получаем в каждом месте, - это день и ночь. С удаленным сайтом, который находится поблизости, гораздо сложнее иметь дело, чем с сайтом на другой стороне США, и все дело в поставщиках и уровнях поддержки. Я понимаю, что вы спрашивали о colo, а не об управляемом хостинге, но я все еще думаю, что это актуально. Обычные удаленные руки - это не то, что вы хотите попробовать для устранения чего-либо более сложного, чем "перезагрузка сервера". С другой стороны, хорошие инженеры центров обработки данных будут намного лучше решать сложные проблемы. И с похожими уровнями поддержки на бумаге эти два провайдера ОЧЕНЬ разные на практике.

Независимо от того, у кого вы принимаете гостей, если вы выберете архитектуру, знакомую персоналу, вы получите лучшую поддержку. Период. Вот почему у большинства поставщиков управляемых файлов Colo есть определенные дистрибутивы и т. Д., Которые они поддерживают. Конечно, никто не будет поддерживать или знать само ваше приложение. Это не их отдел, это ваш. Задача центра обработки данных - предоставить платформу и поддерживать ее работоспособность. Если под нагрузкой возникают странные проблемы с сетью, они должны их исправить независимо от того, где вы находитесь.

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

И, наконец, самое главное - это конкретные поставщики. Поговорите с другими их клиентами. Если можете, начните медленно и почувствуйте, как они работают.

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

Расходы на удаленные руки не совсем обычные так высокий, что вы хотите отправить инженеров, особенно с такой небольшой инфраструктурой, которую вы предлагаете (если вам нужно установить или обновить 50 модулей, может быть экономически выгодно отправить инженера)

Конечно, вместо этого вы можете думать о клиенте. Кто заказчик? Будет ли на них влиять задержка?

Если у вас есть веб-сайт с региональной ориентацией, кажется хорошей идеей разместить его рядом с регионом, чтобы получить лучшую задержку, но с другой стороны, задержка может быть довольно приемлемой, если он находится на том же континенте, что и большинство ваших пользователей. (подсказка: не используйте хосты APAC, если ваши пользователи находятся в Северной Америке или Европе!)

В конечном итоге вы знаете свой бизнес и приоритеты намного лучше, чем мы; таким образом, только вы можете оценить компромиссы. Если бы это был я, я бы определенно не располагал одним из моих серверов дальше, чем в 3 часах от меня, но это потому, что я не могу оправдать оплату 80 долларов в час за руки на месте. Опять же, если бы вы знали, что сэкономите достаточно (назовем это 20% затрат на хостинг), и уверены, что не будете сжигать столько в удаленных руках, тогда у вас есть ответ.

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

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

Все это предполагает, что ваши основные проблемы с оборудованием (надежность, мощность, HVAC, резервное копирование, землетрясение, наводнение и т. Д.) Равны или лучше в удаленном объекте.