IT в России и мире в реалиях мирового кризиса

Цитата: Брянский от 20.07.2016 14:12:01вы что то путаете
если 4 CPU и много дисков - то это вот такой корпус должен быть
https://www.supermicro.nl/products/chassis/4U/848/SC848A-R1K62.cfm

но там во первых 24 HDD, во вторых этот корпус до 2010 года точно не выпускался, а в третьих он относительно стандартный - у SuperMicro есть куча матерей который к нему походят.
судя по всему вы это все выдумали... не было никакого сервера
В описанный вами корпуса (3U типа SC836) ставятся только двухпроцессорные материнки

Мне как-то наплевать на ваше мнение, я точно с таким чудом от супермикро сталкивался и проблему запомнил. Собственно тот сервер и окончательно меня убедил в том, что с супермикро дел лучше не иметь.

Цитата: Брянский от 20.07.2016 14:12:50вы бредите - так не делается
вы судя по всему все это выдумали
какое нах быстродействие тут?
если такую хрень собрать на практике - то ноды будут постоянно синхронизироваться друг с другом!
между дисковыми системам нод будет постоянно гоняться огромный трафик.
какая нах обработка транзакций? нодам не до этого - они собой будут заняты
блин так никто никогда в нормальных организациях не делает!

кустари-одиночки с моторами.. слесари полесовы мать вашу

Будут мне продавцы самосборных серверов рассказывать про эксплуатацию хайлоад систем.
Кто сказал, про трафик между дисковыми системами? У меня реплицируются не блочные устройства, репликация осуществляется на уровне БД. Расходы на репликацию не очень и значительные. Репликация БД, между прочим, встречается очень часто и вполне регулярно используемое средство отказоустойчивости серверов БД и балансировки их нагрузки. Да и нагрузка на сеть/диск при репликации БД часто в разы меньше, чем при синхронизации блочных устройств.

Цитата: pkdr от 20.07.2016 14:25:25Мне как-то наплевать на ваше мнение, я точно с таким чудом от супермикро сталкивался и проблему запомнил. Собственно тот сервер и окончательно меня убедил в том, что с супермикро дел лучше не иметь.

вы откровенно лжете, и я вас поймал на лжи - одно из двух - либо такого сервера вообще не было, либо это была не платформа SuperMicro

Не было 10 лет назад у SuperMicro серверных платформ с 4 процессорами на 16 дисков... максимум 10 шт. и все!
Я естественно догадываюсь из чего вашу хрень можно было собрать..
но причем тут SuperMicro  то?

Цитата: pkdr от 20.07.2016 14:34:51Будут мне продавцы самосборных серверов рассказывать про эксплуатацию хайлоад систем.
Кто сказал, про трафик между дисковыми системами? У меня реплицируются не блочные устройства, репликация осуществляется на уровне БД. Расходы на репликацию не очень и значительные. Репликация БД, между прочим, встречается очень часто и вполне регулярно используемое средство отказоустойчивости серверов БД и балансировки их нагрузки. Да и нагрузка на сеть/диск при репликации БД часто в разы меньше, чем при синхронизации блочных устройств.

вы чушь сказали - в кластере не бывает просто репликация, там синхронизация между нодами по неartbeat.
Если у вас нет непрерывной синхронизации  между нодами, то это не кластер, а непонятно что.
И уж тем более без синхронизации невозможно в принципе распределять нагрузку между узлами.
А синхронизация БД на отдельных нодах без постоянной синхронизации локальных дисковых подсистем в случае когда нет единой СХД - невозможна
У вас постоянно идут транзакции на запись в БД, ведется журнал транзакций.. на дисках мля.. локально!
на каждом узле свой журнал! на дисках! БД журнал транзакций в ОЗУ не хранит! это принципиально!
она пишет его на диск, и пишет непрерывно!
Что вы тут нас лечите своими бредовыми фантазиями?
как вы можете синхронизировать БД на нодах не синхронизируя непрерывно диски?!
вы чушь городите - вы это не реализовывали, либо у вас все совсем не так как вы здесь описали!

если у вас веб-кластер - то так и скажите а не сношайте нам мозги
но там то БД вообще лежит на внешнем сервере а на нодах стоит только интерфейс пользователей который принимает из wan запросы пользователей и делегирует их к серверу бд
у вас так?

Цитата: Hadan от 20.07.2016 16:09:02Вы удивитесь, но на «нормальных» системах БД всегда лежит на отдельных серверах. Специфика.

а я разве утверждал обратное?
мы то как раз и обсуждаем именно сервера баз данных а не сервера приложений

