Я разработчик, привыкший тестировать и отлаживать код.
Иногда мне приходится вносить изменения в конфигурацию нашего балансировщика нагрузки. Насколько я понимаю, если я испорчу это, это может остановить работу всего сайта, но у нас нет возможности протестировать его в автономном режиме.
Как люди тестируют такие вещи? Я надеялся, что появится какой-то эмулятор, который я смогу использовать. Или есть возможность получить вторую конфигурацию для тестирования?
Я хотел бы быть так же уверен в изменениях, которые я вношу в балансировщик нагрузки, как в изменениях, которые я вношу в свой код. Есть ли у кого-нибудь набор тестов, который они используют для тестирования своего балансировщика нагрузки?
Обновить
Мы находимся в процессе перехода от одной серверной части к другой, и мы перенаправляем пользователей на основе URL-адреса.
В идеале у вас должен быть F5 BigIP в вашей (производственной параллельной) промежуточной среде. Это позволяет вам тестировать новую конфигурацию, версии кода, функции и т. Д., Не влияя на производство.
Предполагая, что это невозможно из-за стоимости или других ограничений, следующей лучшей альтернативой будет второй набор сервисов QA или UAT, настроенных для работы с теми же внутренними серверами, что и производственные, но только имеет небольшую часть пользователей, нацеленных на него.
Не зная больше о своей конфигурации, трудно быть более конкретным. Можете ли вы предоставить более подробную информацию о том, как вы используете свой балансировщик нагрузки и какие изменения вы планируете внести?
ОБНОВЛЕНИЕ: исходя из вашего пояснения, кажется, вы хотите проверить свою способность переключать пользователей между одним набором внутренних серверов и другим, и что вы маршрутизируете запросы пользователей на основе URL-адреса, к которому они обращаются? (Переключение контента).
Если вы не можете позволить себе другой балансировщик нагрузки в производственной среде, я бы предложил настроить новую службу с использованием тестового URL-адреса и пересылать запросы на этот URL-адрес так же, как вы это делаете в настоящее время в производственной среде. Убедившись, что эта тестовая служба работает в соответствии с производственной программой, вы можете изменить политику, связанную с тестовым URL-адресом, для перенаправления на новый сервер. Это должно подтвердить, что ваша конфигурация Big-IP верна.
(Приносим извинения за отсутствие образца конфигурации, я сам не работал с балансировщиками нагрузки F5, только с другими поставщиками.)
Вы можете получить ограниченную по времени (и с некоторыми функциональными возможностями) виртуальную версию LTM, которая будет работать в vmware:
Или тестовый виртуальный сервер на производственной единице (ах) - хорошая альтернатива.
Другие балансировщики нагрузки предлагают функциональность, аналогичную F5, а их поставщики предоставляют более полезные варианты тестирования и разработки.
Вы можете получить лицензию на разработку Zeus Traffic Manager (полная функциональность) или лицензию Citrix VPX (только стандартная версия), обе ограничены пропускной способностью 1 Мбит (чего должно быть достаточно для большинства целей разработки) и действительны в течение 1 года.
Zeus будет ежегодно бесплатно продлевать лицензии на разработку (не знаете, что будет делать Citrix?)
Аарон - ни при каких обстоятельствах тестовый виртуальный сервер на производственной единице не является хорошей альтернативой!
Я делаю это, настраивая вторую виртуальную машину (или набор виртуальных машин), которая сопоставлена тем же пулам. Затем вы можете протестировать промежуточный VIP, отредактировав файл / etc / hosts (или файл хостов Windows).
Здесь я буду восхвалять своего внешнего поставщика DNS, Dynect (http://dynect.com). У них есть функция управления трафиком, которая позволяет добавлять как старые, так и новые виртуальные IP-адреса в ротацию имен хостов, но также настраивать вес - соотношение частоты обслуживания старого и нового IP-адресов, а затем вы можете медленно увеличивать вес. мигрировать, если жесткое переключение слишком рискованно.
Что касается внутреннего DNS, я считаю, что GLB F5 может делать то же самое (но не цитируйте меня, поскольку у меня здесь нет практического опыта).
Первый ответ - наличие тестовой среды.
Я рекомендую автоматизировать тестирование с помощью любого инструмента для внедрения сценариев HTTP.
Затем возникает вопрос, как поддерживать синхронизацию ваших сред, и я рекомендую отказаться от ручной настройки производственной среды из интерфейса администратора.
Предложения по автоматизации настройки BigIP методом DevOps:
iApp создано F5 https://clouddocs.f5.com/api/iapps/
Ansible модули https://www.ansible.com/integrations/networks/f5
Ресурсы Terraform https://www.terraform.io/docs/providers/bigip/index.html
создать свой собственный iApp
Или приложения курса, созданные из iApp (либо из F5, либо из вашего собственного), должны быть развернуты благодаря Ansible или Terraform.
На момент написания этой статьи ни модули Ansible, ни ресурсы Terraform еще не охватывали все объекты конфигурации BigIP.