Маршрутизация дилеммы в эластичной инфраструктуре веб-приложения мультиместоположения
Править: На самом деле, если это - просто существование или не "записи" в местоположении X в диапазоне целых чисел, Вы могли устранить хранилище данных и просто использовать битовый массив... Так, приблизительно 10 машин с 100 ТБ дискового пространства (таким образом, у Вас есть 10 копий Вашего битового массива для производительности и резервного копирования) и если Вы сделали 128 ГБ RAM на сервер, Вы могли бы соответствовать верхнему уровню высокого разрешения blockgroup индекс в памяти, чтобы сделать первую проверку прежде, чем поразить диск для бита X из 26 квадрильонов.
Я пошел бы для опции № 2, Если Вы берете:
375 машин с 64 ТБ (32 диска на 2 ТБ) каждый (реалистично 400 машин для отказов) затем просто отображает записи на ZVOLs, которые составляют 2 ТБ каждый. Затем на одном или нескольких индексных серверах, хранилище в массиве Judy или массиве critbit или просто побитово отображают, отображение того, если Вы добавили запись на то 1 из 26 квадрильонов мест. Индекс был бы между 50 и 100 ТБ, и у Вас мог даже быть второй индекс уровня indcating, если бы были какие-либо записи, записанные в определенный 64k блок адресов, которые поместились бы меньше чем в 64 ГБ RAM и обеспечили бы быстрый уровень начальной проверки, если бы определенное "окружение" было пусто или нет.
Затем для чтения той записи Вы сначала проверили бы, существует ли запись для нахождения путем рассмотрения индекса. Если существует, то перейдите к машине # (X)/ZOL # (Y) на том местоположении машины/записи # (Z) в том блобе на 2 ТБ на основе простого индексного вычисления. Единственные рекордные взлеты взгляда были бы чрезвычайно быстры, и Вы могли протестировать загрузку некоторых частей хранилища данных в другой dbs (в то время как Вы используете хранилище данных для реальной работы), и выполнение тестирования производительности, чтобы видеть, были ли они способны к поддержке Вашей целой базы данных - или нет, просто используйте хранилище данных тот путь.
ZOL является вещью ZFS, о которой можно было думать редкого файла в других файловых системах, таким образом, подобные вещи будут применяться. Или Вы могли просто индексировать к определенному числу байта на диске, но это становится хитрым, если диски являются различными размерами, если Вы не ограничиваете число байтов, используемых на диск на уровне, который работает на все диски - т.е. 1.75 ТБ на диск на 2 ТБ. Или создайте метаустройства, которые являются фиксированным размером и т.д.
Исходный NAT, к сожалению, самый простой вариант. В этом случае ASA преобразует входящие соединения, чтобы они выглядели так, как если бы они исходили из его локального интерфейса. Веб-сервер ответит на этот локальный трафик. Это даст вам полную симметрию на обратных маршрутах. Если вы отслеживаете трафик в журнале на веб-сервере, вам необходимо указать что-то другое, кроме IP-адреса источника - или, возможно, сопоставить журналы брандмауэра с веб-журналами. Это несколько болезненно, но будет (и масштабируется).
В зависимости от того, какой ASA у вас есть, вы также потенциально можете запускать их как пару актив-актив. В этом сценарии они будут разделять состояние и позаботятся о любой асимметрии. Для этого потребуется канал L2 между межсетевыми экранами и, если предположить, что два сайта имеют разные пространства DMZ, наличие одного и того же внешнего сегмента на обоих межсетевых экранах. В зависимости от того, как у вас настроена маршрутизация, это может быть довольно сложно, а также может выходить за рамки официальной поддержки. Если вы сможете заставить это решение работать, оно будет работать для двух сайтов.