Цитата: Hadan от 20.07.2016 16:09:02Вы удивитесь, но на «нормальных» системах БД всегда лежит на отдельных серверах. Специфика.

да кстати, отдельных от чего?
и что такое у вас нормальная БД - SAP? Oracle?

Цитата: Брянский от 20.07.2016 15:39:09вы откровенно лжете, и я вас поймал на лжи - одно из двух - либо такого сервера вообще не было, либо это была не платформа SuperMicro

Не было 10 лет назад у SuperMicro серверных платформ с 4 процессорами на 16 дисков... максимум 10 шт. и все!
Я естественно догадываюсь из чего вашу хрень можно было собрать..
но причем тут SuperMicro  то?

Вы можете говорить что угодно, но такой сервер был, так как я его видел своими глазами и щупал своими руками. И ответ сервиса официального дилера был 100% однозначным, "таких материнских плат больше нет и они сняты с производства". Лично я не в курсе, действительно это так, или дилер, который этот сервер поставил накосячил. Знаете, привык я себе и своим глазам доверять.

Цитата: pkdr от 20.07.2016 16:44:14Вы можете говорить что угодно, но такой сервер был, так как я его видел своими глазами и щупал своими руками. И ответ сервиса официального дилера был 100% однозначным, "таких материнских плат больше нет и они сняты с производства". Лично я не в курсе, действительно это так, или дилер, который этот сервер поставил накосячил. Знаете, привык я себе и своим глазам доверять.

вот как вы можете утверждать что это был сервер на платформе SuperMicro если вы не можете  назвать модель ни платформы, ни корпуса, ни материнской платы...
?
Причем я точно знаю что в 2006-2007 SuperMicro не выпускал ничего подобного.
И что такое официальный дилер у SuperMicro? Кто это? Назовите пожалуйста.
Вот уж не слышал про таких.. есть официальные дистрибуторы и OEM-партнеры... есть просто партнеры

Вы вообще представляете с кем спорите то? Людей знающих больше чем я про SuperMicro в РФ сильно меньше дюжины...

Цитата: Брянский от 20.07.2016 15:48:51вы чушь сказали - в кластере не бывает просто репликация, там синхронизация между нодами по неartbeat.

Ваша безапеляционность выдаёт вашу неосведомлённость.
Во-первых, heartbeat - это лишь одино из средств мониторинга и управления ресурсами кластера, их немало, например pacemaker или rgmanager из red hat cluster, лично я считаю лучшим rgmanager.
Во-вторых,  кластер - очень, очень широкое понятие, кластеры бывают очень разные, отказоустойчивые, масштабируемые, балансировки нагрузки, HPC (в русском языке нет устоявшегося выражения, можно называть "сверхвысокопроизводительными", очень мощные HPС называют суперкомпьютерами). И средства реализации этих кластеров бывают совершенно разными, на уровне оборудования, блочного устройства, файловой системы, операционной системы, сервиса, балансировщика, протокола. И весь этот зоопарк видов кластеров и способов их реализации вполне имеет право на жизнь и применяется в зависимости от задачи.

Цитата: ЦитатаЕсли у вас нет непрерывной синхронизации  между нодами, то это не кластер, а непонятно что.

И уж тем более без синхронизации невозможно в принципе распределять нагрузку между узлами.
А синхронизация БД на отдельных нодах без постоянной синхронизации локальных дисковых подсистем в случае когда нет единой СХД - невозможна
У вас постоянно идут транзакции на запись в БД, ведется журнал транзакций.. на дисках мля.. локально!
на каждом узле свой журнал! на дисках! БД журнал транзакций в ОЗУ не хранит! это принципиально!
она пишет его на диск, и пишет непрерывно!
Что вы тут нас лечите своими бредовыми фантазиями?
как вы можете синхронизировать БД на нодах не синхронизируя непрерывно диски?!
вы чушь городите - вы это не реализовывали, либо у вас все совсем не так как вы здесь описали!

Вы опять демонстрируете то, что с репликацией БД вы совершенно не знакомы. Диски у меня абсолютно несинхронны, так как весь кластерный сервис реализован именно на уровне БД.
И вот сама СУБД великолепно умеет этот журнал транзакций передавать между нодами (секундное расхождение в случае падения мастер ноды мне не критично). Соответственно серверы отдельные, диски никак друг с другом не синхронны, но все 4 сервера БД содержат полностью идентичные данные. Отказоустойчивость такого кластера просто великолепная, производительность тоже. За 5 лет ни одна аппаратная проблема ни разу не повлияла на стабильность нескольких таких кластеров.

