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

Готовы к запуску: виртуальный выделенный сервер или облако?

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

Я не могу использовать общий хостинг, потому что мне нужен больший контроль над сервером (по техническим причинам - например, с использованием проприетарных расширений для PHP, Apache, а также на уровне базы данных), но я хочу контролировать расходы и не хочу использовать полностью частный маршрут сервера , пока мы не определим размер рынка и т. д. Итак, единственная реальная альтернатива AFAIK - это между виртуальным сервером и облаком.

На данный момент облачные сервисы кажутся мне немного «расплывчатыми». Насколько я понимаю, они позволяют организации передавать свою ИТ-инфраструктуру на аутсорсинг, которая, на мой взгляд (по крайней мере), неотличима от того, что предоставляет хостинг-провайдер (по крайней мере, с функциональной точки зрения) - я хотел бы получить некоторые разъяснения по в чем именно разница между ними.

Возвращаясь к моему первоначальному вопросу, мои требования:

  1. ИТ-инфраструктура, которая может масштабироваться с ростом
  2. Возможность управления машиной (например, для установки наших библиотек собственной разработки и т. Д.)
  3. Программное обеспечение резервного копирования, которое является достаточно гибким и всеобъемлющим (но простым в использовании), что позволяет реализовать (защищенную) стратегию резервного копирования. По этой проблеме мне всегда было интересно, где хранились фактические резервные копии данных (поскольку физические машины являются удаленными, и нельзя получить доступ к каким-либо реальным лентам и т. Д., На которых была сделана резервная копия). Я также хотел бы получить несколько советов и рекомендаций в этой области. Что касается размера данных, я ожидаю, что набор данных будет увеличиваться на несколько мегабайт данных (первоначально, скажем, 10 МБ, примерно через год, возможно, 50 МБ) каждый день.

Кстати, я решил развернуть его на сервере Debian (большинство моих дополнительных библиотек и т.д. были скомпилированы и построены на машине Debian).

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

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

Облачные сервисы основаны на идее «виртуализированного центра обработки данных», проданной нам 10 лет назад.

Облачный хостинг (обычно) - это просто виртуальная среда частного сервера, за исключением того, что вы можете быстро предоставить дополнительное оборудование в любой момент. Amazon EC2, например, просто предоставляет вам часть сервера, использующего Xen (хотя иногда это довольно неплохой кусок, если вы готовы за него заплатить), который вы загружаете вместе с образом виртуальной машины, который храните в S3.

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

Помните, что облачные сервисы не нужны для масштабирования.

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

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

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

Некоторые облачные провайдеры «упрощают» процесс, предоставляя вам меньше контроля.

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

Надежность имеет значение

Все виртуальные серверы работают на обычном серверном оборудовании. Если основной компьютер загорается, виртуальные серверы умирают так же быстро. Однако большинство облачных провайдеров также предоставляют SAN для вашего постоянного хранилища. Стоит отметить, что при правильном управлении сеть SAN значительно более надежна, чем жесткий диск с одним сервером, и ее можно быстро назначить другому серверу, если у вас возникнут проблемы с вашей текущей машиной. Это также намного дороже за байт.

Так что...

Выделенный - это самый простой способ, который определенно дает вам максимум ресурсов за деньги. Кроме того, он наименее гибкий. Традиционные VPS дают меньше, но должны стоить меньше.

Что касается резервного копирования: в rsync нет ничего плохого - это основа для большинства инструментов резервного копирования. Добавьте жесткие ссылки для снимков, и у вас есть реальное решение.

Я предполагаю, что вы имеете в виду облачные службы Amazon (EC2, S3, EBS и т. Д.) Или аналогичные, поскольку облако - это большой расплывчатый термин, которым может быть практически любая служба в Интернете.

Что касается Amazon по сравнению со стандартным VPS, большие различия заключаются в следующем:

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

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

Оборудование на лету
Amazon создала API и инструменты для управления различными услугами, которые у них есть, чтобы вы могли управлять ими программно. Если вы правильно спроектируете свое приложение для горизонтального масштабирования (управление общими сеансами, балансировщики нагрузки и т. Д.), Вы можете запустить минимальный блок по умолчанию, а затем в зависимости от времени суток, загрузки системы, одновременных пользователей и т. Д. Добавьте больше блоков в смесь.

