Lord British
1) Балансировка нагрузки/масштабируемость сервиса. Хочется сервисную часть (морда, api) крутить на несколких серверах. Соединения к которым разбрасываются каким-нибудь балансировщиком аппаратным или программным. Кто в теме как это обычно выглядит? Хочется по единому DNS имени попадать на один из серверов эдакого HA (high avail...) кластера, прозрачно дщля пользователя. Т. е. его перекидывает балансировщик сам.


Хмм... Ну вот так, как Вы описали, так и делается:-) В принципе, можно вообще сделать чисто на уровне TCP/IP. Например, не секрет, что одному имени DNS не обязательно должен соответствовать один адрес. Ну вот хоть yandex попробуйте попинговать и посмотреть на IP-адреса. Ну или nslookup глянуть на ту же тему. Но это такой вариант не очень, если у Вас цель HA кластер.
Можно использовать специальный софт какой-нибудь. К примеру,
Apache .

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

Lord British
2) Балансировка нагрузки/масштабируемость БД. Что лучше применить? Шардинг какой-нибудь дикий с репликациями? Или кластер предлагаемый той или иной СУБД. Рассматривается использование Oracle или MS SQL.

Спасибо. Буду рад любой информации.

Есть опыт работы с Oracle RAC. Реально решает такую задачу. Единственно что, это совсем не то, что просто на одну машину - и ставиться сложнее и поддерживать сложнее и информации/специалистов меньше. Плюс по-любому тогда нужен SAN. Про MSSQL не знаю, но думаю, что хуже будет, из общих соображений. SAN все равно нужен будет.

i,

А морда?

iHaueri,

А морда?

WCF = SOAP. Морда может быть любой

Ну так о том и вопрос, кто будет балансировать нагрузку на морду. Или считается, что морда нисколько не нагружается?

Lord BritishHauer

Есть опыт работы с Oracle RAC. Реально решает такую задачу. Единственно что, это совсем не то, что просто на одну машину - и ставиться сложнее и поддерживать сложнее и информации/специалистов меньше. Плюс по-любому тогда нужен SAN. Про MSSQL не знаю, но думаю, что хуже будет, из общих соображений. SAN все равно нужен будет.



У меня был опыт установки Oracle RAC на виртуалки с общим виртуальным хранилищем. Примерно представляю как выглядит. Но к сожалению в продакшне никогда не видел. Работал только со standby/primary. Но это больше относится ко времени восстановления. Кроме того, полагаю, что необходимо придерживаться некоторых требований при написании приложения, чтобы не завалить этот кластер (использование последовательностей например...). Если поделитесь соображениями по этому поводу буду признателен.

Да нет, особых требований никаких к приложениям нет (с чего бы быть каким-то проблемам с последовательностями?). Stanby/primary это все-таки не совсем то, мне кажется. RAC состоит из ноудов, которые в принципе равноценны. Т.е. обращение целиком к кластеру, точно так же. как и к одному серверу (connection string только отличается).

DPH3При средней доходности системы платежей, в масштабах города Oracle RAC, скорее всего, выйдет за пределы бюджета.

Собственно, я про RAC только исходя из:

Lord British
Рассматривается использование Oracle или MS SQL.


А так, конечно, это огромная нагрузка на бюджет. Хотя.... Местами Oracle может проявить гибкость в плане лицензирования, мне думается.

DPH3,

Я видел и 70 на не таком уж большом заказе. Но это вариант типа "всё или ничего", т.е. берите 200К и давайте нам, что мы хотим или вообще ничего не купим.