Цитата: Брянский от 20.07.2016 17:11:04вот как вы можете утверждать что это был сервер на платформе SuperMicro если вы не можете  назвать модель ни платформы, ни корпуса, ни материнской платы...
?
Причем я точно знаю что в 2006-2007 SuperMicro не выпускал ничего подобного.

Потому, что на корпусе сервера и на его материнской плате было написано "супермикро".
К сожалению, я не могу спустя 10 лет вспомнить буквенно-цифровой индекс, который я видел всего несколько раз.

Цитата: ЦитатаИ что такое официальный дилер у SuperMicro? Кто это? Назовите пожалуйста.

Вот уж не слышал про таких.. есть официальные дистрибуторы и OEM-партнеры... есть просто партнеры

Даже если бы я помнил название той фирмы, что поставила тот сервис, я уважаю и соблюдаю подписанный мной NDA, даже срок которого истёк.

Цитата: ЦитатаВы вообще представляете с кем спорите то? Людей знающих больше чем я про SuperMicro в РФ сильно меньше дюжины...

Ситуация с тем сервером была вообще за пределами РФ.
Я понимаю, что вы хвалите продаваемый вами товар, я не хочу оскорблять вас, я уверен, что своим клиентам вы предлагаете наилучшие условия, действительно подбираете клиентам наилучшие и наиболее подходящие им образцы, что с тех пор SuperMicro сделало какие-то шаги к улучшению ситуации и даже пожелаю вам успеха в торговле.

Но мой личный опыт говорит, что с тремя десятками серверов супермикро в нескольких разных компаниях, причём даже в разных странах, у меня было очень много геморроя, которого никогда не было с серверами серьёзных вендоров, его было столько, с таким соотношением геморрой/сервер, что я с тех пор принципиально не работаю с supermicro и всегда рекомендую не покупать их оборудование. Может быть виноваты поставщики, может быть те, кто их покупал, но факт, что везде эти серверы подсказали себя с худшей стороны. Из хорошего про них могу сказать, что они реально дешёвые, о качестве самих серверов, я ничего плохого сказать не могу, процент отказа у них такой же как и у нормальных вендоров. Но если в супермикро что-то сломалось и требует замены, даже если это откровенный расходник то будет целая куча неожиданных проблем.
На этом я останавливаюсь и буду игнорировать любые набросы, связанные с супермикро.

Цитата: pkdr от 20.07.2016 17:11:17Ваша безапеляционность выдаёт вашу неосведомлённость.
Во-первых, heartbeat - это лишь одино из средств мониторинга и управления ресурсами кластера, их немало, например pacemaker или rgmanager из red hat cluster, лично я считаю лучшим rgmanager.
Во-вторых,  кластер - очень, очень широкое понятие, кластеры бывают очень разные, отказоустойчивые, масштабируемые, балансировки нагрузки, HPC (в русском языке нет устоявшегося выражения, можно называть "сверхвысокопроизводительными", очень мощные HPС называют суперкомпьютерами). И средства реализации этих кластеров бывают совершенно разными, на уровне оборудования, блочного устройства, файловой системы, операционной системы, сервиса, балансировщика, протокола. И весь этот зоопарк видов кластеров и способов их реализации вполне имеет право на жизнь и применяется в зависимости от задачи.


Вы опять демонстрируете то, что с репликацией БД вы совершенно не знакомы. Диски у меня абсолютно несинхронны, так как весь кластерный сервис реализован именно на уровне БД.
И вот сама СУБД великолепно умеет этот журнал транзакций передавать между нодами (секундное расхождение в случае падения мастер ноды мне не критично). Соответственно серверы отдельные, диски никак друг с другом не синхронны, но все 4 сервера БД содержат полностью идентичные данные. Отказоустойчивость такого кластера просто великолепная, производительность тоже. За 5 лет ни одна аппаратная проблема ни разу не повлияла на стабильность нескольких таких кластеров.

Уточните ОС под которой работает ваш кластер? Красна шапка? А что за СУБД?
а что касается зоопарка кластеров - а нет никакого зоопарка... это зоопарк терминологии
их всего то три вида

1.  WEB Cluster - это то что также называют масштабируемым кластером. Это для приложений.. в основном веб..
2.  High-Availability cluster - отказоустойчивый кластер.. чаще из двух узлов.. иногда больше.. производительность равна производительности 1 узла (если у вас на нем живет 1 база данных).. MS SQL вот на таких и работает
3. High Perfomance Cluster, HPC - высокопроизводительный кластер который умеет распараллеливать вычисления между нодами, как правило требует компиляции приложений под себя.
3.1. Oracle Real Application Cluster - разновидность High Perfomance Cluster

