Я на 100% уверен, что я не первый, кто рассматривает возможность тестирования всей инфраструктуры, но все же я не нашел никакой соответствующей информации о том, как решить эту проблему.
Поскольку, я думаю, все мы знаем, о чем говорим, я постараюсь изобразить сценарий как можно короче.
Я много лет работаю в сфере хостинга, и мы всегда тестируем что-то новое. Еще в "чудесные годы" мы сделали несколько «ab», «dd» или «bonnie» и т. Д. Для тестирования диска, процессора и так далее.
Потом мы выросли, и нам нужно было протестировать наш коммерческий сайт или сайт какого-то крупного клиента. Мы перепробовали множество инструментов и в итоге получили такие вещи, как Jmeter, который долгое время был большим подспорьем. Недавно мы использовали Locust, отличный инструмент, не такой простой в настройке, но очень мощный.
Но теперь мы можем сказать: «мы достигли зрелости», мы продаем облако, и на карту поставлено гораздо больше, чем «группа веб-сайтов на веб-сервере».
Как облачный инженер вы разрабатываете решение для хранения, которое сможет разместить тысячи виртуальных машин (такой же сценарий и потребности применимы к другим вещам, например, к большим кластерам баз данных). Вы тратите дни на вычисления и предлагаете количество доступных виртуальных машин для выделенного вам бюджета. Мы все знаем, что будет дальше ... кто-то приходит и говорит ... ни за что ... мы должны влезть как минимум в два раза больше, мы должны зарабатывать деньги !!
Итак ... вы знаете, что невозможно уместить вдвое больше подсчитанных вами виртуальных машин, но вам нужно начать переговоры и предоставить менеджерам достаточно информации, чтобы прийти к соглашению, где-то посередине.
И вот в чем проблема ... как я должен протестировать всю инфраструктуру, которая может разместить тысячи виртуальных машин? Мы уже работали с инструментами нагрузочно-распределенного тестирования, такими как Jmeter или Locust. Они великолепны, но имеют одну большую проблему: они были разработаны для проверки одного IP-адреса, а не тысяч виртуальных машин.
Итак ... Я думаю, что многие пришли к этой ситуации только для того, чтобы понять, что нет никакого способа проверить это эффективно. Однако я уверен, что вы, ребята, в какой-то момент нашли способ протестировать подобную инфраструктуру более реалистичным способом, чем выполнение тестов старым способом. Буду признателен за любую идею, которую вы мне дадите.
Очевидно, вам нужна правильная архитектура и настройка, хорошее оборудование, ежедневное обслуживание и многое другое. Все, что мы можем сделать, чтобы очистить и обновить нашу систему, уже делается, но ... в какой момент мы должны прекратить вводить данные?
При подготовке новой системы мы делаем правильно:
иногда, просто взглянув на графики munin, можно увидеть некоторые возможные узкие места, но у нас были проблемы с сервисом с большим количеством менее активных виртуальных машин, чем порог предупреждения, который нам удалось определить во время тестов.
Итак, подытоживая, я знаю, что если бы кто-то нашел решение этой проблемы, его было бы очень просто найти на первой странице Google, но давайте посмотрим, есть ли у кого-нибудь стратегии для правильного тестирования некоторых небольших частей система.
Спасибо.
Я не эксперт, но сегодня читал об облачном тестировании, особенно отчет SPEC Open Systems Group: "Отчет об облачных вычислениях Руководящему комитету OSG". CBTOOL open-source от IBM кажется вам полезным. «Cloud Rapid Experimentation and Analysis Tool (также известный как CBTOOL) - это платформа, которая автоматизирует сравнительный анализ облака IaaS посредством проведения контролируемых экспериментов». Похоже, он специально тестирует подготовку виртуальных машин на различных облачных платформах.