Во-первых, Amazon EC2 — это Amazon Elastic Computing Cloud, термин употребляется с 2007 года и именно эта компания одна из тех, что задали тренд cloud computing в мире.
Во-вторых, есть стандарт NIST, где все написано, что не было подобных недопониманий. По которому, Amazon EC2, Rackspace Cloud, GoGrid и Скалакси — public clouds.
В-третьих, 120 CPU легко — поднимите 8 машин. Хотите через панель, хотите через HTTP REST API. Оплата по часам, не хотите — уберите. Это и называют computing cloud.
Масштабирование происходит по памяти, как только системе необходима дополнительная память она выделяется модулем ядра (в пределах стартового и максимального значения памяти, указанных в конфигурационном файле domU Xen). На данный момент считается реально задействованная память плюс около 100 Mb сверх (высвечивается как free + cached). В ближайшее время алгоритм будет еще больше модифицирован для того, чтобы полностью уйти от данных накладных расходов.
Процессор — на каждые 256 мегабайт памяти мы выделяем гарантированно 6% CPU (регулируем весами).
В ближайших планах также динамическое выделение диска (оплата не за весь размер, а именно за использованный).
Боюсь, что пятьюстами иопсами можно положить только совсем уж недорогие полки.
Полки — они все не дешевые. так что в большинстве фирм, которые таки перешли на СХД стоят entry level, это данность.
Да, у меня была возможность пользоваться XP 20000, но это исключение, по этому невысокие iops это то, что мы имеем сейчас в реальности. Давай исходить из этого.
А приведенные цифры от разработчиков — это сферический конь в вакууме. Очень многое зависит от интерфейса (iscsi/sas/fc), от контроллеров полки, да и от самих хардов — контроллеры на них бывают разные, оборотистость разная.
Самое узкое место — это как раз сами диски. Все остальное — контроллеры, транспорт значительно быстрее и не являются узким местом.
Вот голые цифры, которые дают винты на маленьких блоках (в худшем случае) которые используются сейчас для расчета сторов: «SAS 15k — 180, SAS 10k — 140, SATA 7200 — 80, SATA 5400 — 40». Это среднее по больнице, но инсайдеры утверждают, что девиации там не больше 5% в зависимости от производителя/модели.
То есть в простом случае, что бы получить 500 иопсов нам нужен рейд из 4-5 дисков, без redundancy.
Еще очень многое зависит от типа операций (рандом, последовательно, запись, чтение) и разумеется — от типа массива.
Конкретная производительность одного диска зависит от нескольких входных характеристик:
— размер блока (от 512 байт до мегабайт)
— тип обращения (соотношение чтение/запись)
— случайный, последовательный или смешанный доступ
— длительность (всплеск, устойчивая, переменная нагрузка)
— геометрия данных на диске (частичное, полное заполнение, внешний или внутренний край пластины, плотности записи, итп)
При последовательном чтении блоками по 512 Байт один диск может обслуживать до 800 IOPS (это предел процессора диска).
При многопоточном случайном чтении блоками по 8КБ можно достичь 280 IOPS
При многопоточном случайном чтении блоками по 64КБ можно достичь всего 240 IOPS (больше времени нужно на непосредственную передачу данных)
И далее, чем больше размер блока, тем меньше IOPS может выдать диск.
На практике, обычно используют вышеприведенные немного более консервативные значения. И дело тут во времени отклика.
Время отклика определяет, например, промежуток времени между операциями ввода-вывода одного пользователя (одного из многих потоков запросов). Если время отклика большое, то пользователи жалуются что невозможно работать, и «система тормозит». И им все равно, что система обслуживает 1000 таких как они, а суммарное количество выполняемых IOPS зашкаливает за 2000. Им важно что лично у них тормозит почта. Система работает на пределе возможного, но среднее время отклика 50-100 мс, субъективно «сервер работает очень медленно», а приложения постоянно «подвисают». Зато, когда нагрузка низкая, или пользователей мало, у них «все летает». Суммарное к-во IOPS не больше 200, зато время отклика 5 мс и к тому же стабильно. Значит «производительность хорошая». Однако, когда спрашивают про производительность дисков, все равно часто хотят услышать именно про IOPS-ы.
Чем выше максимум, тем лучше время отклика в нижней и средней части шкалы производительности.
При почти нулевой загрузке диска response time равно service time, которое является временем необходимым на выполнение одной операции без учета очередей.
При случайном доступе к данным, этот параметр вычисляется по формуле:
Service Time = Disk Rotational Latency + Average Disk Seek Time
что для диска 15К rpm дает 2мс + 4 мс = 6 мс
До тех пор пока очередей на диске нет (Utilization 0%), этот параметр сохраняется почти на одном и том же уровне.
Утилизация определяется соотношением нагрузки на диск к максимально достижимой производительности.
Utilization% = Current IOPS / Max IOPS
Чем ближе загрузка диска к максимально возможной, тем больше время отклика.
При 100% загруженности диска время отклика растет до бесконечности (т.е. растет очередь запросов, которые диск физически не может обслужить).
Формула связывающая response time, service time и утилизацию диска основана на законе обслуживания очередей (законе Литла) и опирается на факт, что диск может обслуживать только одну операцию в один момент времени (имеется ввиду традиционный механический диск). Response Time = Service Time / (1-Utilization%)
Например, для диска работающего в режиме многопоточного случайного чтения блоками по 8КБ со скоростью 140 IOPS (50% от предельных 280 IOPS на 8КБ блоках) среднее время отклика составит 6 мс/(1-50%)=12 мс.
В целом, процесс прецизионного расчета производительности СХД, хотя технически возможен, но достаточно сложен и должен учитывать множество нюансов. Поэтому, в первом приближении берутся вышеуказанные, рекомендуемые производителем показатели производительности для дисков разного типа.
Во-вторых, есть стандарт NIST, где все написано, что не было подобных недопониманий. По которому, Amazon EC2, Rackspace Cloud, GoGrid и Скалакси — public clouds.
В-третьих, 120 CPU легко — поднимите 8 машин. Хотите через панель, хотите через HTTP REST API. Оплата по часам, не хотите — уберите. Это и называют computing cloud.
Процессор — на каждые 256 мегабайт памяти мы выделяем гарантированно 6% CPU (регулируем весами).
В ближайших планах также динамическое выделение диска (оплата не за весь размер, а именно за использованный).
а можно немного детальней?
–195-й в рейтинге хабралюдей
Популярность вашего сервиса растёт с огромной скоростью!
Полки — они все не дешевые. так что в большинстве фирм, которые таки перешли на СХД стоят entry level, это данность.
Да, у меня была возможность пользоваться XP 20000, но это исключение, по этому невысокие iops это то, что мы имеем сейчас в реальности. Давай исходить из этого.
Самое узкое место — это как раз сами диски. Все остальное — контроллеры, транспорт значительно быстрее и не являются узким местом.
Вот голые цифры, которые дают винты на маленьких блоках (в худшем случае) которые используются сейчас для расчета сторов: «SAS 15k — 180, SAS 10k — 140, SATA 7200 — 80, SATA 5400 — 40». Это среднее по больнице, но инсайдеры утверждают, что девиации там не больше 5% в зависимости от производителя/модели.
То есть в простом случае, что бы получить 500 иопсов нам нужен рейд из 4-5 дисков, без redundancy.
Конкретная производительность одного диска зависит от нескольких входных характеристик:
— размер блока (от 512 байт до мегабайт)
— тип обращения (соотношение чтение/запись)
— случайный, последовательный или смешанный доступ
— длительность (всплеск, устойчивая, переменная нагрузка)
— геометрия данных на диске (частичное, полное заполнение, внешний или внутренний край пластины, плотности записи, итп)
При последовательном чтении блоками по 512 Байт один диск может обслуживать до 800 IOPS (это предел процессора диска).
При многопоточном случайном чтении блоками по 8КБ можно достичь 280 IOPS
При многопоточном случайном чтении блоками по 64КБ можно достичь всего 240 IOPS (больше времени нужно на непосредственную передачу данных)
И далее, чем больше размер блока, тем меньше IOPS может выдать диск.
На практике, обычно используют вышеприведенные немного более консервативные значения. И дело тут во времени отклика.
Время отклика определяет, например, промежуток времени между операциями ввода-вывода одного пользователя (одного из многих потоков запросов). Если время отклика большое, то пользователи жалуются что невозможно работать, и «система тормозит». И им все равно, что система обслуживает 1000 таких как они, а суммарное количество выполняемых IOPS зашкаливает за 2000. Им важно что лично у них тормозит почта. Система работает на пределе возможного, но среднее время отклика 50-100 мс, субъективно «сервер работает очень медленно», а приложения постоянно «подвисают». Зато, когда нагрузка низкая, или пользователей мало, у них «все летает». Суммарное к-во IOPS не больше 200, зато время отклика 5 мс и к тому же стабильно. Значит «производительность хорошая». Однако, когда спрашивают про производительность дисков, все равно часто хотят услышать именно про IOPS-ы.
Чем выше максимум, тем лучше время отклика в нижней и средней части шкалы производительности.
При почти нулевой загрузке диска response time равно service time, которое является временем необходимым на выполнение одной операции без учета очередей.
При случайном доступе к данным, этот параметр вычисляется по формуле:
Service Time = Disk Rotational Latency + Average Disk Seek Time
что для диска 15К rpm дает 2мс + 4 мс = 6 мс
До тех пор пока очередей на диске нет (Utilization 0%), этот параметр сохраняется почти на одном и том же уровне.
Утилизация определяется соотношением нагрузки на диск к максимально достижимой производительности.
Utilization% = Current IOPS / Max IOPS
Чем ближе загрузка диска к максимально возможной, тем больше время отклика.
При 100% загруженности диска время отклика растет до бесконечности (т.е. растет очередь запросов, которые диск физически не может обслужить).
Формула связывающая response time, service time и утилизацию диска основана на законе обслуживания очередей (законе Литла) и опирается на факт, что диск может обслуживать только одну операцию в один момент времени (имеется ввиду традиционный механический диск). Response Time = Service Time / (1-Utilization%)
Например, для диска работающего в режиме многопоточного случайного чтения блоками по 8КБ со скоростью 140 IOPS (50% от предельных 280 IOPS на 8КБ блоках) среднее время отклика составит 6 мс/(1-50%)=12 мс.
В целом, процесс прецизионного расчета производительности СХД, хотя технически возможен, но достаточно сложен и должен учитывать множество нюансов. Поэтому, в первом приближении берутся вышеуказанные, рекомендуемые производителем показатели производительности для дисков разного типа.