Системы виртуализации надо рассматривать отдельно

    

Цитата: pkdr от 20.07.2016 17:43:16Потому, что на корпусе сервера и на его материнской плате было написано "супермикро".
К сожалению, я не могу спустя 10 лет вспомнить буквенно-цифровой индекс, который я видел всего несколько раз.


Даже если бы я помнил название той фирмы, что поставила тот сервис, я уважаю и соблюдаю подписанный мной NDA, даже срок которого истёк.

вы врете - не было такого корпуса у SuperMicro 10 лет назад
ваш сервак мог только вот так выглядеть
https://www.supermicro.nl/products/system/4U/8045/SYS-8045C-3R.cfm

максимум 10 HDD (да и то если только вторую корзину засунуть)

ваши 32 или 16 HDD это просто вранье
и дело не в SuperMicro (вы просто попались на лжи на нем) а в вас - вы фейк от начала и до конца - лепите тут всем туфту почерпнутую на просторах нета которая к вам отношения не имеет

я 10 лет назад мучился с проектами когда клиенты требовали много дисков к четырехпроцессорнику - а тут приходит чел который заявляет - а у нас типа был такой сервак

Цитата: Брянский от 20.07.2016 18:15:35Уточните ОС под которой работает ваш кластер? Красна шапка? А что за СУБД?

Вариация на тему шапки - центос.
Если речь про кластер с БД на рейде 0 из ссд, то перкона и постгри.

Цитата: Цитатаа что касается зоопарка кластеров - а нет никакого зоопарка... это зоопарк терминологии

их всего то три вида

Опять же ну не надо так безапелляционно, их гораздо больше, вобще нет чёткого определения слову кластер. Если у тебя есть сервис, так или иначе распределённый по нескольким узлам, выполняющим одну задачу, значит у тебя есть кластер.

Цитата: Цитата1.  WEB Cluster - это то что также называют масштабируемым кластером. Это для приложений.. в основном веб..
2.  High-Availability cluster - отказоустойчивый кластер.. чаще из двух узлов.. иногда больше.. производительность равна производительности 1 узла (если у вас на нем живет 1 база данных).. MS SQL вот на таких и работает
3. High Perfomance Cluster, HPC - высокопроизводительный кластер который умеет распараллеливать вычисления между нодами, как правило требует компиляции приложений под себя.
3.1. Oracle Real Application Cluster - разновидность High Perfomance Cluste

Знаете от такой жёсткой классификации, очень повеяло когда-то прочитанной мной  методичкой от M$, когда делал фейловер кластер для MS SQL. Там именно так и писалось "кластеры бывают такие:" и список из трёх пунктов (описывающих, разумеется, только те варианты, которые M$ смогла как-то реализовать у себя), только первый пункт у них назывался тоже по другому (но по факту в прочитанном узнавался кластер балансировки нагрузки), но не web cluster.

Под web cluster вы явно имеете в виду load balancing cluster, как обычно его зовут, ну вряд ли кто-то будет звать балансировку запросов веб-кластером, если балансер работает не с вебом.
"High-Availability cluster" так говорят только в очень официальной документации и материалах маркетологов, в общении подавляющее число людей используют failover cluster, собственно от этого у меня ассоциация с мелкомягкой методичкой и возникла, уж очень похоже на их безапелляционность.
Есть ещё scalable cluster - масштабируемый кластер, который предназначен для распределения ресурса, который слишком большой, чтобы поместиться на одной ноде, например всё тот же Oracle RAC (который, скорее, ближе к нему, а не к HPC) или всякие кассандры с редисами, отличается от load balancing тем, что ноды не идентичные, а делят данные между узлами и сами обмениваются данными и перераспределяют их.
HPC кластером же обычно именуют кластер, где не хватает именно вычислительной мощности и кластер в первую очередь занят распределением вычислительных ресурсов между нодами, обычно они нужны для числодробилок и встречаются намного реже других.

Подозреваю, что вы это взяли как раз из методички оракла, упоминание RAC на это намекает, так вот не стоит полностью доверять даже полезным книгам от подобных компаний, вернее информация там очень важная и полезная, но всегда нужно помнить, что подача информации там тенденциозна.

И следует помнить, что я написал про виды кластеров ни в коей мере не предендует на истину, просто небольшая выжимка из принятых в сообществе терминов и того, где и как оно употребляется, никто вам не зарещает обзывать failover cluster, как HA cluster, его тоже используют, но только на порядки меньше. Просто потому, что под понятием "кластер" сейчас понимают целый зоопарк разнообразнейших технологий.

   

