Комментарии 127
Он нас всех посчитал!
+6
А можно промо код? :)
0
Сами потестировали, сам заняли первое место :)
+18
Сделали добротно, с учетом накопленного опыта и понимания особенностей облачных платформ, поэтому и результаты соответствующие.
0
Судя по вашему описания системы хранения, ваш результат тестирования — это результат кэша 96 Гб на файловом сервере. У трех машин диски по 15 Гб целиком укладываются в этот кэш и за счет короткого времени проведения тестирования, все данные в этом кэше являются горячими.
+9
Ключевой особенностью всех СХД является способ организации рейда и алгоритмы системы кэширования, диски-то все равно у всех одинаковые.
Данные являются горячими только для последовательных тестов. Время тестов с произвольным доступом на реально нагруженном хранилище показывает производительность системы в целом. А эти тесты ключевые.
Данные являются горячими только для последовательных тестов. Время тестов с произвольным доступом на реально нагруженном хранилище показывает производительность системы в целом. А эти тесты ключевые.
0
Вы выполнили последовательный тест и у вас все диски целиком осели в кэше. После этого произвольный доступ обращается уже к кэшу.
+3
Нет. Алгоритм работы iozone следующий:
— последовательная запись;
— последовательное чтение (тут некоторая часть читается из кэша, так как реальные клиенты постоянно вытесняют своими данными);
— последовательная запись всего файла;
— последовательное чтение всего файла (за время двух последних тестов данные уже полностью вытесняются).
— последовательная запись;
— последовательное чтение (тут некоторая часть читается из кэша, так как реальные клиенты постоянно вытесняют своими данными);
— последовательная запись всего файла;
— последовательное чтение всего файла (за время двух последних тестов данные уже полностью вытесняются).
0
С другой стороны, то, что у вас 96 Гб кэша в файлсервере, это дополнительная память в подарок всем клиентам — в среднем, несколько сотен Мб на каждую виртуальную машину. Конечно, этим кэшем больше всего пользуются VM с маленьким объемом памяти и интенсивным дисковым выводом — такие могут иметь постоянно занятую долю от этого кэша и несколько Гб.
В принципе, вы таким образом предоставляете очень хорошую возможность сокращения затрат для клиентов — держать самый минимальный размер оперативной памяти 512 Мб и свап где-нибудь на 8 или 16 Гб. Так как основная часть свапа находится в кэше на файл-сервере, это получается _очень быстрый_ свап. Интенсивность сваппинга в 100-200 Мб в секунду никаких ощутимых тормозов не дает.
В принципе, вы таким образом предоставляете очень хорошую возможность сокращения затрат для клиентов — держать самый минимальный размер оперативной памяти 512 Мб и свап где-нибудь на 8 или 16 Гб. Так как основная часть свапа находится в кэше на файл-сервере, это получается _очень быстрый_ свап. Интенсивность сваппинга в 100-200 Мб в секунду никаких ощутимых тормозов не дает.
+1
иопсы то все равно платные?
0
Шейпинг выключен всего лишь временно =)
0
Даже если будет шейпинг 100 Мб/сек, это не страшно. Решает микросекундное время задержки сети и доступа к оперативной памяти вместо миллисекунд физического позиционирования головки на диске.
0
вы ничего не путаете? как раз сетевая задержка (между нодой и хранилищем) и доступ к памяти это микросекунды, а вот позиционирование головок диска это миллисекунды (механика все же..) и они ОЧЕНЬ решают.
0
??? Я именно это и написал.
0
Вы написали что «Решает микросекундное время задержки сети и доступа к оперативной памяти», а я написал что «позиционирование головок диска это миллисекунды (механика все же..) и они ОЧЕНЬ решают» Или мы по-разному читаем…
0
Так и не пойму, с чем именно вы спорите. Если не трудно, распишите подробнее, не экономя на словах.
0
в вашем посте вы написали что важны задержки сети и доступа к памяти, я же написал что более важны задержки доступа к диску. но возможно вы просто описались или я неправильно понял ваш пост.
0
Нежно слили всех конкурентов :)
+3
«Сам себя не похвалишь — никто не похвалит.» ;)
+9
Жаль нет VMco и IT-Grad vCloud, я бы почитал про реальную производительность хваленых СХД netapp.
0
«реальную производительность хваленых СХД netapp» вы можете измерить только сами, и только их самих. Потому что способов убить производительность (любой системы хранения) существует десятки, и почем знать, какую из них выбрала данная конкретная компания.
ЗЫ. Ну по поводу самого поста тут уже многие высказались, не стану добавлять ;)
ЗЫ. Ну по поводу самого поста тут уже многие высказались, не стану добавлять ;)
+3
Зачем заранее боятся, что Netapp проиграет. Вот бы и увидели, как убили кривыми конфигами СХД. Или наоборот, как настоящий филер порвал бы решения почти на коленке от Селектела.
0
Я не понимаю, почему использование IETD должно считаться «решением на колене». (обиделся)
+7
Да я то не считаю, что решение Скалакси наколеночное, один Infiniband внушает. Просто вендоры СХД, при словах «мы построили СХД на linux, iscsi, SCST, md итд» криво как-то усмехаются. Не ынтерпрайз не решение.
0
вендоры усмехаются, потому, что им не удалось впарить тебе то же самое, но в 10 раз дороже. вот и троллят :)
+3
Ага, ага, производители железа всегда усмехаются при упоминании софтых опенсорсных решений. Adaptec тоже усмехался, пока ему:
а) не показали
б) не спросили как сделать тройной raid1.
С остальными вендорами ровно так же. У них никакие не волшебные диски, у них внутри всего лишь софт для управления операциями на диски. Софт, на который мы не можем влиять. В отличие от опенсорса, который можно и поправить, и пересобрать под задачу.
а) не показали
365883.382007] aacraid: SCSI bus appears hung [366011.032227] IRQ 26/aacraid: IRQF_DISABLED is not guaranteed on shared IRQs [453360.987916] aacraid: Host adapter abort request (0,0,0,0) [453360.988057] aacraid: Host adapter reset request. SCSI hang ? [453415.926534] aacraid: Host adapter abort request (0,0,0,0) [453415.926659] aacraid: Host adapter reset request. SCSI hang ? [453471.815273] aacraid: Host adapter abort request (0,0,0,0) [453471.815398] aacraid: Host adapter reset request. SCSI hang ? [453527.703998] aacraid: Host adapter abort request (0,0,0,0) [453527.704124] aacraid: Host adapter reset request. SCSI hang ? [453583.592740] aacraid: Host adapter abort request (0,0,0,0) [453583.592865] aacraid: Host adapter reset request. SCSI hang ? [453639.481478] aacraid: Host adapter abort request (0,0,0,0) [453639.481602] aacraid: Host adapter reset request. SCSI hang ? [453649.465609] sd 0:0:0:0: [sda] Unhandled error code [453649.465612] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT [453649.465616] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 3d e4 18 28 00 00 08 00 [453649.465625] end_request: I/O error, dev sda, sector 1038358568 [453649.465659] Buffer I/O error on device sda1, logical block 129794565 [453649.465688] lost page write due to I/O error on sda1
б) не спросили как сделать тройной raid1.
С остальными вендорами ровно так же. У них никакие не волшебные диски, у них внутри всего лишь софт для управления операциями на диски. Софт, на который мы не можем влиять. В отличие от опенсорса, который можно и поправить, и пересобрать под задачу.
+5
Только к опенсорсу нужно прикладывать и amarao в комплекте. :)
+4
нет, нужно прикладывать толковых спецов.
А теперь покажите мне вендора, который согласится, что с его хранилищем можно использовать тупых идиотов.
Я помню, на курсах адаптека обсуждались idiot's case, там много рассказывали. Толковые спецы нужны в любом случае (хотя бы, чтобы выбрать правильного вендора и конфиг под задачу). А если спецы есть, нафига нам люди, которые хотят много денег за то, что и так есть в опенсорсе (я в курсе про фичи нетаппа).
Главная же проблема с любым вендором — нельзя посмотреть «как оно работает». Когда у меня были проблемы с XCP, я посмотрел сырцы. И сделал с учётом того, что там написано, а не того, что написано в документации.
Наша окончательная позиция — мы работаем без вендорлока.
А теперь покажите мне вендора, который согласится, что с его хранилищем можно использовать тупых идиотов.
Я помню, на курсах адаптека обсуждались idiot's case, там много рассказывали. Толковые спецы нужны в любом случае (хотя бы, чтобы выбрать правильного вендора и конфиг под задачу). А если спецы есть, нафига нам люди, которые хотят много денег за то, что и так есть в опенсорсе (я в курсе про фичи нетаппа).
Главная же проблема с любым вендором — нельзя посмотреть «как оно работает». Когда у меня были проблемы с XCP, я посмотрел сырцы. И сделал с учётом того, что там написано, а не того, что написано в документации.
Наша окончательная позиция — мы работаем без вендорлока.
+3
Да, только в случае «вендора» это shared специалист (называется tech support), а в случае «опенсорса» — dedicated.
И «дешевизна» опенсорса компенсируется затратами на оплату знаний такого «дедика» ;)
И «дешевизна» опенсорса компенсируется затратами на оплату знаний такого «дедика» ;)
0
тобишь для обслуживания СХД вендора «дедик» не нужен? Достаточно суппорта? Или оплачивать знания схд-админа уже не нужно, обучение того же netapp схд админа далеко не дешевое занятие. И если честно я дико сомневаюсь в том, что схд-админ+обучение_оного+платная_техподдержка будет сильно дешевле и качественней, чем ЗП того же amarao.
+4
Я знаю совсем не одну компанию, которая обходится при обслуживании системы хранения «сисадмином общей практики», не выделенным на эту задачу, а занимающегося всем подряд в организации, в пределах своего подразделения.
Более того, это — нормально.
Возможно пока это диковинно в России, но в мире как раз держать на зарплате админа в конторе на 15-30-50 рабочих мест — вот это диковина и типичное «русское расточительство».
Использовать аутсорсного админа (и вендорский саппорт для решения специфических проблем конкретного оборудования), совсем не являющегося гуру в тематике вашей компании — это повседневный быт IT-отделов.
Это совершенно точно дешевле, чем найм специализированного человека, и дальнейший «вендорлок» на него, сколь бы ни был он сам замечательный специалист и человек.
Более того, это — нормально.
Возможно пока это диковинно в России, но в мире как раз держать на зарплате админа в конторе на 15-30-50 рабочих мест — вот это диковина и типичное «русское расточительство».
Использовать аутсорсного админа (и вендорский саппорт для решения специфических проблем конкретного оборудования), совсем не являющегося гуру в тематике вашей компании — это повседневный быт IT-отделов.
Это совершенно точно дешевле, чем найм специализированного человека, и дальнейший «вендорлок» на него, сколь бы ни был он сам замечательный специалист и человек.
+1
Нет, извините, техсаппорт вменяемого спеца в штате не заменяет.
Простая логика: кто определяет конфигурацию решения под задачу? Видимо, тот, кто способен проанализировать потребности. Может ли неквалифицированный специалист это сделать? Нет. Значит, нужен квалифицированный человек. И реально, топологию сети строит не техсаппорт вендоров одного из поставщиков, а именно этот человек.
Техсаппорт полезен, но мой опыт показывает, что никто из них не может сказать что-то новое и важное по сравнению с common knowledge.
Более того, мир вокруг меняется с такой скоростью, что данные годовалой давности уже не совсем точны, двухлетней устарели, а трёхлетней — ахинея. Особенно, в области сочетания виртуализации и технологий линукса.
Простая логика: кто определяет конфигурацию решения под задачу? Видимо, тот, кто способен проанализировать потребности. Может ли неквалифицированный специалист это сделать? Нет. Значит, нужен квалифицированный человек. И реально, топологию сети строит не техсаппорт вендоров одного из поставщиков, а именно этот человек.
Техсаппорт полезен, но мой опыт показывает, что никто из них не может сказать что-то новое и важное по сравнению с common knowledge.
Более того, мир вокруг меняется с такой скоростью, что данные годовалой давности уже не совсем точны, двухлетней устарели, а трёхлетней — ахинея. Особенно, в области сочетания виртуализации и технологий линукса.
0
Дело не в этом. А в том, что люди, которые пропагандируют «опенсорс» часто, намеренно ли, случайно ли, забывают, что к такому «бесплатному» решению, «без вендорлока», должен прилагаться специалист с зарплатой куда выше среднерыночной. И без него, случись что, все встанет.
Что такого специалиста и затраты на него нужно (равно как и все риски с этим связанные) учитывать в бизнесплане.
Вот будьте честны, вот случилось так, что у вас внезапно возникла необходимость срочно выйти «из бизнеса», допусти на полгода-год. Вот прямо завтра. Ну мало ли. В больницу попали, семейные проблемы. Просто внезапная смена ориентиров в жизни. Всякое бывает.
Сможет ли ваша компания продолжить жизнь без вас?
Вот только если честно?
Весь тот объем вашей ежедневной работы и знаний специфики решения можно передать завтра же свеженанятому специалисту?
В хорошей организации «от вендора» — можно. (и не только «можно» — нужно!) А в вашем случае?
Не кажется ли вам, что в вашем случае, вы, избавившись от «вендорлока» разных производителей железа и софта, получили вендорлок на своеобразного «вендора» по имени amarao?
Что такого специалиста и затраты на него нужно (равно как и все риски с этим связанные) учитывать в бизнесплане.
Вот будьте честны, вот случилось так, что у вас внезапно возникла необходимость срочно выйти «из бизнеса», допусти на полгода-год. Вот прямо завтра. Ну мало ли. В больницу попали, семейные проблемы. Просто внезапная смена ориентиров в жизни. Всякое бывает.
Сможет ли ваша компания продолжить жизнь без вас?
Вот только если честно?
Весь тот объем вашей ежедневной работы и знаний специфики решения можно передать завтра же свеженанятому специалисту?
В хорошей организации «от вендора» — можно. (и не только «можно» — нужно!) А в вашем случае?
Не кажется ли вам, что в вашем случае, вы, избавившись от «вендорлока» разных производителей железа и софта, получили вендорлок на своеобразного «вендора» по имени amarao?
+3
Во-первых, всё-таки нетактично в споре съезжать на личности.
Во-вторых, «вендорлок» на толкового специалиста лучше, чем на производителя — они, хоть под ногами и не валяются, но всё же заменяемы. В отличие от. Иначе можно дойти до «писать свой софт нельзя, вдруг программист, его писавший, заболеет».
В-третьих, люди надёжнее железа :)
Во-вторых, «вендорлок» на толкового специалиста лучше, чем на производителя — они, хоть под ногами и не валяются, но всё же заменяемы. В отличие от. Иначе можно дойти до «писать свой софт нельзя, вдруг программист, его писавший, заболеет».
В-третьих, люди надёжнее железа :)
+1
Ну если amarao сочтет себя оскорбленным таким «переходом на личности», то он сам скажет, не надо его защищать, он сам на кого хошь наедет себя защитит.
«Вендорлок» на конкретного человека _всегда_ хуже, чем на организацию, с которой возможны договорные обязательства, и которая несет за них юрответственность.
Потому что вот я уже выше пример привел. Идет вечером этот специалист домой, а навстречу — гопники. Результат — полгода в больнице. Реальный случай, кстати.
А в конторе все, оказывается, завязано на этого специалиста. Даже пароли от половины всех аккаунтов, админок и консолей — у него в голове, а он — в коме. И привет. Пишите письма.
Оказалось, что в конторе, так сильно озабоченной отсутствием «единой точки отказа» в оборудовании, самая главная «точка отказа» была на виду. Выяснилось, что случись что с одним человеком — и все, контора на грани остановки и попадания на большие деньги.
Думаете уникальный случай? Увы, нет.
«Вендорлок» на конкретного человека _всегда_ хуже, чем на организацию, с которой возможны договорные обязательства, и которая несет за них юрответственность.
Потому что вот я уже выше пример привел. Идет вечером этот специалист домой, а навстречу — гопники. Результат — полгода в больнице. Реальный случай, кстати.
А в конторе все, оказывается, завязано на этого специалиста. Даже пароли от половины всех аккаунтов, админок и консолей — у него в голове, а он — в коме. И привет. Пишите письма.
Оказалось, что в конторе, так сильно озабоченной отсутствием «единой точки отказа» в оборудовании, самая главная «точка отказа» была на виду. Выяснилось, что случись что с одним человеком — и все, контора на грани остановки и попадания на большие деньги.
Думаете уникальный случай? Увы, нет.
+1
Может быть, не нужно передёргивать? Пример, который вы привели («пароли в голове, голова в коме») — относится к неправильному случаю использования людских ресурсов, который вы пытаетесь сравнить с гипотетическим правильным случаем использования привязанного к вендору оборудования. Кроме того, при отказе маршрутизатора сеть падает; если же нормальный админ заболеет, ничего не упадёт.
0
Не уникальный. Потому-то у нас и сделано так, что все в команде (пусть хуже), но умеют делать всё, что делают другие.
Я более-менее ориентируюсь во всём, что наваяли наши спецы, они кое-как, но способны управляться с сервером и знают потроха xapi примерно как я (они его мучают с точки зрения XenAPI, я с точки зрения падучести deadbeef'овости).
Вопрос наличия или нет вендорлока на специалиста — вопрос производственной архитектуры, а не решения 'netapp или нет'. С netapp'ом ровно так же можно накрутить столько, что мало не покажется.
Я более-менее ориентируюсь во всём, что наваяли наши спецы, они кое-как, но способны управляться с сервером и знают потроха xapi примерно как я (они его мучают с точки зрения XenAPI, я с точки зрения падучести deadbeef'овости).
Вопрос наличия или нет вендорлока на специалиста — вопрос производственной архитектуры, а не решения 'netapp или нет'. С netapp'ом ровно так же можно накрутить столько, что мало не покажется.
0
Вендорлок по имени amarao есть, разумеется. Но помимо amarao на свете есть ещё куча документации по lvm, iscsi, drbd, xen'у, xapi и т.д. Таким образом, смена специалиста, конечно, приведёт к проблемам с изучением того, как работает архитектура.
Но… Рассмотрим сценарий, в котором мы заменили связку lvm, drbd и iscsi на netapp с iscsi.
Вопрос: если amarao, обратившийся в веру netapp'а уйдёт, то решится ли проблема изучения всей архитектуры? Не думаю.
А проблема хранилища? Да сейчас конфиги iscsi и lvm вместе меньше 10кб в размере, из которых примерно половина — тривиально-очевидны. Их изучение по обширнейней документации — дело двух недель для любого спеца моего уровня и день-два для человека с большим уровнем. Изучение netapp'а в этом смысле ничем не лучше и не хуже, чем изучение iscsi (благо, у iscsi и опций-то меньше). А знание LVM у линуксоида как-бы подразумевается.
Если же вы хотите сказать, что купив netapp можно уволить квалифицированного специалиста и нанять таджика…
Скажите, вы это готовы сказать? «Решения netapp не требюет наличия в штате квалифицированного персонала, так как наш саппорт решает за клиента все проблемы, связанные с хранилищем, его конфигурацией и интеграцией в используемые системы». Так?
Но… Рассмотрим сценарий, в котором мы заменили связку lvm, drbd и iscsi на netapp с iscsi.
Вопрос: если amarao, обратившийся в веру netapp'а уйдёт, то решится ли проблема изучения всей архитектуры? Не думаю.
А проблема хранилища? Да сейчас конфиги iscsi и lvm вместе меньше 10кб в размере, из которых примерно половина — тривиально-очевидны. Их изучение по обширнейней документации — дело двух недель для любого спеца моего уровня и день-два для человека с большим уровнем. Изучение netapp'а в этом смысле ничем не лучше и не хуже, чем изучение iscsi (благо, у iscsi и опций-то меньше). А знание LVM у линуксоида как-бы подразумевается.
Если же вы хотите сказать, что купив netapp можно уволить квалифицированного специалиста и нанять таджика…
Скажите, вы это готовы сказать? «Решения netapp не требюет наличия в штате квалифицированного персонала, так как наш саппорт решает за клиента все проблемы, связанные с хранилищем, его конфигурацией и интеграцией в используемые системы». Так?
0
Дело не в «заранее бояться».
Дело в том, что тестирование «ни о чем».
Вернее о том, что правильная методика — рулит. :)
А так получается тестирование скорости автомобилей разных марок, выйдя на улицу, и с секундомером замерив скорость десятка проехавших мимо автомобилей, а затем делая глубокомысленные выводы на основе результатов: «А смотри ка, ВАЗ-классика-то — самый быстрый!» А он может быстрый, потому что вам попалось два подряд джихад-такси, которым пофиг на правила :)
Это в случае самого Оверсана можно быть уверенным, что предоставлена максимальная производительность дисков, но отчего авторы решили, что какой-нибудь Amazon дает вот такой вот созданному «с улицы» инстансу вот прямо сразу всю производительность имеющихся у него дисков?
Есть QoS, он, конечно же, у правильных сервисов, используется.
Так что я думаю, что измерялся скорее порог дискового QoS «по умолчанию», а не «производительность дисков»
Ну и в завершение темы:
Rackspace использует NetApp с 2009 года. Я не могу гарантировать, что данные при создании первой же клиентской машины сразу окажутся на NetApp, контора там большая и сложная, и разных сервисов, в том числе и уровней использования много.
Но тем не менее:
Rackspace:
«Rackspace relies on NetApp storage and data management technology for a variety of hosting options. NetApp is a key component in powering The Rackspace Cloud, our cloud division. With NetApp we can create a virtual, shared, and dynamic infrastructure with extremely high utilization. This allows us to provide industry-leading cost efficiencies to our customers. Rackspace also uses NetApp to provide Dedicated NAS services to Enterprise Managed Hosting customers seeking a dedicated file storage and data protection solution.»
— John Engates, chief technology officer for Rackspace
www.netapp.com/us/company/news/news-rel-20090825-cloud-partners.html
Дело в том, что тестирование «ни о чем».
Вернее о том, что правильная методика — рулит. :)
А так получается тестирование скорости автомобилей разных марок, выйдя на улицу, и с секундомером замерив скорость десятка проехавших мимо автомобилей, а затем делая глубокомысленные выводы на основе результатов: «А смотри ка, ВАЗ-классика-то — самый быстрый!» А он может быстрый, потому что вам попалось два подряд джихад-такси, которым пофиг на правила :)
Это в случае самого Оверсана можно быть уверенным, что предоставлена максимальная производительность дисков, но отчего авторы решили, что какой-нибудь Amazon дает вот такой вот созданному «с улицы» инстансу вот прямо сразу всю производительность имеющихся у него дисков?
Есть QoS, он, конечно же, у правильных сервисов, используется.
Так что я думаю, что измерялся скорее порог дискового QoS «по умолчанию», а не «производительность дисков»
Ну и в завершение темы:
Rackspace использует NetApp с 2009 года. Я не могу гарантировать, что данные при создании первой же клиентской машины сразу окажутся на NetApp, контора там большая и сложная, и разных сервисов, в том числе и уровней использования много.
Но тем не менее:
Rackspace:
«Rackspace relies on NetApp storage and data management technology for a variety of hosting options. NetApp is a key component in powering The Rackspace Cloud, our cloud division. With NetApp we can create a virtual, shared, and dynamic infrastructure with extremely high utilization. This allows us to provide industry-leading cost efficiencies to our customers. Rackspace also uses NetApp to provide Dedicated NAS services to Enterprise Managed Hosting customers seeking a dedicated file storage and data protection solution.»
— John Engates, chief technology officer for Rackspace
www.netapp.com/us/company/news/news-rel-20090825-cloud-partners.html
+7
Я бы сказал, что это не тестирование авто, кто быстрей. А тестирование гостиниц. Вы клиент с улицы, то как вас быстро заселили показатель производительности персонала. Как клиенту в этих победили гостиницы Скалакси, terremark, rackspace.
0
Кстати, да.
Критерий отсева весьма странный: вы если техническую производительность тестируете, то какая разница по каким принципам происходят ее продажи?
Критерий отсева весьма странный: вы если техническую производительность тестируете, то какая разница по каким принципам происходят ее продажи?
0
Хочется комментариев от amarao и damad, если честно (:
+3
А сколько активных клиентов было на сторадже Скалакси при тестировании?
+3
Ждем ответа от Clodo
+6
Вот наш ответ:
Часть клиентов уже использует…
Подробности скоро…
Часть клиентов уже использует…
Подробности скоро…
+3
Часть
Ключевое.
Графики впечатляют, ждем подробностей.
Остальные данные из изначального поста взяты, или всё своё?
0
Коллеги, ключевой параметр в тестировании — нагруженное и заполненное хранилище. На пустых нодах произвольная запись у нас и поболее — на 4k под 100k IOPS, как и у терремарка.
0
Не из-за этого ли теста вчера днём вы упали?
+12
Если вы так уверены в себе, почему не заказали независимое тестирование?
А так-объективность весьма сомнительная, чистый PR…
А так-объективность весьма сомнительная, чистый PR…
+8
Мы с удовольствием снабдим вас необходимыми ресурсами, если вы захотите объективно повторить подобный тест.
+5
За предложение оплатить мне тестирование Amazon, Rackspace итд Спасибо! Наверно денег у вас и вправду много.)
А если серьезно.Если бы такой тест проводила независимая компания, даже по вашему заказу, доверия к его результатам было бы гораздо больше.
А если серьезно.Если бы такой тест проводила независимая компания, даже по вашему заказу, доверия к его результатам было бы гораздо больше.
0
(от имени Селектела).
SAN у нас работает на 10G, а не на гигабите. У нас используется шейпинг (чтобы один клиент, решивший поиграться с iozone/bonnie++ не создал затруднений соседям). Шейпинг работает чуть дальше кеша (то есть вы сможете получить неожиданные пики по чтению/записи, но не сможете нагрузить нашу дисковую подсистему насмерть). Плюс, мы используем intellicache.
Ваши тесты меня очень озадачили, вы сильно увеличили нагрузку. График загрузки дисков (график уже после кеша, то, что кеш пробило):
SAN у нас работает на 10G, а не на гигабите. У нас используется шейпинг (чтобы один клиент, решивший поиграться с iozone/bonnie++ не создал затруднений соседям). Шейпинг работает чуть дальше кеша (то есть вы сможете получить неожиданные пики по чтению/записи, но не сможете нагрузить нашу дисковую подсистему насмерть). Плюс, мы используем intellicache.
Ваши тесты меня очень озадачили, вы сильно увеличили нагрузку. График загрузки дисков (график уже после кеша, то, что кеш пробило):
+10
тобишь по рукам клиенту не успели дать за такие iops'ы?
0
зачем по рукам? чем больше клиент генерит иопсов, тем больше он их покупает. :)
вопрос только в том, что бы один плохой не мешал соседям с диском работать.
вопрос только в том, что бы один плохой не мешал соседям с диском работать.
+1
Зачэм быт да? Лучше болше хади болше дэнга плати.
Ради этого и задумывалось — для нас нет плохих клиентов (кроме спамеров и т.д.) — что бы клиент в машине не вытворял, мы с этого деньги получим.
Взмен, клиенты, которые делают по 1к операций в день спокойно лежат и не платят лишнего.
Ради этого и задумывалось — для нас нет плохих клиентов (кроме спамеров и т.д.) — что бы клиент в машине не вытворял, мы с этого деньги получим.
Взмен, клиенты, которые делают по 1к операций в день спокойно лежат и не платят лишнего.
+4
Для уточнения, что есть до кеша, а то после — с какой стороны смотрите на кеш? «до кеша» — это ближе к дисками или ближе к вм-кам?
0
Да, наоборот, шейпинг в облаке обязан быть. Я имея там виртуалку, совсем бы не хотел, что бы меня тормозили например ваши тесты. Пусть лучше вас ограничат в полосе, но у меня латентность дисковых операций не изменится.
Так что пока тесты не совсем адекватны, вы видите то, что происходит с высоконагружающей систему виртуалкой, но не видите, на сколько это влияет на соседей. Если получили рекордный иопс, но все соседи тормозили по страшному — то нафиг такой хостинг. А если получили умеренный, но соседи даже не почесались — вот это хорошее решение.
Так что пока тесты не совсем адекватны, вы видите то, что происходит с высоконагружающей систему виртуалкой, но не видите, на сколько это влияет на соседей. Если получили рекордный иопс, но все соседи тормозили по страшному — то нафиг такой хостинг. А если получили умеренный, но соседи даже не почесались — вот это хорошее решение.
+9
Латентность изменится, увы, контролировать это сложно, но у нас есть некие рамки, которые мы более-менее можем сдерживать (то есть можно запросто получить 10мс вместо 2мс из-за засранца рядом). Увы, технологии контроля дисков только-только развиваются, и точного представления что с этим делать пока нет.
Какие-то наброски (идеи) есть, но в жизнь мы их пока не закодировали.
Какие-то наброски (идеи) есть, но в жизнь мы их пока не закодировали.
+1
Мы написали, что шейпинг временно выключен и включится, когда мы сделаем отдельно регулируемую ширину канала для каждого диска.
0
выключен он у вас (то есть в этот момент 1. можно было получить всю полосу 2. затормозить соседние виртуалки).
а включен (если есть) у других тестируемых участников он или нет — вы не знаете.
то есть у себя вы лимиты сняли и показали рекордный иопс, а что и как настроено у остальных — неизвестно. по этому обзор бессмысленный.
а включен (если есть) у других тестируемых участников он или нет — вы не знаете.
то есть у себя вы лимиты сняли и показали рекордный иопс, а что и как настроено у остальных — неизвестно. по этому обзор бессмысленный.
+5
ну не совсем бессмысленный — клиенты хоть знают, чего ждать…
+2
а чего ждать от включения шейпинга у скалакси? может он после этого скатится в самый низ графика?
0
После этого сколько купите, столько и будет. При это уровень гарантии будет на порядки выше остальных провайдеров.
+2
я могу купить все, и увеличить латентность диска для всех соседей?
0
Если вы купите все, мы сделаем для вас отдельный кластер, а курьером, который привезет вам договор будет Анджелина Джоли или любое другое существо по вашему выбору.
На механических дисках — да, есть вероятность, что латентность у соседей по диску увеличится. На SSD соседи ничего не заметят. SSD дисков правда уже нет в панели, так как весь объем давно продан, но в будущем опять появятся.
На механических дисках — да, есть вероятность, что латентность у соседей по диску увеличится. На SSD соседи ничего не заметят. SSD дисков правда уже нет в панели, так как весь объем давно продан, но в будущем опять появятся.
+10
Еще раз повторю, в облачных СХД самое главное — производительность произвольных операций чтения и записи. Шейпить эти операции отдельно от последовательных никто не умеет — 100%. Ну а так как у всех провайдеров произвольные тесты сильно отличаются от последовательных, то значит на результат первых никакой шейпинг не влияет и они зависят только от общей производительности системы.
Ну а поскольку основной профиль нагрузки интернет-проектов — произвольные операции в БД или с мелкими файлами, наша система очень хорошо решает эти задачи.
Ну а поскольку основной профиль нагрузки интернет-проектов — произвольные операции в БД или с мелкими файлами, наша система очень хорошо решает эти задачи.
+2
НЛО прилетело и опубликовало эту надпись здесь
Антиреклама Скалакси прежде всего. До сих пор мне как-то они казались более «вменяемыми» и понимающими предмет. :(
Но выкатывать на хабр такую шитую белыми нитками заказуху… Причем лучше бы если бы это была заказуха, потому что если люди в самом деле верят в то, что они «намеряли», вот в таком случае все куда хуже.
Но выкатывать на хабр такую шитую белыми нитками заказуху… Причем лучше бы если бы это была заказуха, потому что если люди в самом деле верят в то, что они «намеряли», вот в таком случае все куда хуже.
-1
Простите за глупость, но помогите разобраться, как вы получили итоговую таблицу данных? Помогите на примере:
screenlog.scalaxy.1:
screenlog.scalaxy.1:
+1
Случайно рано промахнулся кнопкой…
screenlog.scalaxy.1:
8388608 4 35733 26702 40831 35005 2038 14105
8388608 4 77614 49849 78251 76950 3560 18524
8388608 4 67363 34573 57054 61127 3115 20614
screenlog.scalaxy.2:
8388608 4 74578 27050 51325 64362 3197 10534
8388608 4 67450 39465 69858 74963 3479 10003
8388608 4 52392 28300 69194 62910 3364 7827
screenlog.scalaxy.3:
8388608 4 75524 31947 82384 77260 3511 8342
8388608 4 59282 34287 93289 92944 3839 6957
8388608 4 85223 39246 95587 89991 3771 12086
Как из этих исходных данных вы получили те данные, которые у вас в гугл-таблице?
screenlog.scalaxy.1:
8388608 4 35733 26702 40831 35005 2038 14105
8388608 4 77614 49849 78251 76950 3560 18524
8388608 4 67363 34573 57054 61127 3115 20614
screenlog.scalaxy.2:
8388608 4 74578 27050 51325 64362 3197 10534
8388608 4 67450 39465 69858 74963 3479 10003
8388608 4 52392 28300 69194 62910 3364 7827
screenlog.scalaxy.3:
8388608 4 75524 31947 82384 77260 3511 8342
8388608 4 59282 34287 93289 92944 3839 6957
8388608 4 85223 39246 95587 89991 3771 12086
Как из этих исходных данных вы получили те данные, которые у вас в гугл-таблице?
+3
Для сравнения, вот данные с hetzner eq8:
8388608 4 41963 38170 1514434 1525684 1004891 1847
8388608 4 41963 38170 1514434 1525684 1004891 1847
0
Судя по 1514434, количество RAM на этой виртуалке много больше 512 МБ. Перечитайте методику теста.
0
Зная о eq8 то 24 GB DDR3 RAM
К стати почему именно 512 у вас?
К стати почему именно 512 у вас?
0
При объеме файла в тесте 15 ГБ он полностью укладывается в оперативную память виртуальной машины (24 ГБ в случае eq8), и тогда тест чтения показывает скорость чтения из оперативной памяти, а не из системы хранения.
512 МБ мы выбрали как минимальный размер доступный у большинства провайдеров, чтобы память не влияла на тесты чтения.
512 МБ мы выбрали как минимальный размер доступный у большинства провайдеров, чтобы память не влияла на тесты чтения.
0
Да, к сожалению забыл про это. Действительно, у hetzner всего 24GB. Но если всё пересчитать на деньги, то у вас за аналогичную стоимость будет 3.5GB. Во сколько раз, примерно, увеличатся исходные показатели из ваших тестов на 512MB?
0
Очень просто, берем столбцы 3 (линейная запись), 5 (линейное чтение), 6 (произвольная запись), 7 (произвольное чтение) и передаем функции AVERAGE в Google spreadsheets.
0
Мне, эти «тесты», напоминают тесты от Microsoft, в котором IE9 всегда впереди. Хотя, вроде все правильно и наглядно.
+8
Ну-у-у, зайдите на блог EMC — там EMC впереди планеты всей и плевали они на всех с высокой колокольни. На блогах netapp — вам расскажут, что вы заплатите меньше получите больше, уникальный WAFL, супербыстрый flashcache и огого-и-эгегей. На мероприятии HP вам расскажут, что дескать мы уже порвали почти всех, винты у нас быстрее, кешы больше, фибра фибрастей и надо брать. Маркетинг. Он как религия.
+4
«слишком медленно, что бы использовать на реальных приложениях» — вы бы, коллеги, сначала спросили у реальных приложений. Это раз.
Плюс к тому — небольшой логический реверанс: «коллеги, работающие с первой версией нашей архитектуры 2008 года» + «слишком медленно, что бы использовать на реальных приложениях» == «мы были неюзабельными и водили за нос клиентов, пока нас не клюнул жареный петух, и мы не поменяли архитектуру». Мы ценим ваше качественное развитие, скоро и у нас, что тут скрывать, ожидается обновление СХД. Но такие категоричные выводы вам совершенно не идут.
Тем более, что есть разные методики тестирования и результаты какой из них говорят о реальных ощущениях клиента — это большой вопрос. Ну и еще один вопрос — это самочувствие клиентов-соседей при проведении тестов.
Плюс к тому — небольшой логический реверанс: «коллеги, работающие с первой версией нашей архитектуры 2008 года» + «слишком медленно, что бы использовать на реальных приложениях» == «мы были неюзабельными и водили за нос клиентов, пока нас не клюнул жареный петух, и мы не поменяли архитектуру». Мы ценим ваше качественное развитие, скоро и у нас, что тут скрывать, ожидается обновление СХД. Но такие категоричные выводы вам совершенно не идут.
Тем более, что есть разные методики тестирования и результаты какой из них говорят о реальных ощущениях клиента — это большой вопрос. Ну и еще один вопрос — это самочувствие клиентов-соседей при проведении тестов.
+9
Чувствую «топор войны» откопали-будем ждать «тестов Скалакси» от Селектел и Clodo.)
+6
Ага, нагрузка на все хранилище уже выросла в 6 раз с момента публикации поста.
+1
Черный Властелин атакует хранилище!
+1
Ну и как? 300МБ/с держите?
0
300Мегабайт в секунду — это примерно три гигабита.
SAS-порт даёт шесть гигабит, тобишь держит на заявленных 300МБ/сек две виртуальные машинки. Ещё один SAS-порт держит те-же самые две машинки во второй половинке зеркала.
То-есть, чтобы держать 300Мб/сек. на тысяче, даже не клиентов, а виртуальных машин, без учёта кэширования, и с учётом зеркалирования, необходимо иметь:
500 SAS портов X 2 половинки зеркала == 1000 SAS-портов.
То-есть по одному SAS-порту на каждую виртуальную машину?
SAS-порт даёт шесть гигабит, тобишь держит на заявленных 300МБ/сек две виртуальные машинки. Ещё один SAS-порт держит те-же самые две машинки во второй половинке зеркала.
То-есть, чтобы держать 300Мб/сек. на тысяче, даже не клиентов, а виртуальных машин, без учёта кэширования, и с учётом зеркалирования, необходимо иметь:
500 SAS портов X 2 половинки зеркала == 1000 SAS-портов.
То-есть по одному SAS-порту на каждую виртуальную машину?
0
Честно говоря, лучший ответ на «наброс на вентилятор» — игнор.
-2
Нет, я не планирую меряться пиписьками. Собрать охрененно быстрое хранилище можно — его будет невозможно окупить. Основной момент — обеспечить требуемую производительность в разумные деньги и при этом ещё не потерять надёжность.
+7
А ты провел тестирование СХД конкурентов?
-12
Когда-то на Хабре пробегал такой слайд- «Есть ложь, наглая ложь и есть бенчмарки».
А по сути — мне просто интересно ЗАЧЕМ вбухали столько бабла а стореджи, интерконнект и IOPS'ы??
Дайте клиентам много дешевого RAM и guestOS сами накешат то что нужно.
А по сути — мне просто интересно ЗАЧЕМ вбухали столько бабла а стореджи, интерконнект и IOPS'ы??
Дайте клиентам много дешевого RAM и guestOS сами накешат то что нужно.
+1
Не всё, увы. В рамках той теории, которую мы используем, есть т.н. «злые иопсы», которые в любом случае пройдут на самый низкий уровень хранения через все кеши.
+1
Какой процент «злых иопсов» в общем? Большинство клиентов держат web и небольшые db которые влазят в RAM. Но у вас RAM дорогой — поэтому берут 512 MB и засовуют в него систему и 2 гига db, что чревато нагрузкой на СХД.
Среди тех кому действительно нужно много IO — те кто криво настроил os и db или те у кого бизнес-логика на уровне db(но такие не юзают общественные cloud'ы).
Среди тех кому действительно нужно много IO — те кто криво настроил os и db или те у кого бизнес-логика на уровне db(но такие не юзают общественные cloud'ы).
+1
У большинства проектов >20k уникальных посетителей в месяц БД в память не влазит, а диски являются самым узким местом.
0
Любое уникальное чтение является «злым». До тех пор, пока у нас кеш меньше устройства хранения, то злые иопсы будут всегда. Даже запись можно закешировать (у нас intellicache на графике хорошо видно — записи много меньше, чем чтения), а вот рандомное первое чтение — нет.
0
Я недавно занимался переносом одного мелкого торент трекера с посещаемостью около 25к уников в день. Перенос осуществляли с hetzner eq8 на самосборный сервер, в который воткнули ssd и 12GB DDR3. MySQL база трекера занимает всего 3GB и легко уместилась в памяти. Установлен nginx (gzip,aio) + php-fpm (mysqli,apc), что позволило достичь отсутствие fail на ab -n 10000 -c 1000. К сожалению, в час пик уже не хватает мощности сервера. В связи с чем, ищем подходящую площадку. В данный момент расходы на сервер не превышают 3000р/месяц. Возможно ли имея такие исходные данные, захоститься у вас по аналогичной стоимости и получиться отсутствие 502 Bad Gateway в час пик?
Думал отправить в ЛС, но вдруг кто-нибудь другой подскажет, что лучше сделать в этой ситуации?
Думал отправить в ЛС, но вдруг кто-нибудь другой подскажет, что лучше сделать в этой ситуации?
0
При таких нагрузках долго масштабировать в лоб, вертикально, не получится. как минимум придется переходить к настоящему FastCGI и накапливать данные для обновлением пачкой за один запрос. Но рано или поздно придется трекер переписывать в самостоятельный постоянно работающий демон для нормального кэширования данных и минимизации обращений к внешней БД.
И да, посещаемость в униках для трекера не показательна, интереснее максимальное(пиковое) суммарное число активных торрентов по всем пользователям и время между анонсами.
И да, посещаемость в униках для трекера не показательна, интереснее максимальное(пиковое) суммарное число активных торрентов по всем пользователям и время между анонсами.
+1
Посещаемость, которую я указал выше — это данные из Google Analytics. Т.е. это статистика только по «главной страничке форума». А обычная статистика с анонсера такая: пиров >600к, раздающих >400к, скачивающих >150к. В дни, когда какая-нибудь «новинка» то +10-20%.
Думаете, всё-таки нужно начинать оптимизировать программную часть самого форума и анонсера?
Думаете, всё-таки нужно начинать оптимизировать программную часть самого форума и анонсера?
0
Лично мое мнение — да. Даже если предположить довольно скромное время анонса 30 минут, получается около 350 запросов в секунду к трекеру, что выливается в 1-2 миллиона запросов в секунду к базе данных в зависимости от удачности архитектуры — это уже большая нагрузка, особенно учитывая что примерно половина запросов это запись.
Вообще, если база полностью в памяти — не совсем понятно, зачем вам SSD.
Для справки — трекер nnm-club(на C++) работает в 1 поток и потребляет меньше 1GB памяти.
Вообще, если база полностью в памяти — не совсем понятно, зачем вам SSD.
Для справки — трекер nnm-club(на C++) работает в 1 поток и потребляет меньше 1GB памяти.
0
Время анонса 30 минут. Запросов в секунду в обычном режиме около 450, в пике доходило до 800. На SSD OCZ Agility-2 файлы форума. А по софту — используем всем известный ppkbb3cker с оригинальным анонсером, который, по хорошему, надо заменить на xbtt.
Вообщем ясно. Будем значит оптимизировать программную часть. Спасибо.
Вообщем ясно. Будем значит оптимизировать программную часть. Спасибо.
0
Они убили Кенни Clodo…
+5
Clodo — коллеги, работающие с первой версией нашей архитектуры 2008 года, IBM GPFS хранилище, решение на базе Xen.Какой тонкий троллинг =)
+12
Вопрос к автору исследований.
Вот это ваше кеширование как отражается на целостности данных? К примеру, произведена транзакция и сервер кеширования падает. Транзакция на диске не запечатлена — только в ОЗУ на сервере кеширования? Получается нет гарантии целостности данных?
Вот это ваше кеширование как отражается на целостности данных? К примеру, произведена транзакция и сервер кеширования падает. Транзакция на диске не запечатлена — только в ОЗУ на сервере кеширования? Получается нет гарантии целостности данных?
+2
Скорости не так интересны как средние/максимальные задержки случайного чтения/записи, так как именно они влияют на скорость формирования страниц и отзывчивость сайта в целом. Очень странно что вы их не указали…
+1
Вводная информация не точна. IT-GRAD предлагает почасовую тарификацию (pay-as-you-go). Кроме того интерфейс vCloud позволяет самостоятельно создавать машины без обращений в службу поддержки + есть развитый API.
А если говорить про сам топик — тестирование производительности дисковой подсистемы — то в нашем SLA содержатся специальные метрики — max Latency и min IOPS, которые могут быть оптимизированы под конкретных корпоративных заказчиков.
А если говорить про сам топик — тестирование производительности дисковой подсистемы — то в нашем SLA содержатся специальные метрики — max Latency и min IOPS, которые могут быть оптимизированы под конкретных корпоративных заказчиков.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование дисков облачных провайдеров