Это отличный способ сэкономить на хостинге в зависимости от модели использования вашей аудитории. Например, допустим, у вас нагрузка с 10:00 до 16:00 с понедельника по пятницу, то есть 6 часов в будний день, а в остальное время - произвольный доступ.

Если вам нужна большая коробка для этих 6 часов и работает она круглосуточно, вы потратите 0,34 доллара в час * 24 часа * 30 дней = около 245 долларов в месяц (с некоторыми дополнительными расходами на хранилище, пропускную способность и т. Д., Но почасовая - основная часть стоимости).

Вместо этого, если бы вы управляли маленьким ящиком 24/7, а большой приходил, чтобы помочь в течение этих 6 часов, вы бы говорили 0,085 доллара в час за малый * 24 часа * 30 = 60 долларов плюс 0,34 доллара за час за большой * 6 часов * 20 = 40 долларов, что в сумме составляет около 100 долларов, что составляет менее половины 24/7 работы большой коробки.

Окружающая среда
Все они являются VPS (Amazon использует Xen в качестве гипервизора). Amazon только что создал этот интерфейс для управления сервисами, запуска вещей на лету, модульных сервисов и т. Д., Но машины по-прежнему остаются виртуальными машинами. Для вас нет разницы в настройке apache, поддержке патчей и т. Д. Будь то VPS, Amazon, облако Rackspace и т. Д., Вы по-прежнему будете использовать SSH на коробке и будете в полной среде Linux.

1: требуется облако.

2: нужна физическая машина или виртуальная машина

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

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

Облачные сервисы - это просто современное название того, что многие компании предоставляют в течение нескольких лет. Они пытаются абстрагироваться от предоставляемых ими услуг, чтобы вам не казалось, что вы имеете дело с физической инфраструктурой. Например, Elastic Compute Cloud от Amazon EC2 позволяет загружать несколько виртуальных частных серверов через их API, вместо того, чтобы заказывать новый VPS через продавца. Они также взимают почасовую оплату вместо ежемесячного или годового контракта. Это позволяет очень гибко программно управлять своими ресурсами. Например, вы можете ввести в эксплуатацию больше серверов, когда нагрузка высока, или когда вам нужен тестовый сервер, или загрузить 100 серверов, когда вам нужно обработать числа и списать их в тот же день для управления затратами. Облачное хранилище (например, Amazon S3) делает то же самое для хранилища. Гибкость работы с инфраструктурой как с потребляемым ресурсом - вот что делает «облако» таким привлекательным.

Чтобы ответить на ваши вопросы:

  1. Проще всего было бы начать использовать Amazon EC2 или Облачные серверы Rackspace, потому что, если вы можете настроить свое приложение так, чтобы оно было гибким, используя поставщика VPS, который может вводить в эксплуатацию больше или более быстрые серверы и взимать плату только за то, что вы используете, это упрощает контроль ваших затрат и по-прежнему предоставляет хорошие услуги, когда ваша популярность растет. . Если вам не нужна такая гибкость, вы можете попробовать Slicehost, обычный хостер VPS.
  2. Я бы определенно выбрал виртуальную машину из-за ее гибкости, как описано выше. Физическая машина будет рекомендована, если у вас высокие потребности в операциях ввода-вывода или вы не можете принять небольшие накладные расходы виртуальной машины.
  3. Большинство провайдеров могут предоставить какое-то резервное копирование для своих серверов. Вы также можете предоставить собственную резервную копию за пределами площадки. Я лично очень люблю Серверная версия Jungle Disk, который является доступным, безопасным и использует Amazon S3 или Rackspace Cloudfiles в качестве поставщиков хранилища. Фактически вы платите только за то, что используете, поэтому ваши расходы будут расти только при увеличении набора данных или периода хранения. Есть много предложений, так что не забудьте присмотреться к ним и проверить их требования. Резервные копии полезны только тогда, когда они доказаны.