Цитата: Брянский от 20.07.2016 09:46:16...
товарищ Power On
вы тут хрень написали.
...
во третьих использование RAID 0 никак не может увеличить количество IOPS именно потому что поток транзакций читается сразу со всех HDD
А вот RAID 1 и RAID 10 на аппаратных контроллерах  могут увеличить IOPS вдвое - контроллер может распределять запросы на чтение по разным HDD потому что на них лежат полные и идентичные копии требуемых данных

RAID для чайников

Цитата: ЦитатаRAID 0 (striping — «чередование») — дисковый массив из двух или более жёстких дисков с отсутствием резервирования. Информация разбивается на блоки данных (A_i) и записывается на оба/несколько дисков одновременно.

(+): За счёт этого существенно повышается производительность (от количества дисков зависит кратность увеличения производительности).

Цитата: Поверонов от 20.07.2016 21:46:45Не удваивает а N-аривает где N - число физических пакетов дисков ("шпинделей"). Блок данных распределяется  мелкими секторам "полосками" между "шпинделями" так чтобы они одновременно подходили к читающим/пишущим головкам. Таким образом время чтения/записи уменьшено в N раз, так как выполняется на всех "шпинделях" параллельно. А затем физический блок сливается из полосок в  памяти контроллера и переписывается в ОЗУ.

Каюсь, использовал не точную формулировку, рассматривал частный случай, когда на raid 1 и raid 0 выделено по два диска, а на raid 10 - 4

Цитата: Брянский от 20.07.2016 09:52:05А нахрена вам домой ПК от МЦСТ
вы кого-то боитесь? у вас террабайты детской порнухи дома хранятся?!

Затем же, зачем и сервер - у меня на нем несколько сервисов крутится.
Я не хочу потерять свои данные (фото, видео, проекты, документы). Во всякие ФейсбукоВконтакты их не заливаю и храню только на домашнем жестком диске.

А причем тут детское порно и МЦСТ - я даже и не знаю, как вы их связали. Речь ведь о закладках наших "партнеров" идет.

Плата разработчика MBE1C-PC представляет собой материнскую плату, выполненную в форм-факторе miniITХ.
На плате расположены микропроцессор Эльбрус-1С+ и южный мост КПИ-2. Разъемы DIMM обеспечивают подключение модулей DDR3 ECC к двум контроллерам памяти процессора. Для охлаждения процессора предусмотрены крепления для пассивного радиатора.

 
Вывод изображения с интегрированного 2D/3D видеоконтроллера возможен через разъёмы HDMI и LVDS на 2 независимых монитора. 
Разведены следующие интерфейсы южного моста:

• PCI-Express 2.0 x16,
  


• PCI-Express 2.0 x 4 (для модулей miniPCI-E),
  


• 8 каналов SATA 3.0 (один из них в виде разъёма mSATA)
  


• 3 канала Gigabit Ethernet с поддержкой протокола IEEE1588,
  


• 8 каналов USB 2.0, 2 порта RS-232,
  


• многоканальный звук HD Audio,
  


• отладочные интерфейсы JTag.
  

Электрическая схема и топология платы разработчика передаются компаниям, желающим разработать для данного микропроцессора собственные проекты вычислительных модулей.

 P.S. Дело хорошее, но сильно вредит закрытость - ни результатов тесов ни цены ни видео работы.

Цитата: _taras_ от 26.07.2016 15:21:49Плата разработчика MBE1C-PC
...
сильно вредит закрытость - ни результатов тесов ни цены ни видео работы.

Плата разработчика. Это достаточно специфичная категория изделий, у которой например цены раньше вообще не подразумевалось.
Хотя я тут очень давно вне темы.

Цитата: _taras_ от 26.07.2016 15:21:49Плата разработчика MBE1C-PC представляет собой материнскую плату, выполненную в форм-факторе miniITХ.
На плате расположены микропроцессор Эльбрус-1С+ и южный мост КПИ-2.
...
Электрическая схема и топология платы разработчика передаются компаниям, желающим разработать для данного микропроцессора собственные проекты вычислительных модулей.

Слишком жирный южный мост для одноядерного процессора. Процессор только и будет делать, что прерывания обслуживать от всего этого зоопарка интерфейсов.
...
Нет ни одного IEEE 1394. Нет ни одного eSATA. Т.е. подключить внешний накопитель не получится. Зато есть целых 16 четырехполосных PCIe и восемь USB 2.0. И можно подключить четыре дополнительные клавиатуры и четыре дополнительные мышки.