Предыстория: я пишу веб-приложение, которое будет доступно для всего мира в виде программного обеспечения как услуги. В качестве исходных данных для выбора платформы баз данных я читал о базах данных NoSQL, таких как Cassandra, Riak, MongoDB и Redis. Репликация, сегментирование и разбиение на разделы занимают важное место в наборах функций всех этих баз данных.
В конечном итоге я выберу один из них и продолжу разработку, но меня беспокоит то, смогу ли я реально использовать все преимущества сегментирования / распределения базы данных в производственной среде.
Я начинаю с одного человека с технологической инфраструктурой производства, состоящей из одного слайса SliceHost, на котором работает Centos. Я никогда не ожидаю, что у меня будет собственное серверное оборудование. Я просто хочу сейчас получить представление о том, к какой серверной архитектуре я мог бы двигаться, когда мой продукт станет исключительно успешным. :-)
Как люди настраивают кластеры серверов для поддержки своих изящных схем распределения баз данных NoSQL в среде VPS? В большинстве (во всех?) Случаях продукты баз данных рассчитаны на работу в частной локальной сети и, следовательно, не имеют механизмов аутентификации, которые необходимы для поддержки кластеров, охватывающих безумный мир Интернета. Как создать частную локальную сеть в «облаке»? Предлагают ли провайдеры VPS такие вещи? SliceHost, кажется, предлагает частные IP-адреса, но эти адреса доступны всем их клиентам; они не ограничиваются одним конкретным клиентом.
Прежде всего, не добавляйте высокомасштабируемые хранилища данных NoSQL прежде, чем вам понадобится такой уровень производительности. На начальном этапе разработки и пока у вас появятся первые несколько тысяч клиентов, вы, вероятно, сможете нормально работать с одной мощной базой данных SQL. Оставайтесь с проверенным решением, пока вам не понадобится больше; особенно если в вашей среде разработки приложений есть какой-то слой Object-Relation Mapper, который ожидает базу данных SQL.
Как создать частную локальную сеть в «облаке»?
Зависит от провайдера, стандартного решения нет. У некоторых провайдеров этого может не быть (вы упоминаете, что «частные» IP-адреса Slicehost доступны всем клиентам Slicehost).
Amazon EC2 имеет встроенный брандмауэр, называемый «группой безопасности».. По умолчанию только серверы под вашим контролем могут отправлять друг другу IP-пакеты; и вы получите детальное управление этими правилами. В чате поддержки Rackspace Cloud Server говорится, что их подключение к частной сети является частным для каждой учетной записи клиента (предположительно, это означает, что используется какая-то VLAN для каждого клиента). Другое хорошее Поставщики PaaS должно быть нечто подобное; в противном случае вы можете подумать о смене провайдера.
С провайдерами, которые не предлагают по-настоящему частные подсети, вы мог:
Это сработает. Но это увеличивает сложность, и IMHO сводит на нет большую часть простой подготовки дополнительных хостов (потому что, когда вы добавляете новый сервер, вам также необходимо изменить правила межсетевого экрана, чтобы разрешить новый «частный» IP). Простая подготовка действительно является ключевой частью того, что нужно от провайдера PaaS.
Вы бы не хотели, чтобы база данных была открыта для более широкого мира, независимо от ее типа, поэтому вам нужно ограничить подключения только теми хостами, которые авторизованы.
Я ничего не знаю о системах nosql, но поскольку вы планируете использовать серверы slicehost, было бы просто ограничить соединения с помощью iptables, чтобы соединения были явно настроены так, чтобы разрешать трафик только между собой (через их частные IP-адреса), таким образом устанавливая, какие суммы в вашу личную локальную сеть.
Я изучаю, можно ли использовать IPSec для того же сценария в нашем запуске. По сути, IPSec имеет этот подпротокол заголовка аутентификации, который может аутентифицировать данный IP-пакет в зависимости от того, совпадает ли его контрольная сумма md5 / sha-1 с payload + ip. Теперь поворот в том, что мы можем указать общий секрет, который также будет использоваться при вычислении контрольной суммы пакета. Если отправитель не знает секрет, он не сможет вычислить контрольную сумму, которая может быть проверена получателем, и поэтому пакет будет отброшен как поврежденный.
Фактически мы можем группировать узлы в локальной сети на основе общего секрета, и только внутригрупповые узлы могут отправлять IP-пакеты друг другу, решая проблему.