Комментарии 127
Он нас всех посчитал!
А можно промо код? :)
Сами потестировали, сам заняли первое место :)
Сделали добротно, с учетом накопленного опыта и понимания особенностей облачных платформ, поэтому и результаты соответствующие.
Судя по вашему описания системы хранения, ваш результат тестирования — это результат кэша 96 Гб на файловом сервере. У трех машин диски по 15 Гб целиком укладываются в этот кэш и за счет короткого времени проведения тестирования, все данные в этом кэше являются горячими.
Ключевой особенностью всех СХД является способ организации рейда и алгоритмы системы кэширования, диски-то все равно у всех одинаковые.
Данные являются горячими только для последовательных тестов. Время тестов с произвольным доступом на реально нагруженном хранилище показывает производительность системы в целом. А эти тесты ключевые.
Данные являются горячими только для последовательных тестов. Время тестов с произвольным доступом на реально нагруженном хранилище показывает производительность системы в целом. А эти тесты ключевые.
Вы выполнили последовательный тест и у вас все диски целиком осели в кэше. После этого произвольный доступ обращается уже к кэшу.
Нет. Алгоритм работы iozone следующий:
— последовательная запись;
— последовательное чтение (тут некоторая часть читается из кэша, так как реальные клиенты постоянно вытесняют своими данными);
— последовательная запись всего файла;
— последовательное чтение всего файла (за время двух последних тестов данные уже полностью вытесняются).
— последовательная запись;
— последовательное чтение (тут некоторая часть читается из кэша, так как реальные клиенты постоянно вытесняют своими данными);
— последовательная запись всего файла;
— последовательное чтение всего файла (за время двух последних тестов данные уже полностью вытесняются).
С другой стороны, то, что у вас 96 Гб кэша в файлсервере, это дополнительная память в подарок всем клиентам — в среднем, несколько сотен Мб на каждую виртуальную машину. Конечно, этим кэшем больше всего пользуются VM с маленьким объемом памяти и интенсивным дисковым выводом — такие могут иметь постоянно занятую долю от этого кэша и несколько Гб.
В принципе, вы таким образом предоставляете очень хорошую возможность сокращения затрат для клиентов — держать самый минимальный размер оперативной памяти 512 Мб и свап где-нибудь на 8 или 16 Гб. Так как основная часть свапа находится в кэше на файл-сервере, это получается _очень быстрый_ свап. Интенсивность сваппинга в 100-200 Мб в секунду никаких ощутимых тормозов не дает.
В принципе, вы таким образом предоставляете очень хорошую возможность сокращения затрат для клиентов — держать самый минимальный размер оперативной памяти 512 Мб и свап где-нибудь на 8 или 16 Гб. Так как основная часть свапа находится в кэше на файл-сервере, это получается _очень быстрый_ свап. Интенсивность сваппинга в 100-200 Мб в секунду никаких ощутимых тормозов не дает.
иопсы то все равно платные?
Шейпинг выключен всего лишь временно =)
Даже если будет шейпинг 100 Мб/сек, это не страшно. Решает микросекундное время задержки сети и доступа к оперативной памяти вместо миллисекунд физического позиционирования головки на диске.
вы ничего не путаете? как раз сетевая задержка (между нодой и хранилищем) и доступ к памяти это микросекунды, а вот позиционирование головок диска это миллисекунды (механика все же..) и они ОЧЕНЬ решают.
??? Я именно это и написал.
Вы написали что «Решает микросекундное время задержки сети и доступа к оперативной памяти», а я написал что «позиционирование головок диска это миллисекунды (механика все же..) и они ОЧЕНЬ решают» Или мы по-разному читаем…
Нежно слили всех конкурентов :)
«Сам себя не похвалишь — никто не похвалит.» ;)
Жаль нет VMco и IT-Grad vCloud, я бы почитал про реальную производительность хваленых СХД netapp.
«реальную производительность хваленых СХД netapp» вы можете измерить только сами, и только их самих. Потому что способов убить производительность (любой системы хранения) существует десятки, и почем знать, какую из них выбрала данная конкретная компания.
ЗЫ. Ну по поводу самого поста тут уже многие высказались, не стану добавлять ;)
ЗЫ. Ну по поводу самого поста тут уже многие высказались, не стану добавлять ;)
Зачем заранее боятся, что Netapp проиграет. Вот бы и увидели, как убили кривыми конфигами СХД. Или наоборот, как настоящий филер порвал бы решения почти на коленке от Селектела.
Я не понимаю, почему использование IETD должно считаться «решением на колене». (обиделся)
Да я то не считаю, что решение Скалакси наколеночное, один Infiniband внушает. Просто вендоры СХД, при словах «мы построили СХД на linux, iscsi, SCST, md итд» криво как-то усмехаются. Не ынтерпрайз не решение.
вендоры усмехаются, потому, что им не удалось впарить тебе то же самое, но в 10 раз дороже. вот и троллят :)
Ага, ага, производители железа всегда усмехаются при упоминании софтых опенсорсных решений. 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.
С остальными вендорами ровно так же. У них никакие не волшебные диски, у них внутри всего лишь софт для управления операциями на диски. Софт, на который мы не можем влиять. В отличие от опенсорса, который можно и поправить, и пересобрать под задачу.
Только к опенсорсу нужно прикладывать и amarao в комплекте. :)
Гм… к netapp тоже надо прикладывать, multagor например.
нет, нужно прикладывать толковых спецов.
А теперь покажите мне вендора, который согласится, что с его хранилищем можно использовать тупых идиотов.
Я помню, на курсах адаптека обсуждались idiot's case, там много рассказывали. Толковые спецы нужны в любом случае (хотя бы, чтобы выбрать правильного вендора и конфиг под задачу). А если спецы есть, нафига нам люди, которые хотят много денег за то, что и так есть в опенсорсе (я в курсе про фичи нетаппа).
Главная же проблема с любым вендором — нельзя посмотреть «как оно работает». Когда у меня были проблемы с XCP, я посмотрел сырцы. И сделал с учётом того, что там написано, а не того, что написано в документации.
Наша окончательная позиция — мы работаем без вендорлока.
А теперь покажите мне вендора, который согласится, что с его хранилищем можно использовать тупых идиотов.
Я помню, на курсах адаптека обсуждались idiot's case, там много рассказывали. Толковые спецы нужны в любом случае (хотя бы, чтобы выбрать правильного вендора и конфиг под задачу). А если спецы есть, нафига нам люди, которые хотят много денег за то, что и так есть в опенсорсе (я в курсе про фичи нетаппа).
Главная же проблема с любым вендором — нельзя посмотреть «как оно работает». Когда у меня были проблемы с XCP, я посмотрел сырцы. И сделал с учётом того, что там написано, а не того, что написано в документации.
Наша окончательная позиция — мы работаем без вендорлока.
Да, только в случае «вендора» это shared специалист (называется tech support), а в случае «опенсорса» — dedicated.
И «дешевизна» опенсорса компенсируется затратами на оплату знаний такого «дедика» ;)
И «дешевизна» опенсорса компенсируется затратами на оплату знаний такого «дедика» ;)
тобишь для обслуживания СХД вендора «дедик» не нужен? Достаточно суппорта? Или оплачивать знания схд-админа уже не нужно, обучение того же netapp схд админа далеко не дешевое занятие. И если честно я дико сомневаюсь в том, что схд-админ+обучение_оного+платная_техподдержка будет сильно дешевле и качественней, чем ЗП того же amarao.
Я знаю совсем не одну компанию, которая обходится при обслуживании системы хранения «сисадмином общей практики», не выделенным на эту задачу, а занимающегося всем подряд в организации, в пределах своего подразделения.
Более того, это — нормально.
Возможно пока это диковинно в России, но в мире как раз держать на зарплате админа в конторе на 15-30-50 рабочих мест — вот это диковина и типичное «русское расточительство».
Использовать аутсорсного админа (и вендорский саппорт для решения специфических проблем конкретного оборудования), совсем не являющегося гуру в тематике вашей компании — это повседневный быт IT-отделов.
Это совершенно точно дешевле, чем найм специализированного человека, и дальнейший «вендорлок» на него, сколь бы ни был он сам замечательный специалист и человек.
Более того, это — нормально.
Возможно пока это диковинно в России, но в мире как раз держать на зарплате админа в конторе на 15-30-50 рабочих мест — вот это диковина и типичное «русское расточительство».
Использовать аутсорсного админа (и вендорский саппорт для решения специфических проблем конкретного оборудования), совсем не являющегося гуру в тематике вашей компании — это повседневный быт IT-отделов.
Это совершенно точно дешевле, чем найм специализированного человека, и дальнейший «вендорлок» на него, сколь бы ни был он сам замечательный специалист и человек.
Нет, извините, техсаппорт вменяемого спеца в штате не заменяет.
Простая логика: кто определяет конфигурацию решения под задачу? Видимо, тот, кто способен проанализировать потребности. Может ли неквалифицированный специалист это сделать? Нет. Значит, нужен квалифицированный человек. И реально, топологию сети строит не техсаппорт вендоров одного из поставщиков, а именно этот человек.
Техсаппорт полезен, но мой опыт показывает, что никто из них не может сказать что-то новое и важное по сравнению с common knowledge.
Более того, мир вокруг меняется с такой скоростью, что данные годовалой давности уже не совсем точны, двухлетней устарели, а трёхлетней — ахинея. Особенно, в области сочетания виртуализации и технологий линукса.
Простая логика: кто определяет конфигурацию решения под задачу? Видимо, тот, кто способен проанализировать потребности. Может ли неквалифицированный специалист это сделать? Нет. Значит, нужен квалифицированный человек. И реально, топологию сети строит не техсаппорт вендоров одного из поставщиков, а именно этот человек.
Техсаппорт полезен, но мой опыт показывает, что никто из них не может сказать что-то новое и важное по сравнению с common knowledge.
Более того, мир вокруг меняется с такой скоростью, что данные годовалой давности уже не совсем точны, двухлетней устарели, а трёхлетней — ахинея. Особенно, в области сочетания виртуализации и технологий линукса.
Дело не в этом. А в том, что люди, которые пропагандируют «опенсорс» часто, намеренно ли, случайно ли, забывают, что к такому «бесплатному» решению, «без вендорлока», должен прилагаться специалист с зарплатой куда выше среднерыночной. И без него, случись что, все встанет.
Что такого специалиста и затраты на него нужно (равно как и все риски с этим связанные) учитывать в бизнесплане.
Вот будьте честны, вот случилось так, что у вас внезапно возникла необходимость срочно выйти «из бизнеса», допусти на полгода-год. Вот прямо завтра. Ну мало ли. В больницу попали, семейные проблемы. Просто внезапная смена ориентиров в жизни. Всякое бывает.
Сможет ли ваша компания продолжить жизнь без вас?
Вот только если честно?
Весь тот объем вашей ежедневной работы и знаний специфики решения можно передать завтра же свеженанятому специалисту?
В хорошей организации «от вендора» — можно. (и не только «можно» — нужно!) А в вашем случае?
Не кажется ли вам, что в вашем случае, вы, избавившись от «вендорлока» разных производителей железа и софта, получили вендорлок на своеобразного «вендора» по имени amarao?
Что такого специалиста и затраты на него нужно (равно как и все риски с этим связанные) учитывать в бизнесплане.
Вот будьте честны, вот случилось так, что у вас внезапно возникла необходимость срочно выйти «из бизнеса», допусти на полгода-год. Вот прямо завтра. Ну мало ли. В больницу попали, семейные проблемы. Просто внезапная смена ориентиров в жизни. Всякое бывает.
Сможет ли ваша компания продолжить жизнь без вас?
Вот только если честно?
Весь тот объем вашей ежедневной работы и знаний специфики решения можно передать завтра же свеженанятому специалисту?
В хорошей организации «от вендора» — можно. (и не только «можно» — нужно!) А в вашем случае?
Не кажется ли вам, что в вашем случае, вы, избавившись от «вендорлока» разных производителей железа и софта, получили вендорлок на своеобразного «вендора» по имени amarao?
Во-первых, всё-таки нетактично в споре съезжать на личности.
Во-вторых, «вендорлок» на толкового специалиста лучше, чем на производителя — они, хоть под ногами и не валяются, но всё же заменяемы. В отличие от. Иначе можно дойти до «писать свой софт нельзя, вдруг программист, его писавший, заболеет».
В-третьих, люди надёжнее железа :)
Во-вторых, «вендорлок» на толкового специалиста лучше, чем на производителя — они, хоть под ногами и не валяются, но всё же заменяемы. В отличие от. Иначе можно дойти до «писать свой софт нельзя, вдруг программист, его писавший, заболеет».
В-третьих, люди надёжнее железа :)
Ну если amarao сочтет себя оскорбленным таким «переходом на личности», то он сам скажет, не надо его защищать, он сам на кого хошь наедет себя защитит.
«Вендорлок» на конкретного человека _всегда_ хуже, чем на организацию, с которой возможны договорные обязательства, и которая несет за них юрответственность.
Потому что вот я уже выше пример привел. Идет вечером этот специалист домой, а навстречу — гопники. Результат — полгода в больнице. Реальный случай, кстати.
А в конторе все, оказывается, завязано на этого специалиста. Даже пароли от половины всех аккаунтов, админок и консолей — у него в голове, а он — в коме. И привет. Пишите письма.
Оказалось, что в конторе, так сильно озабоченной отсутствием «единой точки отказа» в оборудовании, самая главная «точка отказа» была на виду. Выяснилось, что случись что с одним человеком — и все, контора на грани остановки и попадания на большие деньги.
Думаете уникальный случай? Увы, нет.
«Вендорлок» на конкретного человека _всегда_ хуже, чем на организацию, с которой возможны договорные обязательства, и которая несет за них юрответственность.
Потому что вот я уже выше пример привел. Идет вечером этот специалист домой, а навстречу — гопники. Результат — полгода в больнице. Реальный случай, кстати.
А в конторе все, оказывается, завязано на этого специалиста. Даже пароли от половины всех аккаунтов, админок и консолей — у него в голове, а он — в коме. И привет. Пишите письма.
Оказалось, что в конторе, так сильно озабоченной отсутствием «единой точки отказа» в оборудовании, самая главная «точка отказа» была на виду. Выяснилось, что случись что с одним человеком — и все, контора на грани остановки и попадания на большие деньги.
Думаете уникальный случай? Увы, нет.
Может быть, не нужно передёргивать? Пример, который вы привели («пароли в голове, голова в коме») — относится к неправильному случаю использования людских ресурсов, который вы пытаетесь сравнить с гипотетическим правильным случаем использования привязанного к вендору оборудования. Кроме того, при отказе маршрутизатора сеть падает; если же нормальный админ заболеет, ничего не упадёт.
Не уникальный. Потому-то у нас и сделано так, что все в команде (пусть хуже), но умеют делать всё, что делают другие.
Я более-менее ориентируюсь во всём, что наваяли наши спецы, они кое-как, но способны управляться с сервером и знают потроха xapi примерно как я (они его мучают с точки зрения XenAPI, я с точки зрения падучести deadbeef'овости).
Вопрос наличия или нет вендорлока на специалиста — вопрос производственной архитектуры, а не решения 'netapp или нет'. С netapp'ом ровно так же можно накрутить столько, что мало не покажется.
Я более-менее ориентируюсь во всём, что наваяли наши спецы, они кое-как, но способны управляться с сервером и знают потроха xapi примерно как я (они его мучают с точки зрения XenAPI, я с точки зрения падучести deadbeef'овости).
Вопрос наличия или нет вендорлока на специалиста — вопрос производственной архитектуры, а не решения 'netapp или нет'. С netapp'ом ровно так же можно накрутить столько, что мало не покажется.
Вендорлок по имени 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 не требюет наличия в штате квалифицированного персонала, так как наш саппорт решает за клиента все проблемы, связанные с хранилищем, его конфигурацией и интеграцией в используемые системы». Так?
Дело не в «заранее бояться».
Дело в том, что тестирование «ни о чем».
Вернее о том, что правильная методика — рулит. :)
А так получается тестирование скорости автомобилей разных марок, выйдя на улицу, и с секундомером замерив скорость десятка проехавших мимо автомобилей, а затем делая глубокомысленные выводы на основе результатов: «А смотри ка, ВАЗ-классика-то — самый быстрый!» А он может быстрый, потому что вам попалось два подряд джихад-такси, которым пофиг на правила :)
Это в случае самого Оверсана можно быть уверенным, что предоставлена максимальная производительность дисков, но отчего авторы решили, что какой-нибудь 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
Я бы сказал, что это не тестирование авто, кто быстрей. А тестирование гостиниц. Вы клиент с улицы, то как вас быстро заселили показатель производительности персонала. Как клиенту в этих победили гостиницы Скалакси, terremark, rackspace.
Кстати, да.
Критерий отсева весьма странный: вы если техническую производительность тестируете, то какая разница по каким принципам происходят ее продажи?
Критерий отсева весьма странный: вы если техническую производительность тестируете, то какая разница по каким принципам происходят ее продажи?
Мы тестируем облачных провайдеров, и, в соответствии с нашими представлениями и стандартом NIST, таковыми не являются компании где виртуальные машины создаются вручную системными администраторами.
Хочется комментариев от amarao и damad, если честно (:
А сколько активных клиентов было на сторадже Скалакси при тестировании?
Ждем ответа от Clodo
Вот наш ответ:
Часть клиентов уже использует…
Подробности скоро…
Часть клиентов уже использует…
Подробности скоро…
Не из-за этого ли теста вчера днём вы упали?
Если вы так уверены в себе, почему не заказали независимое тестирование?
А так-объективность весьма сомнительная, чистый PR…
А так-объективность весьма сомнительная, чистый PR…
Мы с удовольствием снабдим вас необходимыми ресурсами, если вы захотите объективно повторить подобный тест.
(от имени Селектела).
SAN у нас работает на 10G, а не на гигабите. У нас используется шейпинг (чтобы один клиент, решивший поиграться с iozone/bonnie++ не создал затруднений соседям). Шейпинг работает чуть дальше кеша (то есть вы сможете получить неожиданные пики по чтению/записи, но не сможете нагрузить нашу дисковую подсистему насмерть). Плюс, мы используем intellicache.
Ваши тесты меня очень озадачили, вы сильно увеличили нагрузку. График загрузки дисков (график уже после кеша, то, что кеш пробило):
SAN у нас работает на 10G, а не на гигабите. У нас используется шейпинг (чтобы один клиент, решивший поиграться с iozone/bonnie++ не создал затруднений соседям). Шейпинг работает чуть дальше кеша (то есть вы сможете получить неожиданные пики по чтению/записи, но не сможете нагрузить нашу дисковую подсистему насмерть). Плюс, мы используем intellicache.
Ваши тесты меня очень озадачили, вы сильно увеличили нагрузку. График загрузки дисков (график уже после кеша, то, что кеш пробило):
тобишь по рукам клиенту не успели дать за такие iops'ы?
зачем по рукам? чем больше клиент генерит иопсов, тем больше он их покупает. :)
вопрос только в том, что бы один плохой не мешал соседям с диском работать.
вопрос только в том, что бы один плохой не мешал соседям с диском работать.
Зачэм быт да? Лучше болше хади болше дэнга плати.
Ради этого и задумывалось — для нас нет плохих клиентов (кроме спамеров и т.д.) — что бы клиент в машине не вытворял, мы с этого деньги получим.
Взмен, клиенты, которые делают по 1к операций в день спокойно лежат и не платят лишнего.
Ради этого и задумывалось — для нас нет плохих клиентов (кроме спамеров и т.д.) — что бы клиент в машине не вытворял, мы с этого деньги получим.
Взмен, клиенты, которые делают по 1к операций в день спокойно лежат и не платят лишнего.
Для уточнения, что есть до кеша, а то после — с какой стороны смотрите на кеш? «до кеша» — это ближе к дисками или ближе к вм-кам?
Да, наоборот, шейпинг в облаке обязан быть. Я имея там виртуалку, совсем бы не хотел, что бы меня тормозили например ваши тесты. Пусть лучше вас ограничат в полосе, но у меня латентность дисковых операций не изменится.
Так что пока тесты не совсем адекватны, вы видите то, что происходит с высоконагружающей систему виртуалкой, но не видите, на сколько это влияет на соседей. Если получили рекордный иопс, но все соседи тормозили по страшному — то нафиг такой хостинг. А если получили умеренный, но соседи даже не почесались — вот это хорошее решение.
Так что пока тесты не совсем адекватны, вы видите то, что происходит с высоконагружающей систему виртуалкой, но не видите, на сколько это влияет на соседей. Если получили рекордный иопс, но все соседи тормозили по страшному — то нафиг такой хостинг. А если получили умеренный, но соседи даже не почесались — вот это хорошее решение.
Латентность изменится, увы, контролировать это сложно, но у нас есть некие рамки, которые мы более-менее можем сдерживать (то есть можно запросто получить 10мс вместо 2мс из-за засранца рядом). Увы, технологии контроля дисков только-только развиваются, и точного представления что с этим делать пока нет.
Какие-то наброски (идеи) есть, но в жизнь мы их пока не закодировали.
Какие-то наброски (идеи) есть, но в жизнь мы их пока не закодировали.
Мы написали, что шейпинг временно выключен и включится, когда мы сделаем отдельно регулируемую ширину канала для каждого диска.
выключен он у вас (то есть в этот момент 1. можно было получить всю полосу 2. затормозить соседние виртуалки).
а включен (если есть) у других тестируемых участников он или нет — вы не знаете.
то есть у себя вы лимиты сняли и показали рекордный иопс, а что и как настроено у остальных — неизвестно. по этому обзор бессмысленный.
а включен (если есть) у других тестируемых участников он или нет — вы не знаете.
то есть у себя вы лимиты сняли и показали рекордный иопс, а что и как настроено у остальных — неизвестно. по этому обзор бессмысленный.
ну не совсем бессмысленный — клиенты хоть знают, чего ждать…
а чего ждать от включения шейпинга у скалакси? может он после этого скатится в самый низ графика?
После этого сколько купите, столько и будет. При это уровень гарантии будет на порядки выше остальных провайдеров.
я могу купить все, и увеличить латентность диска для всех соседей?
Если вы купите все, мы сделаем для вас отдельный кластер, а курьером, который привезет вам договор будет Анджелина Джоли или любое другое существо по вашему выбору.
На механических дисках — да, есть вероятность, что латентность у соседей по диску увеличится. На SSD соседи ничего не заметят. SSD дисков правда уже нет в панели, так как весь объем давно продан, но в будущем опять появятся.
На механических дисках — да, есть вероятность, что латентность у соседей по диску увеличится. На SSD соседи ничего не заметят. SSD дисков правда уже нет в панели, так как весь объем давно продан, но в будущем опять появятся.
Еще раз повторю, в облачных СХД самое главное — производительность произвольных операций чтения и записи. Шейпить эти операции отдельно от последовательных никто не умеет — 100%. Ну а так как у всех провайдеров произвольные тесты сильно отличаются от последовательных, то значит на результат первых никакой шейпинг не влияет и они зависят только от общей производительности системы.
Ну а поскольку основной профиль нагрузки интернет-проектов — произвольные операции в БД или с мелкими файлами, наша система очень хорошо решает эти задачи.
Ну а поскольку основной профиль нагрузки интернет-проектов — произвольные операции в БД или с мелкими файлами, наша система очень хорошо решает эти задачи.
НЛО прилетело и опубликовало эту надпись здесь
Антиреклама Скалакси прежде всего. До сих пор мне как-то они казались более «вменяемыми» и понимающими предмет. :(
Но выкатывать на хабр такую шитую белыми нитками заказуху… Причем лучше бы если бы это была заказуха, потому что если люди в самом деле верят в то, что они «намеряли», вот в таком случае все куда хуже.
Но выкатывать на хабр такую шитую белыми нитками заказуху… Причем лучше бы если бы это была заказуха, потому что если люди в самом деле верят в то, что они «намеряли», вот в таком случае все куда хуже.
Простите за глупость, но помогите разобраться, как вы получили итоговую таблицу данных? Помогите на примере:
screenlog.scalaxy.1:
screenlog.scalaxy.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
Как из этих исходных данных вы получили те данные, которые у вас в гугл-таблице?
Для сравнения, вот данные с hetzner eq8:
8388608 4 41963 38170 1514434 1525684 1004891 1847
8388608 4 41963 38170 1514434 1525684 1004891 1847
Судя по 1514434, количество RAM на этой виртуалке много больше 512 МБ. Перечитайте методику теста.
Зная о eq8 то 24 GB DDR3 RAM
К стати почему именно 512 у вас?
К стати почему именно 512 у вас?
При объеме файла в тесте 15 ГБ он полностью укладывается в оперативную память виртуальной машины (24 ГБ в случае eq8), и тогда тест чтения показывает скорость чтения из оперативной памяти, а не из системы хранения.
512 МБ мы выбрали как минимальный размер доступный у большинства провайдеров, чтобы память не влияла на тесты чтения.
512 МБ мы выбрали как минимальный размер доступный у большинства провайдеров, чтобы память не влияла на тесты чтения.
Да, к сожалению забыл про это. Действительно, у hetzner всего 24GB. Но если всё пересчитать на деньги, то у вас за аналогичную стоимость будет 3.5GB. Во сколько раз, примерно, увеличатся исходные показатели из ваших тестов на 512MB?
Очень просто, берем столбцы 3 (линейная запись), 5 (линейное чтение), 6 (произвольная запись), 7 (произвольное чтение) и передаем функции AVERAGE в Google spreadsheets.
Мне, эти «тесты», напоминают тесты от Microsoft, в котором IE9 всегда впереди. Хотя, вроде все правильно и наглядно.
Ну-у-у, зайдите на блог EMC — там EMC впереди планеты всей и плевали они на всех с высокой колокольни. На блогах netapp — вам расскажут, что вы заплатите меньше получите больше, уникальный WAFL, супербыстрый flashcache и огого-и-эгегей. На мероприятии HP вам расскажут, что дескать мы уже порвали почти всех, винты у нас быстрее, кешы больше, фибра фибрастей и надо брать. Маркетинг. Он как религия.
«слишком медленно, что бы использовать на реальных приложениях» — вы бы, коллеги, сначала спросили у реальных приложений. Это раз.
Плюс к тому — небольшой логический реверанс: «коллеги, работающие с первой версией нашей архитектуры 2008 года» + «слишком медленно, что бы использовать на реальных приложениях» == «мы были неюзабельными и водили за нос клиентов, пока нас не клюнул жареный петух, и мы не поменяли архитектуру». Мы ценим ваше качественное развитие, скоро и у нас, что тут скрывать, ожидается обновление СХД. Но такие категоричные выводы вам совершенно не идут.
Тем более, что есть разные методики тестирования и результаты какой из них говорят о реальных ощущениях клиента — это большой вопрос. Ну и еще один вопрос — это самочувствие клиентов-соседей при проведении тестов.
Плюс к тому — небольшой логический реверанс: «коллеги, работающие с первой версией нашей архитектуры 2008 года» + «слишком медленно, что бы использовать на реальных приложениях» == «мы были неюзабельными и водили за нос клиентов, пока нас не клюнул жареный петух, и мы не поменяли архитектуру». Мы ценим ваше качественное развитие, скоро и у нас, что тут скрывать, ожидается обновление СХД. Но такие категоричные выводы вам совершенно не идут.
Тем более, что есть разные методики тестирования и результаты какой из них говорят о реальных ощущениях клиента — это большой вопрос. Ну и еще один вопрос — это самочувствие клиентов-соседей при проведении тестов.
Чувствую «топор войны» откопали-будем ждать «тестов Скалакси» от Селектел и Clodo.)
Ага, нагрузка на все хранилище уже выросла в 6 раз с момента публикации поста.
Черный Властелин атакует хранилище!
Ну и как? 300МБ/с держите?
300Мегабайт в секунду — это примерно три гигабита.
SAS-порт даёт шесть гигабит, тобишь держит на заявленных 300МБ/сек две виртуальные машинки. Ещё один SAS-порт держит те-же самые две машинки во второй половинке зеркала.
То-есть, чтобы держать 300Мб/сек. на тысяче, даже не клиентов, а виртуальных машин, без учёта кэширования, и с учётом зеркалирования, необходимо иметь:
500 SAS портов X 2 половинки зеркала == 1000 SAS-портов.
То-есть по одному SAS-порту на каждую виртуальную машину?
SAS-порт даёт шесть гигабит, тобишь держит на заявленных 300МБ/сек две виртуальные машинки. Ещё один SAS-порт держит те-же самые две машинки во второй половинке зеркала.
То-есть, чтобы держать 300Мб/сек. на тысяче, даже не клиентов, а виртуальных машин, без учёта кэширования, и с учётом зеркалирования, необходимо иметь:
500 SAS портов X 2 половинки зеркала == 1000 SAS-портов.
То-есть по одному SAS-порту на каждую виртуальную машину?
Честно говоря, лучший ответ на «наброс на вентилятор» — игнор.
Нет, я не планирую меряться пиписьками. Собрать охрененно быстрое хранилище можно — его будет невозможно окупить. Основной момент — обеспечить требуемую производительность в разумные деньги и при этом ещё не потерять надёжность.
А ты провел тестирование СХД конкурентов? 
Когда-то на Хабре пробегал такой слайд- «Есть ложь, наглая ложь и есть бенчмарки».
А по сути — мне просто интересно ЗАЧЕМ вбухали столько бабла а стореджи, интерконнект и IOPS'ы??
Дайте клиентам много дешевого RAM и guestOS сами накешат то что нужно.
А по сути — мне просто интересно ЗАЧЕМ вбухали столько бабла а стореджи, интерконнект и IOPS'ы??
Дайте клиентам много дешевого RAM и guestOS сами накешат то что нужно.
Не всё, увы. В рамках той теории, которую мы используем, есть т.н. «злые иопсы», которые в любом случае пройдут на самый низкий уровень хранения через все кеши.
Какой процент «злых иопсов» в общем? Большинство клиентов держат web и небольшые db которые влазят в RAM. Но у вас RAM дорогой — поэтому берут 512 MB и засовуют в него систему и 2 гига db, что чревато нагрузкой на СХД.
Среди тех кому действительно нужно много IO — те кто криво настроил os и db или те у кого бизнес-логика на уровне db(но такие не юзают общественные cloud'ы).
Среди тех кому действительно нужно много IO — те кто криво настроил os и db или те у кого бизнес-логика на уровне db(но такие не юзают общественные cloud'ы).
У большинства проектов >20k уникальных посетителей в месяц БД в память не влазит, а диски являются самым узким местом.
Любое уникальное чтение является «злым». До тех пор, пока у нас кеш меньше устройства хранения, то злые иопсы будут всегда. Даже запись можно закешировать (у нас intellicache на графике хорошо видно — записи много меньше, чем чтения), а вот рандомное первое чтение — нет.
Я недавно занимался переносом одного мелкого торент трекера с посещаемостью около 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 в час пик?
Думал отправить в ЛС, но вдруг кто-нибудь другой подскажет, что лучше сделать в этой ситуации?
Думал отправить в ЛС, но вдруг кто-нибудь другой подскажет, что лучше сделать в этой ситуации?
При таких нагрузках долго масштабировать в лоб, вертикально, не получится. как минимум придется переходить к настоящему FastCGI и накапливать данные для обновлением пачкой за один запрос. Но рано или поздно придется трекер переписывать в самостоятельный постоянно работающий демон для нормального кэширования данных и минимизации обращений к внешней БД.
И да, посещаемость в униках для трекера не показательна, интереснее максимальное(пиковое) суммарное число активных торрентов по всем пользователям и время между анонсами.
И да, посещаемость в униках для трекера не показательна, интереснее максимальное(пиковое) суммарное число активных торрентов по всем пользователям и время между анонсами.
Посещаемость, которую я указал выше — это данные из Google Analytics. Т.е. это статистика только по «главной страничке форума». А обычная статистика с анонсера такая: пиров >600к, раздающих >400к, скачивающих >150к. В дни, когда какая-нибудь «новинка» то +10-20%.
Думаете, всё-таки нужно начинать оптимизировать программную часть самого форума и анонсера?
Думаете, всё-таки нужно начинать оптимизировать программную часть самого форума и анонсера?
Лично мое мнение — да. Даже если предположить довольно скромное время анонса 30 минут, получается около 350 запросов в секунду к трекеру, что выливается в 1-2 миллиона запросов в секунду к базе данных в зависимости от удачности архитектуры — это уже большая нагрузка, особенно учитывая что примерно половина запросов это запись.
Вообще, если база полностью в памяти — не совсем понятно, зачем вам SSD.
Для справки — трекер nnm-club(на C++) работает в 1 поток и потребляет меньше 1GB памяти.
Вообще, если база полностью в памяти — не совсем понятно, зачем вам SSD.
Для справки — трекер nnm-club(на C++) работает в 1 поток и потребляет меньше 1GB памяти.
Время анонса 30 минут. Запросов в секунду в обычном режиме около 450, в пике доходило до 800. На SSD OCZ Agility-2 файлы форума. А по софту — используем всем известный ppkbb3cker с оригинальным анонсером, который, по хорошему, надо заменить на xbtt.
Вообщем ясно. Будем значит оптимизировать программную часть. Спасибо.
Вообщем ясно. Будем значит оптимизировать программную часть. Спасибо.
Они убили Кенни Clodo…
Clodo — коллеги, работающие с первой версией нашей архитектуры 2008 года, IBM GPFS хранилище, решение на базе Xen.Какой тонкий троллинг =)
Вопрос к автору исследований.
Вот это ваше кеширование как отражается на целостности данных? К примеру, произведена транзакция и сервер кеширования падает. Транзакция на диске не запечатлена — только в ОЗУ на сервере кеширования? Получается нет гарантии целостности данных?
Вот это ваше кеширование как отражается на целостности данных? К примеру, произведена транзакция и сервер кеширования падает. Транзакция на диске не запечатлена — только в ОЗУ на сервере кеширования? Получается нет гарантии целостности данных?
Скорости не так интересны как средние/максимальные задержки случайного чтения/записи, так как именно они влияют на скорость формирования страниц и отзывчивость сайта в целом. Очень странно что вы их не указали…
Вводная информация не точна. IT-GRAD предлагает почасовую тарификацию (pay-as-you-go). Кроме того интерфейс vCloud позволяет самостоятельно создавать машины без обращений в службу поддержки + есть развитый API.
А если говорить про сам топик — тестирование производительности дисковой подсистемы — то в нашем SLA содержатся специальные метрики — max Latency и min IOPS, которые могут быть оптимизированы под конкретных корпоративных заказчиков.
А если говорить про сам топик — тестирование производительности дисковой подсистемы — то в нашем SLA содержатся специальные метрики — max Latency и min IOPS, которые могут быть оптимизированы под конкретных корпоративных заказчиков.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование дисков облачных провайдеров