Comments 13
Всю жизнь считал, что Service Time и Response Time это не одно и то же. В моем понимании Service Time это время, которое тратит конкретный HDD на обслуживание операции ввода/вывода. А значение Response Time = Service Time / (1 — процент утилизации контроллера), где Service Time = средне время поиска дорожки пишущей головкой HDD (Seek time) + время ожидания пока нужные блоки "довернутся" под пишущую головку HDD (Rotational latency) + время передачи данных от пишущей головки HDD к контроллеру HDD или в обратном направлении (transfer time). Исходя из соотношения выше, чем больше нагружен контроллер и чем выше значение Service Time, тем больше будет значение Response Time (вплоть до бесконечности). Так же из описанного выше понятно, что при использовании дисков с низкой скоростью вращения, время отклика будет выше, чем на дисках с высокими скоростями вращения. Косвенно отсюда же вытекает, то что задержки на SSD дисках многократно ниже, так как из уравнения исключаются Seek time и Rotational latency.
Service Time это время, которое тратит конкретный HDD на обслуживание операции ввода/выводаЕсли говорить конкретно об СХД, то ситуация намного более комплексная и одним диском там не обойтись.
Мы заметно реже имеем дело с живыми СХД, нежели с дисками из них, когда всё плохо и Service Time → ∞, и можем в полной мере оценить насколько мудрёные алгоритмы распределения данных там используются.
Нередко после долгого ручного анализа требуется писать кастомный софт под конкретную задачу, т.к. методики хранения тоже проприетарные и не документированы. Собственно поэтому восстановление данных с SAN традиционно является одной из наиболее сложных задач в отрасли.
Вы настолько путаете "теплое с мягким", что даже спорить желания не возникает.
Сильная аргументация, можете остаться при своем мнении.
Ну судя по тому что контраргуменов у вас не возникло, то ваше последнее утверждение близко к истине.
Если что, это был сарказм) Спорить с оппонентом, который без аргументов переходит на критику дело неблагодарное. А если по существу, то есть время обработки запроса носителем информации в составе СХД, и есть время обработки запроса всего СХД. И тут говоря про задержки на носителе, нужно упоминать носитель, и никакой путаницы не будет. Во многих СХД используются алгоритмы оптимизации, носитель уже передал данные в кеш контроллера, и только потом пришел запрос на чтение этих данных.
А простите, вы первый мой комментарий читали? Или проигнорировали?
А если взять в работу ваше последнее утверждение, то СХД должна просто состоять из кэша в оперативной памяти и видимо CPU. А это почему-то все еще не так, хотя к этому постепенно идет. А значит service time диска в принципе по физическим причинам не может равняться response time на сервере, где работает приложение, так то SAN тоже ни куда пока не делась со всеми ее компонентами. Но вы можете и дальше продолжать заново изобретать теорию построения своего велосипеда, игнорируя давно придуманное и устоявшееся. Прежде чем о чем-то спорить вы хотя бы с основами, теорией и устоявшейся в отрасли терминологией разберитесь.
Анализ утилизации СХД