В том случае, когда вся инфраструктура располагается локально, тест критически важных систем происходит регулярно, и в зависимости от результатов руководство принимает решение о покупке нового железа или апгрейде старого. Но как быть, если инфраструктура арендуется в облаке, особенно если вопрос касается не слишком прозрачных значений, таких как скорость дисковой подсистемы? И что значит, если результаты тестирования показывают, что система хранения данных в облаке работает медленнее, чем домашний ноутбук? Разложим все по полочкам.
Для начала давайте расставим точки над i. Большинство крупных сервис-провайдеров, предоставляющих в аренду виртуальные мощности, используют самые продвинутые программные и аппаратные решения для построения собственной инфраструктуры. Разумеется, это относится и к СХД (система хранения данных). Так почему же диск в домашнем компьютере при тестировании может выдавать более высокий результат, чем промышленная система хранения данных за десятки тысяч долларов? На самом деле ничего удивительного в этом нет. Основным параметром оценки скорости дисковых подсистем является IOPS (операции ввода/вывода в секунду) при фиксированном значении latency. Заказчик получает ровно то значение данного параметра, которое прописано в договоре с сервис-провайдером. Разумеется, в зависимости от потребностей скорость может быть увеличена в любой момент за дополнительную плату. Стоит отметить, что любая современная СХД может быть гораздо выше решений для домашнего использования.
Сервис-провайдер в первую очередь должен гарантировать непрерывность работы и выдавать стабильные показатели быстродействия, зафиксированные в договоре, а не обеспечивать максимальные значения в пике.
Давайте разберемся, насколько действительно важна скорость работы дисковой подсистемы. Разумеется, речь идет о тех показателях быстродействия, которые превышают средние значения, необходимые для стабильной работы приложений. Нормальное функционирование приложения гарантируется в облаке по принципу must have. Тут важно понимать, что сервис-провайдер в первую очередь должен гарантировать непрерывность работы и выдавать стабильные показатели быстродействия, зафиксированные в договоре, а не обеспечивать максимальные значения в пике. Ведь на самом деле тестирование скорости дисковой подсистемы в облачной инфраструктуре на максимальные значения IOPs чаще всего не имеет смысла. Тому есть несколько причин:
Причина 1. Результат тестирования и реальная работа приложения – разные вещи.
Это действительно так. В конечном итоге целью тестирования является определение, насколько текущее аппаратное решение подходит для работы сервисов и приложений. Чтобы это выяснить, самым действенным методом будет запустить приложение и посмотреть, как оно работает при различной нагрузке. А тестирование систем хранения данных используется скорее для сравнения самих этих систем. Дело в том, что IOPS – это по сути показатель скорости записи/считывания блоков данных в секунду. Но ведь даже в рамках одного приложения величина таких блоков может быть разной в зависимости от того, какая часть программы выполняется в данный момент. Не говоря уже о том, что существует несколько типов операций помимо записи и чтения, а также параметр Latency (задержки), без которого значение IOPS не несет никакой смысловой нагрузки. На этом фоне результаты подобного тестирования выглядят очень относительными и вряд ли отражают картину целиком.
Причина 2. Вы сами решаете, какое количество IOPS указывать в договоре.
При заключении договора вы согласовываете с сервис-провайдером параметры производительности, в которые помимо процессорной мощности, объема оперативной и физической памяти входит, разумеется, и число IOPS. Таким образом, если вы знаете, какие показатели вам действительно необходимы, вы гарантированно получите их. Стоит отметить, что тут важную роль играет рентабельность, поскольку чем выше быстродействие, тем дороже услуга.
Причина 3. Стабильные показатели быстродействия важнее пиковых.
Для сравнения скорости локальных жестких дисков и системы хранения в облаке чаще всего берутся максимальные значения IOPS, что в корне неверно. В большинстве случаев приложениям важен стабильный и предсказуемый уровень производительности на долгий период, а не возможность в какой-то отдельный момент выдать сверхрезультат. Учитывая все это, можно с уверенностью сказать, что сравнивать результаты тестирования таких показателей, как IOPS, в облачной и локальной инфраструктуре имеет смысл только при наличии стопроцентной уверенности в чистоте теста и с учетом многих нюансов. А делать выводы относительно некорректной или медленной работы приложений по вине скорости СХД следует в самую последнюю очередь, после того как проверены все другие возможные причины.
Локальный диск действительно может выдать большую скорость при тестировании, но в боевых условиях от него будет сложно получить такой же уровень надежности и производительности на длительный период времени, как у СХД.
В заключение можно сделать вывод, что сравнение скорости диска локального ПК и СХД в облаке вряд ли можно считать честным, так как это решения разного уровня, которые выполняют разные задачи. С одной стороны, локальный диск действительно может выдать большую скорость при тестировании, но в боевых условиях от него будет сложно получить такой же уровень надежности и производительности на длительный период времени, как у СХД. С другой стороны, промышленные решения для хранения информации, реализованные в инфраструктуре сервис-провайдера, могут обеспечить не только надежность, но и высокую скорость, если это действительно необходимо заказчику и он готов к дополнительным тратам.
