Многие новые клиенты, когда начинают использовать CloudSigma, хотят протестировать производительность; они часто стремятся провести сравнительный анализ производительности облачных серверов и своей собственной инфраструктуры, и это вполне логично. Простое сравнение цен по ресурсам не дает полной картины; то, что действительно важно — это конечный результат: сколько стоит выполнение конкретной вычислительной задачи?
Для любых заданных требований количество ресурсов, необходимых для их достижения, может сильно различаться в разных облаках. Это означает, что простое сравнение цен не работает. Обратная сторона заключается в том, что сравнение производительности в отрыве от цен ничуть не лучше. Для содержательного сравнения необходимо объединить как цену, так и производительность, чтобы рассчитать некоторую меру стоимости единицы вычислений. В этом посте я собираюсь поделиться своими мыслями по поводу тестирования производительности наших и других облачных серверов. Я также дам несколько советов по получению полезных результатов и тому, что они на самом деле означают.
Предупреждения
Сразу поясню: я довольно скептически отношусь к тестированию производительности в целом. Оно редко дает реальное представление о практическом использовании. Короче говоря, ничто не заменит запуск реальных приложений, которые вы планируете использовать на платформе. Если вы можете сделать это с разумными затратами времени, то альтернативы такому подходу просто нет.
Еще один фактор — это загруженность облачного провайдера. Вы можете протестировать облачные серверы и получить отличные результаты. Однако это может быть в значительной степени связано с уровнем использования (или его отсутствием) у конкретного провайдера. И это не обязательно положительный знак. Это может отражать трудности в работе, потерю клиентов, прошлые проблемы с доступностью и надежностью и т. д. Поэтому при интерпретации результатов тестирования всегда следует изучать историю сбоев и других потенциальных проблем облачного провайдера.
И последнее предупреждение: производительность — не единственный фактор, который следует учитывать. Часто более низкая производительность может отражать более надежную (и избыточную) аппаратную архитектуру, лежащую в ее основе. Поэтому всегда важно четко понимать, на какой инфраструктуре построено облако. Таким образом, вы сможете справедливо сравнить результаты, что позволит вам принять взвешенное решение о покупке.
Определение задачи
Далее в этом посте я изложу различные аспекты производительности и то, как лучше всего интерпретировать результаты. Однако перед проведением любого тестирования важно охарактеризовать тип вычислений, которые вы планируете выполнять в облаке; это определит относительную важность различных показателей производительности. Например, если вы хотите разместить сервер базы данных, который будет находиться под высокой нагрукой на чтение, но низкой на запись, вам следует обратить внимание на производительность дисков в облаке, особенно на произвольное (непоследовательное) чтение.
Поэтому, прежде чем приступать к тестированию облачных серверов, четко сформулируйте, что именно вы будете считать хорошей производительностью облака. Вам следует определить, какие аспекты являются ключевыми и оказывают наибольшее влияние на реальную производительность ваших вычислений. Как только у вас появится четкое представление об этом, вы сможете приступить к тестированию.
Вычислительная производительность
Когда мы оцениваем чистую вычислительную производительность, речь идет о процессоре (CPU) и оперативной памяти (RAM). Различия в производительности на чисто вычислительном уровне между облаками на самом деле не так велики. Однако существуют некоторые факторы, которые вызывают реальные различия.
Безусловно, самым важным фактором, влияющим на вычислительную производительность в облаке, является конкуренция за ресурсы. Публичные облака — это мультиарендные среды. Оперативную память и хранилище невозможно перераспределить сверх лимита (хотя их можно перепродать), но процессорное время (CPU) перераспределять можно и это делается. Уровни конкуренции значительно различаются, но, по сути, провайдеры публичных облаков могут продавать процессорную мощность физического хоста более чем на 100%.
Некоторые из крупнейших провайдеров используют коэффициент переподписки процессора более чем в три раза. Это означает, что общая ‘проданная’ мощность процессора всех виртуальных серверов на одной физической машине может в три раза превышать ее фактическую мощность. Они делают это потому, что большинство виртуальных серверов большую часть времени не используют выделенные им ресурсы процессора даже на 100%. Тем не менее, коэффициенты переподписки напрямую влияют на результаты тестов производительности облачных серверов и их реальное использование. Если переподписка высока (т. е. превышает выделение ресурсов процессора более чем на 200%), производительность облачного сервера значительно снизится.
Проще говоря, если нагрузка на любую физическую машину превышает 1 на ядро, вычислительные задачи ставятся в очередь, и время, необходимое этой виртуальной машине для завершения работы, увеличивается. Учитывая, что большинство облаков взимают плату на основе почасовой мощности, это напрямую влияет на расходы клиентов этого облака.
Другим важным фактором, влияющим на вычислительную производительность, является количество процессорных ядер, к которым имеет доступ виртуальная машина. Это важно не для всех приложений, но многие современные приложения поддерживают многопоточность. Фактически это означает, что приложение и/или операционная система способны распределять вычислительные задачи по нескольким ядрам. Отличный совет для повышения производительности ваших вычислений — сопоставить количество потоков (т. е. ядер), которые может поддерживать приложение, с количеством ядер, к которым имеет доступ виртуальная машина.
К сожалению, во многих публичных облаках это невозможно. Это связано с тем, что их платформы виртуализации не поддерживают виртуализацию на уровне ядер процессора. Другими словами, каждое ядро может использоваться только одной виртуальной машиной одновременно. В облаках, которые поддерживают виртуализацию ядер процессора, вам следует поэкспериментировать с изменением количества ядер для этой машины, сохраняя при этом общий объем процессора неизменным.
Например, если у вас машина с частотой 2 ГГц, вы можете посмотреть, как удвоение используемых ядер с двух до четырех повлияет на результаты тестирования. Благодаря этому приложения, запущенные на этой виртуальной машине, смогут выполнять задачи через четыре ядра одновременно. В нашем случае вы можете настроить количество ядер, используемых виртуальной машиной, на вкладке ‘advanced’ в модальном окне сведений о сервере в веб-консоли. Только не забывайте всегда проверять стандартную частоту ядра облачного провайдера перед тем, как вручную перезаписывать количество используемых ядер. В нашем случае она составляет 2,2 ГГц на ядро, но она варьируется от облака к облаку.
Я бы рекомендовал рассмотреть возможность использования POV-RAY, CoreMark, Dhrystone или Whetstone для тестирования производительности облачных серверов.
Storage: the real cloud servers performance benchmark
Вся производительность ограничена самым слабым звеном, где возникает «узкое горлышко». В настоящее время технологии значительно продвинулись в области виртуализации в отношении использования процессора и оперативной памяти. Например, одна физическая машина может быть виртуализирована и содержать несколько облачных серверов с минимальными потерями для общей совокупной производительности. К сожалению, в случае с хранилищем предстоит проделать еще огромный путь. Конечным результатом является то, что в большинстве случаев производительность виртуальных серверов в облаке определяется производительностью решения для хранения данных этого облака.
Короче говоря, хранилище в настоящее время является ограничивающим фактором для производительности большинства вычислительных задач в облаке. Какие бы результаты ни показывали pov-ray и другие тесты для чисто вычислительных задач, реальность такова, что скорость, с которой виртуальный сервер может извлекать и записывать данные на физические диски хранения, определяет реальную производительность облачного сервера на сегодняшний день.
С учетом этого, реальные различия в производительности в облаке, даже в отношении вычислительных задач, как правило, обусловлены различиями в производительности хранилища. Как упоминалось ранее в этой статье, потребности клиентов сильно различаются в зависимости от вычислительной задачи. И это особенно актуально для систем хранения данных. Нужен ли вам быстрый доступ на чтение к большим последовательным блокам данных (таким как потоковое мультимедиа) или к небольшим разрозненным фрагментам информации (возможно, в большой базе данных)? Нужно ли вам поддерживать высокую интенсивность записи для быстро меняющихся данных, доступ к которым осуществляется периодически большими всплесками? Существует множество сценариев, и каждый из них будет работать по-разному на одной и той же платформе.
Принципиально различия в производительности сводятся к архитектуре. Эти различия в архитектуре обычно обусловлены разной степенью надежности хранения данных, их избыточностью и, следовательно, вероятностью их безвозвратной потери. На высоком уровне облака используют либо централизованные решения для хранения данных в виде сети хранения данных (SAN) или более распределенных решений локального хранения. В них хранилище расположено на каждой отдельной физической машине.
Хорошие SAN изначально имеют высокий уровень встроенной избыточности. Однако производительность снижается, поскольку данные необходимо передавать из SAN по сети в процессор и оперативную память виртуальной машины для выполнения вычислительных задач. В результате облака на базе SAN, как правило, имеют более низкую производительность при прочих равных условиях по сравнению с облаками с локальными распределенными решениями для хранения данных. Еще одним недостатком SAN является то, что она представляет собой очень крупную единую точку отказа. SAN чрезвычайно надежны. Но если в их работе действительно произойдет серьезный сбой (а такое случалось), вы, скорее всего, столкнетесь с очень масштабным простоем и повреждением данных.
Большинство облачных провайдеров, использующих SAN, не применяют полностью избыточные отказоустойчивые решения того типа, которые используются в корпоративной среде, в основном по соображениям стоимости. Важно понимать, что не все SAN одинаковы, и выяснять у облачного провайдера, какой уровень избыточности они используют в своих SAN.
Облака на базе локальных хранилищ, как правило, имеют хорошую производительность дисков. Однако часто они предлагают локальное хранилище только в непостоянном виде. Это несправедливое сравнение с постоянным хранилищем. Временное хранилище не должно быть столь же устойчивым к сбоям, как постоянное. Для получения значимых результатов всегда важно сравнивать постоянное хранилище с постоянным.
При рассмотрении облаков с распределенными локальными решениями для хранения данных вам также необходимо знать, какую избыточность они обеспечивают. Жесткие диски выходят из строя с заметной регулярностью, поэтому метод хранения имеет решающее значение. Большинство провайдеров используют ту или иную форму RAID, но уровни безопасности сильно различаются. На начальном уровне вы получаете RAID1, где два диска по сути зеркалируют друг друга. Обычно это обеспечивает хорошую производительность. Но при выходе из строя одного диска, пока сменный диск копирует все данные со старого, данные подвергаются риску полной потери в случае отказа второго (сильно нагруженного) диска. Кроме того, во время любого восстановления массива RAID1 производительность дисков, скорее всего, будет намного ниже обычной.
Поэтому многие провайдеры используют RAID5 (устойчивый к отказу одного диска) или RAID6 (устойчивый к отказу двух дисков). RAID6 предлагает безусловно самое безопасное решение для локального хранения, но требует значительных жертв в плане производительности. Наш подход заключается в использовании RAID6, но в сочетании с первоклассными аппаратными картами RAID-контроллеров. Они имеют большой кэш памяти и оснащены резервными батареями. Используемые нами карты RAID-контроллеров на самом деле значительно дороже, чем все дисковые массивы целиком. Таким образом, мы можем обеспечить производительность, сопоставимую с гораздо менее отказоустойчивыми конфигурациями, при этом предлагая огромную сеть безопасности в виде хранилища RAID6. Узнайте больше о нашей облачной инфраструктуре и ее конфигурации, о которой мы рассказываем совершенно открыто.
Я рекомендую использовать IOzone или Bonnie++ для тестирования производительности дисков.
Итак, при интерпретации результатов тестирования производительности хранилища убедитесь, что у вас также есть следующая информация:
- какую архитектуру хранилища использует облако (локальную, SAN, другую)?
- какие меры по обеспечению отказоустойчивости и избыточности предусмотрены для данных?
- является ли хранилище, которое я тестирую, временным или постоянным?
Сопоставление ответов на эти три вопроса с результатами тестирования производительности даст вам достаточно хорошее представление о реальной производительности хранилища.
Сеть
Производительность сети определить и измерить значительно проще, чем вычислительную производительность и производительность дисков. Производительность сети имеет два ключевых аспекта: задержку и пропускную способность.
В зависимости от ваших потребностей задержка сети, используемой облачным провайдером, может быть важной или нет. Если вы используете облако для в основном автономных операций, маловероятно, что задержка будет приоритетом. Однако если вы запускаете приложения реального времени, которые взаимодействуют с внешним миром за пределами облака, то задержка будет критически важным фактором производительности.
Как правило, подавляющая часть задержки обусловлена исключительно физическим расстоянием. Например, большая часть задержки между Лондоном и Сан-Франциско — это фактически время, необходимое свету для преодоления этого расстояния. Различия в задержке определяются разной эффективностью выбранного маршрута. Это тот аспект, который отличается от облака к облаку. Эффективность маршрута напрямую зависит от сетевых провайдеров, к которым облако имеет прямое подключение. Это происходит либо за счет получения от них IP-связности, либо через пиринг. При оценке задержки вы можете просто отправить ping-запрос на свой облачный сервер и определить его производительность. Однако важно определить производительность между вашими реальными конечными пользователями и вашим облачным сервером.
Если большинство ваших пользователей находятся в одном географическом регионе или доступ будет осуществляться в основном из головного офиса вашей компании, важно протестировать производительность из этих мест. Коммерческие службы, такие как Pingdom предлагают экономически эффективный способ одновременного определения задержки из большого количества различных точек по всему миру.
Фактическая пропускная способность, которую может обеспечить ваш облачный сервер, также очень важна. В отличие от более традиционных хостинговых решений, облачные провайдеры, как правило, взимают плату в зависимости от совокупного объема передаваемых данных. Другими словами, оплата не зависит от времени, как при тарификации за Мбит/с, которая обеспечивает фиксированный уровень связи 24/7. Несмотря на это, многие облачные провайдеры будут ‘ограничивать’ пропускную способность любого виртуального сервера. Это будет незаметно для пользователя, пока вы не столкнетесь с этим барьером. Если у вас довольно неравномерный профиль использования полосы пропускания, это может стать важным фактором производительности, который необходимо учитывать.
Чтобы протестировать реальную пропускную способность вашего облачного сервера, важно попробовать загрузить данные на облачный сервер из источника, который на самом деле не ограничивает скорость передачи со своей стороны. Я часто нахожу, что отличный способ определить доступную скорость — это загрузить большой файл от крупного поставщика, такого как Microsoft, Ubuntu или, что еще лучше, путем обновления операционной системы. При этом обычно загружается множество различных файлов из разных мест одновременно. Это даст вам довольно хорошее представление о скорости вашего соединения.
В качестве стандартного теста я часто скачиваю Fedora live CD с их основного сайта, но вам следует как минимум поэкспериментировать с несколькими различными файлами и адресами. Если вам обязательно нужна собственная очень быстрая корпоративная сеть, то вместо этого вы можете в качестве теста загрузить файл со своего облачного сервера в свою собственную сеть.
Теперь добавьте цену обратно, чтобы взвесить результаты
Используя описанные выше методы, вы сможете получить хорошее представление о том, как работают различные провайдеры облачных серверов. Кроме того, вы будете знать, на каких аспектах следует сосредоточиться, которые наиболее важны для ваших конкретных потребностей.
Последний шаг — добавить ценовой аспект к результатам бенчмаркинга. Для этого нет готовой формулы. Это зависит от относительной производительности различных аспектов, описанных выше, и именно вы их определяете. Если одно облако обеспечивает на 40% лучшую производительность (по вашей оценке), но при этом стоит всего на 30% дороже, то оно явно выглядит привлекательным. Точно так же, если у вас высокая потребность в пропускной способности, более низкая вычислительная производительность может быть компенсирована выгодным тарифным планом на передачу данных. Ключ к принятию правильного решения — учесть все эти разнообразные факторы.
Наконец, бенчмаркинг должен быть частью более масштабного процесса определения того, какие облачные серверы подходят именно вам. Он должен включать и другие аспекты. Например, это могут быть соглашения об уровне обслуживания, вопросы привязки к данным или поставщику, физическое местоположение и правовая юрисдикция. Объединив все эти аспекты, вы’сможете сделать правильный выбор поставщика облачных вычислений.
Комментарии
Комментариев пока нет. Будьте первым.