У RISC-V есть проблемы в том числе на уровне ISA. Например там отсутствует как класс все связанное с работой с кэшом (нет инструкций, которыми можно инвалидировать кэш, например). Это обещают поправить в следующих ревизиях, только вот пока их посмотрят, пока начнут производители железа использовать...
Это все можно назвать "сырой", можно "молодой и динамично развивающейся" - суть та же - есть шанс что детские проблемы со временем исправят. Но в текущий момент они немного ограничивают сферы применения архитектуры.
Брендированность по мнению `lspci` не означает, что это своя разработка, а не лицнезированный IP. По хорошему разработчики должны говорить какие IP-блоки они используют сторонние в конкретном процессоре.
Эльбрусы в России не производились по 65нм, как минимум потому что 65нм в РФ только у Микрона и он помечен как "образцы изделий получены" или что-то в таком духе. То что прошлые варианты делались по 65нм TSMC не значит, что на Микроновских 65нм, когда они будут готовы для сложных чипов, получится получить похожие характеристики.
Еще не надо забывать, что по транзисторному бюджету Эльбрусы - достаточно сложные чипы и транзисторный бюджет у них ого-го по меркам массового рынка. Например для Эльбрус-4С, который делался по 65нм, указано что чип содержит 980+ млн транзисторов. Для сравнения, на 65нм выпускался Итаниум с 2 млрд, GeForce GTX 280 с 1.4 млрд, Power6 с 800 млн, Pentium D с 400 млн. - то есть были конечно чипы крупнее, но их было не так чтобы очень много.
Ну и касательно частот - то что на 65нм TSMC можно было выжать 800 МГц (см. Эльбрус-4С) не значит что на 65нм Микрона, когда он будет готов, удастся даже близко к таким показателям подобраться и выпускать настолько сложные чипы.
А на Микроне делали Эльбрус-1СК или как-то так, одно ядро, 90нм, 300 Мгц частоты.
Кстати, с прошлым комментарием тоже не все в порядке - в С-300 и С-400 стоят вроде бы Эльбрус-90, которые к микроархитектуре Эльбрус отношнеия не имеют и являются SPARCv7.
Как сказали в соседнем комментарии — это образно, просто где-то в начале 2010-х уже использование заббикса считалось немного моветоном, к 2015 у меня среди друзей-знакомых не осталось никого кто бы на нем сидел.
Поделитесь, какие решения вы используете?
Я боюсь на текущем месте работы решение нерелевантно совсем, потому что оно полностью самодельное и все что о нем есть — это пара (точное количество не знаю, кажется что ровно два) докладов и один whitepaper (см. Monarch).
На прошлом месте работы достаточно неплохо чувствовал себя графит на потоке, в терминологиях заббикса, 2.5М NVPS (последняя цифра которую разрешили в свое время опубликовать, а не говорить абстрактно «миллионы»). Можете поискать старые доклады по ключевым словам «Graphite@Scale» — были на FOSDEM 2017 и еще на паре конференций, +- одинаковый уровень подробностей к сожалению.
Ну и почти уверен, что сейчас народ из Букинга тоже почитывает хабр и может рассказать что нового, может быть даже были доклады какие-то с тех пор (как я слышал там где-то появился Prometheus рядом, но деталей не знаю).
1. Я бы сказал, что первый шаг в этом направлении можно сделать уже сейчас — рассказать хотя бы вкратце об этом в комментариях. Потому что принятое вами решение мягко говоря не очень популярное, а цифры совсем не впечатляют (хотя они конечно в отрыве от железа) и поэтому вопрос «почему такое решение?» очень интересный.
2. Для систем мониторинга это нормально держать в компании одну команду, которая пилит систему для нужд всех, а всем остальным дает либо готовые рецепты как поднять, либо просто централизованную точку входа, полностью скрывая что там в ядре творится.
1. Обоснования этого момента нет в статье. А это как раз самое интересное в подобных статьях — что сравнивалось, какие причины решений, что не устроило в других и так далее.
Ну и решение очень субъективное, потому что у Заббикса в текущий момент репутация скажем так не лучшего решения на рынке.
2. Так это свойство всех более-менее взрослых решений. Впрочем что страшного в изменении кода? Мне кажется команда мониторинга в том числе и нужна для того чтоб допиливать выбранное решение под изменения задач и нагрузок, которые будут проходить.
Могу ошибаться, но есть интеграторы, на этом специализирующиеся. Просто без применения Эльбрусов в своем пакре железа.
Но Вы остальные моменты в сказанном почему-то игнорируете, а это важные вопросы для понимания почему так никто не сделал и никто не хочет делать в данный момент времени.
Бизнес обычно пытается предоставить что-то, что нужно рынку. В данном случаи должен быть ответ на вопрос «что бизнес может дать?» (он же «зачем?»)
Облако Эльбруса было бы в основном для России
Сейчас в России, если не ошибаюсь, несколько десятков облачных (или SaaS) провайдеров. Именно тех, которые держат российские компании.
а не для Запада, они бы этого не допустили…
Кто они? Чего бы не допустили? Не очень понятно, если честно.
Если Вы про Эльбрус на запад предоставлять — да я думаю МЦСТ не против, только не нужно.
Если наоборот, про облачного провайдера из России на запад — так собственно для западных компаний, когда они хотят соблюдать российские законы о ПД, это один из выборов сейчас. Конечно хороший вопрос сколько компаний используют облака, сколько держат свое, а сколько ничего не делают, но это уже отдельный вопрос.
Я все еще верю, что это нужно сделать, это нужно начать…
Главный момент того, о чем я написал это целесообразность. Такое облако, чтобы в него ехали, должно предоставлять что-то, что не предоставляют другие (сейчас российских облаков уже хватает, войти на рынок будет не так просто даже со стандартными предложениями).
Вообще у любого бизнеса или инициативы должен быть четкий ответ на вопрос «зачем?».
ладно, если у нынешнего 8С Эльбрус нет виртуализации, то виртуальную машину можно продать на физическом выделенном процессоре
Это уже не виртуальная машниа будет. Но, допустим, ок. Какая цена будет у такого решения, ориентировочно?
Я про несколько моментов тут:
1. Ваша оценка стоимости ничем не обоснована, так как стоимость 1 датацентра не публикуется, а также зависит от кучи параметров типа местности, желаемых характеристик датацентра и так далее и тому подобного. Вообще правильным подходом было бы прикинуть размеры (в серверах), прикинуть какая надежность нужна и посмотреть сколько за постройку такого просят те же компании в России, которые на этом специализируются (таковые есть). Но с этого момента у Вас хотя бы будет примерное понимание необходимой площади и хотя бы можно будет прикинуть сколько будет стоить построить здание и обеспечить его генераторами. Тут стоит не забыть, что далеко не в любой точке есть оптика, а если есть оптика то от нескольких независимых операторов, а если иесть то оператор может предоставить нужной ширины канал. Не везде можно найти несколько независимых поставщиков электроэнергии, не везде можно построить здание нужных размеров, не везде будет дешево его охлаждать. Короче много очень специфических тонкостей, которые очень сильно сузят круг доступных мест и повлияют на итоговую цену. И мы еще не трогаем процесс рассчета сети и требований к сети у ЦОДов облаков (советую посмотреть что найдете из публичного про это).
2. В современном мире, от гипервизора ожидаются низкие накладные расходы, то есть поддержка аппаратной виртуализации обязательна, а в Эльбрусах она заявлена только в 16С. Так что о «облаке» на 4С можно забыть
3. Попробуйте прикинуть стоимость услуг. Она будет зависеть и от расходов (электричество на питание и охлаждение это мягко говоря основные расходы датацентра) и от плотности размещения железа (сколько вы сможете предоставить условных виртуальных машин без оверселлинга по цпу и оперативной памяти, сколько диска сможете предоставить и так далее). И не забудьте, что сделать хранилище на 1 ПБ недостаточно, нужно еще уметь отдавать трафик (пропускная способность, ее требования для CDN отличаются от требований для SAN), шифровать его и т.п.
4. Уточните как Netflix, Dropbox и Spotify используют облака. Они не очень многословны, но говорят достаточно много о своей инфраструктуре. У Вас сейчас неверное понимание паттернов использования (например Dropbox еще в рамках IPO своего описывал как они увозили хранилища с амазона и почему)
5. Вы немного недооцениваете паттерн использования облак «как хранилища». У них вышло потому что они для себя уже решили задачу как быстро и надежно отдавать контент близко к пользователю (охват того же CDN от амазона начинался с нескольких датацентров на каждом континенте, то же и у других). Иначе — в чем преимущество решения из двух датацентров где-то в России? Кому они сделают лучше и как?
6. Собственно вытекает из (5). Основной пункт который продавал облака их первым клиентам — они делали жизнь другим компаниям проще. Например больше не надо было делать свой CDN или платить компаниям, на нем специализирующимся (которые тоже не всех устраивали по ряду причин), если тебе понадобилась виртуалочка в США, Европе и Австралии для твоих клиентов — один клик и через пару минут она готова. То есть это в первую очередь сервис, который решает реальные проблемы.
7. Вытекающий из (6). Недостаточно построить датацентр, нужно еще сделать софт, котоырй клиенты будут использовать (API, веб-интерфейсы, интеграция с имеющимися штуками типа Terraform'а).
8. Касательно тех у кого есть ЦОД — чтобы подтолкнуть их рыночным способом (особенно крупняк, на который Вы почему-то целитесь в первую очередь) Вам надо предложить им что-то что они не могут за разумное время сделать самостоятельно. А тут проблема в том, что как раз крупняку, который Вы перечислили, арендовать чужие облака вот совсем не интересно и никаким образом интересно не станет (единственный способ — скупить все Эльбрусы на годы вперед и протолкнуть закон, обязывающий комерческие организации использовать Эльбрусы для чего нибудь, и что-то мне подсказывает что такое решение будет нарушать несколько законов РФ).
Это очень кратко и без особых деталей я бы сказал.
Мне просто инетересно, смотрели ли Вы на конкретный сет бенчмарков и если да, почему он не понравился?
Как я уже сказал выше, он разивается достаточно давно и специально заточен под сравнение различных компиляторов (там множество тестов и их тщательно оптимизируют для каждого из тестируемых компиляторов). Кажется что это была бы более интересная и показательная синтетика даже для сравнения различных процессоров.
Мне кажется, Вы слишком оптимистичны в рассчете необходимых капиталовложений. У Вас с таким подходом выйдет не облако, а в лучшем случаи аренда серверов.
А про то, чтобы крупные российские компании туда захотели переносить что-то — это вообще невыполнимая задача, потому что им это никоим образом не интересно по-умолчанию. Чтобы стало интересно надо из списка исключить тех, у кого свои ДЦ и десятилетия опыта содержания своей инфраструктуры и дополнительно сделать это выгодным для них (что отдельная сложная задача и напрямую упирается в соотношение цена/производительность железа).
p.s. и я не уверен что Ваша оценка в цене датацентра верна.
Спасибо за статью, понастальгировал. Словно вернулся лет на 20 назад, во времена когда 60k NVPS были хай-лоадом и pacemaker с corosync'ом считались хорошим решением.
Особенно полезно было бы для сравнения производительности разных языков, так как бенчмарки там годами допиливаются с точки зрения оптимизаций, есть обвязка, рисующая красивые и понятные графики и показывающая насколько какой компилятор работает медленее или быстрее (а также с измерением потребления ресурсов). Возможно между железом не самый оптимальный набор софта, но с точки зрения исследования производительности java vs c vs c++ vs php vs python будет более показательно, как мне кажется.
Да не то чтоб танцев с музыкой, просто репозиторий не от твоего дистрибутива получает более низкий приоритет и нужно всего лишь добавить правильный pinning. Логика apt'а в это месте очень хорошо документирована на самом деле и добавление файлика — дело пары минут буквально.
Это небольшой subset всех пакетов debian'а, вроде бы еще с патчами от МЦСТ сверху. Небольшой — потому что судя по официальным спискам там 2.3 тысячи пакетов доступно, а в Debian Stable — 60 с небольшим тысяч.
Так как это Debian-based, то apt там вроде бы вполне себе на месте, ведь apt это все же CLI для удобной работы с пакетами.
Просто взяв одну и ту же видеокарту, можно было бы так сказать бесплатно получить статью полезную в том числе для тех кто хочет увидеть бенчмарк процессора. Замена видеокарты на эталонном ПК просто выглядит как операция на 15 минут времени…
У RISC-V есть проблемы в том числе на уровне ISA. Например там отсутствует как класс все связанное с работой с кэшом (нет инструкций, которыми можно инвалидировать кэш, например). Это обещают поправить в следующих ревизиях, только вот пока их посмотрят, пока начнут производители железа использовать...
Это все можно назвать "сырой", можно "молодой и динамично развивающейся" - суть та же - есть шанс что детские проблемы со временем исправят. Но в текущий момент они немного ограничивают сферы применения архитектуры.
Брендированность по мнению `lspci` не означает, что это своя разработка, а не лицнезированный IP. По хорошему разработчики должны говорить какие IP-блоки они используют сторонние в конкретном процессоре.
Эльбрусы в России не производились по 65нм, как минимум потому что 65нм в РФ только у Микрона и он помечен как "образцы изделий получены" или что-то в таком духе. То что прошлые варианты делались по 65нм TSMC не значит, что на Микроновских 65нм, когда они будут готовы для сложных чипов, получится получить похожие характеристики.
Еще не надо забывать, что по транзисторному бюджету Эльбрусы - достаточно сложные чипы и транзисторный бюджет у них ого-го по меркам массового рынка. Например для Эльбрус-4С, который делался по 65нм, указано что чип содержит 980+ млн транзисторов. Для сравнения, на 65нм выпускался Итаниум с 2 млрд, GeForce GTX 280 с 1.4 млрд, Power6 с 800 млн, Pentium D с 400 млн. - то есть были конечно чипы крупнее, но их было не так чтобы очень много.
Ну и касательно частот - то что на 65нм TSMC можно было выжать 800 МГц (см. Эльбрус-4С) не значит что на 65нм Микрона, когда он будет готов, удастся даже близко к таким показателям подобраться и выпускать настолько сложные чипы.
А на Микроне делали Эльбрус-1СК или как-то так, одно ядро, 90нм, 300 Мгц частоты.
Кстати, с прошлым комментарием тоже не все в порядке - в С-300 и С-400 стоят вроде бы Эльбрус-90, которые к микроархитектуре Эльбрус отношнеия не имеют и являются SPARCv7.
forum.beagleboard.org/t/imagination-gpu-for-beaglev-riscv-sbc/28883/5 тут один из разработчиков упоминал что у них есть бета-версия борды с StarFive 7100, но продакшн-версия будет с 7110.
Последняя — 4 ядра U74 и графика от PowerVR на борту, а первая — 2 ядра и без графики. В статье этого просто не сказано.
Как сказали в соседнем комментарии — это образно, просто где-то в начале 2010-х уже использование заббикса считалось немного моветоном, к 2015 у меня среди друзей-знакомых не осталось никого кто бы на нем сидел.
Я боюсь на текущем месте работы решение нерелевантно совсем, потому что оно полностью самодельное и все что о нем есть — это пара (точное количество не знаю, кажется что ровно два) докладов и один whitepaper (см. Monarch).
На прошлом месте работы достаточно неплохо чувствовал себя графит на потоке, в терминологиях заббикса, 2.5М NVPS (последняя цифра которую разрешили в свое время опубликовать, а не говорить абстрактно «миллионы»). Можете поискать старые доклады по ключевым словам «Graphite@Scale» — были на FOSDEM 2017 и еще на паре конференций, +- одинаковый уровень подробностей к сожалению.
Ну и почти уверен, что сейчас народ из Букинга тоже почитывает хабр и может рассказать что нового, может быть даже были доклады какие-то с тех пор (как я слышал там где-то появился Prometheus рядом, но деталей не знаю).
2. Для систем мониторинга это нормально держать в компании одну команду, которая пилит систему для нужд всех, а всем остальным дает либо готовые рецепты как поднять, либо просто централизованную точку входа, полностью скрывая что там в ядре творится.
Ну и решение очень субъективное, потому что у Заббикса в текущий момент репутация скажем так не лучшего решения на рынке.
2. Так это свойство всех более-менее взрослых решений. Впрочем что страшного в изменении кода? Мне кажется команда мониторинга в том числе и нужна для того чтоб допиливать выбранное решение под изменения задач и нагрузок, которые будут проходить.
Но Вы остальные моменты в сказанном почему-то игнорируете, а это важные вопросы для понимания почему так никто не сделал и никто не хочет делать в данный момент времени.
Бизнес обычно пытается предоставить что-то, что нужно рынку. В данном случаи должен быть ответ на вопрос «что бизнес может дать?» (он же «зачем?»)
Сейчас в России, если не ошибаюсь, несколько десятков облачных (или SaaS) провайдеров. Именно тех, которые держат российские компании.
Кто они? Чего бы не допустили? Не очень понятно, если честно.
Если Вы про Эльбрус на запад предоставлять — да я думаю МЦСТ не против, только не нужно.
Если наоборот, про облачного провайдера из России на запад — так собственно для западных компаний, когда они хотят соблюдать российские законы о ПД, это один из выборов сейчас. Конечно хороший вопрос сколько компаний используют облака, сколько держат свое, а сколько ничего не делают, но это уже отдельный вопрос.
Главный момент того, о чем я написал это целесообразность. Такое облако, чтобы в него ехали, должно предоставлять что-то, что не предоставляют другие (сейчас российских облаков уже хватает, войти на рынок будет не так просто даже со стандартными предложениями).
Вообще у любого бизнеса или инициативы должен быть четкий ответ на вопрос «зачем?».
Это уже не виртуальная машниа будет. Но, допустим, ок. Какая цена будет у такого решения, ориентировочно?
1. Ваша оценка стоимости ничем не обоснована, так как стоимость 1 датацентра не публикуется, а также зависит от кучи параметров типа местности, желаемых характеристик датацентра и так далее и тому подобного. Вообще правильным подходом было бы прикинуть размеры (в серверах), прикинуть какая надежность нужна и посмотреть сколько за постройку такого просят те же компании в России, которые на этом специализируются (таковые есть). Но с этого момента у Вас хотя бы будет примерное понимание необходимой площади и хотя бы можно будет прикинуть сколько будет стоить построить здание и обеспечить его генераторами. Тут стоит не забыть, что далеко не в любой точке есть оптика, а если есть оптика то от нескольких независимых операторов, а если иесть то оператор может предоставить нужной ширины канал. Не везде можно найти несколько независимых поставщиков электроэнергии, не везде можно построить здание нужных размеров, не везде будет дешево его охлаждать. Короче много очень специфических тонкостей, которые очень сильно сузят круг доступных мест и повлияют на итоговую цену. И мы еще не трогаем процесс рассчета сети и требований к сети у ЦОДов облаков (советую посмотреть что найдете из публичного про это).
2. В современном мире, от гипервизора ожидаются низкие накладные расходы, то есть поддержка аппаратной виртуализации обязательна, а в Эльбрусах она заявлена только в 16С. Так что о «облаке» на 4С можно забыть
3. Попробуйте прикинуть стоимость услуг. Она будет зависеть и от расходов (электричество на питание и охлаждение это мягко говоря основные расходы датацентра) и от плотности размещения железа (сколько вы сможете предоставить условных виртуальных машин без оверселлинга по цпу и оперативной памяти, сколько диска сможете предоставить и так далее). И не забудьте, что сделать хранилище на 1 ПБ недостаточно, нужно еще уметь отдавать трафик (пропускная способность, ее требования для CDN отличаются от требований для SAN), шифровать его и т.п.
4. Уточните как Netflix, Dropbox и Spotify используют облака. Они не очень многословны, но говорят достаточно много о своей инфраструктуре. У Вас сейчас неверное понимание паттернов использования (например Dropbox еще в рамках IPO своего описывал как они увозили хранилища с амазона и почему)
5. Вы немного недооцениваете паттерн использования облак «как хранилища». У них вышло потому что они для себя уже решили задачу как быстро и надежно отдавать контент близко к пользователю (охват того же CDN от амазона начинался с нескольких датацентров на каждом континенте, то же и у других). Иначе — в чем преимущество решения из двух датацентров где-то в России? Кому они сделают лучше и как?
6. Собственно вытекает из (5). Основной пункт который продавал облака их первым клиентам — они делали жизнь другим компаниям проще. Например больше не надо было делать свой CDN или платить компаниям, на нем специализирующимся (которые тоже не всех устраивали по ряду причин), если тебе понадобилась виртуалочка в США, Европе и Австралии для твоих клиентов — один клик и через пару минут она готова. То есть это в первую очередь сервис, который решает реальные проблемы.
7. Вытекающий из (6). Недостаточно построить датацентр, нужно еще сделать софт, котоырй клиенты будут использовать (API, веб-интерфейсы, интеграция с имеющимися штуками типа Terraform'а).
8. Касательно тех у кого есть ЦОД — чтобы подтолкнуть их рыночным способом (особенно крупняк, на который Вы почему-то целитесь в первую очередь) Вам надо предложить им что-то что они не могут за разумное время сделать самостоятельно. А тут проблема в том, что как раз крупняку, который Вы перечислили, арендовать чужие облака вот совсем не интересно и никаким образом интересно не станет (единственный способ — скупить все Эльбрусы на годы вперед и протолкнуть закон, обязывающий комерческие организации использовать Эльбрусы для чего нибудь, и что-то мне подсказывает что такое решение будет нарушать несколько законов РФ).
Это очень кратко и без особых деталей я бы сказал.
Как я уже сказал выше, он разивается достаточно давно и специально заточен под сравнение различных компиляторов (там множество тестов и их тщательно оптимизируют для каждого из тестируемых компиляторов). Кажется что это была бы более интересная и показательная синтетика даже для сравнения различных процессоров.
А про то, чтобы крупные российские компании туда захотели переносить что-то — это вообще невыполнимая задача, потому что им это никоим образом не интересно по-умолчанию. Чтобы стало интересно надо из списка исключить тех, у кого свои ДЦ и десятилетия опыта содержания своей инфраструктуры и дополнительно сделать это выгодным для них (что отдельная сложная задача и напрямую упирается в соотношение цена/производительность железа).
p.s. и я не уверен что Ваша оценка в цене датацентра верна.
salsa.debian.org/benchmarksgame-team/benchmarksgame
Особенно полезно было бы для сравнения производительности разных языков, так как бенчмарки там годами допиливаются с точки зрения оптимизаций, есть обвязка, рисующая красивые и понятные графики и показывающая насколько какой компилятор работает медленее или быстрее (а также с измерением потребления ресурсов). Возможно между железом не самый оптимальный набор софта, но с точки зрения исследования производительности java vs c vs c++ vs php vs python будет более показательно, как мне кажется.
Так как это Debian-based, то apt там вроде бы вполне себе на месте, ведь apt это все же CLI для удобной работы с пакетами.