Пилим? Пилим!

Jerard> Ага, а потом потерять всю систему из-за пробежавшего таракана сдохшего оптического коммутатора.
а он единственный?

Mishka> Флаг тебе в руки и барабан на шею.
))) лучше денег дай )))

Mishka> Прикинь, правда боюсь денег не хватит. Это из серии — пилот умер в полёте, но поведет сталевар.
ну.. я как-то запомнил, что в сша самые дешевые мощности для хостинга чего угодно, вот и подумал, что наём сервов на некоторое время не есть что-то экстраординарное по сумме.. Впрочем, могу ошибаться.

Mishka> И что? Ты представляешь, как работает СУБД на виртуальной машине? И у тебя есть виртуальные машины для мэйнфреймов? А может есть для другого экзотического железа? Вообще-то на виртуалках надо поработать, прежде чем такие заявы делать. Я на 4-х виртаулках нашу систему минимальную с трудом каждыи день гоняю. И это при том, что у нас сервера серъёзные, вмваря самая продвинутая и основная система линь.
Про экзотическое железо и мейнфреймы не буду спорить, не знаю. Знаю, что наша контора закупила парочку блейдов весной, и видел, как поочередно то один то другой сервис переводили на виртуальные машины.

Mishka> Не работает.
То, что я высказал, буквально описывали в ноябре на семинаре "Инновации ставшие стандартом" представители айбиэма, интела и вмвари.
увы, прямую линку уже не найти на Go-tech

Mishka> В банках двойной ввод всегда.
а как это выглядит со стороны юзера? Дважды в систему вводит данные? Или есть некая автосинхронизация?

>Ну и маштабы в США другие.
масштабы и нелинейность - не спорю. Но принципиальную невозможность этим подтверждать - несогласен.

>обучение работников, перевод филиалов — почти 5 лет.
(шепотом - а у нас некоторые работники систему документооборота, введенную в 2003, до си пор не понимают =))

Mishka> Дык, они же работают по разному. Там же кодировка номеров другая. Выделение номеров другое.
А контроль ошибок никакой не предусмотрен в системе?

Mishka> А как же ты предлагаешь решение, если такой важной вещи не решил?
нууу.. при таком подходе любое преобразование невозможно ))
не спорю, что при более глубокой проработке оно может быть необходимо, но на этапе концептов - не думаю)

Mishka> Здесь же не пакет. Здесь даже не просто миллионы строк кода, сотни миллионов.
сотни миллионов строк кода? эээ... софт весом в десятки гиг? Не база, а именно софт? Код?
Мне кажется, ты несколько преувеличиваешь...

Mishka> Система централизованная. Человек получает сервисы независимо от места проживания. Нету филиалов, отвечающие за клиентов. Кстати, в американских банках тоже нет такого распределения. Вот по штатам есть, т.к. в штатах разные законодательства.
эээ... или я не так описал, или ты не так понял..
У нас база общая. Софт, обрабатывающий эту базу, на нескольких серверах лежит. Они автоматически переключаются (так понимаю, в порядке лоад балансинга) + включаясь взамен зависших. Разумеется, время от времени всё безбожно глючит и виснет (тогда и мне перепадает, хоть я за то не отвечаю вовсе, просто ко мне проще дозвониться )
На некоторых из серверов может использоваться модицицированный вариант (или новый вариант) обработчика.
Эти сервера дают попользоваться одному отделу и следят за результатом.

У вас данный номер, социальный который меняется, он и является идентификатором в бд? Или таки есть иной? Чтоб, скажем, вносить в строку бд ячейку и со старым и с новым. И просто кто работает по новой системе, с новой версией пакета, получает ячейку с новым номером, а кто со старой - ячейку со старой. Или такой вариант тоже чрезмерно сложен? (хоть не улавливаю, чем)

Mishka> Тут гораздо хуже — надо не просто настроить, а чтобы сохраняла-восстанавливала данные в нужной системе или полный дубль с поправленной частью.
А в чем корневое различие в собственно бд? Почему решение из абзаца выше неприменимо и сообветственно общая структура бэкапа неприменима?

Bredonosec> а он единственный?

Нет. Но... Была у нас ситуевина. Только что пришли новенькие ( на тот момент) кластеры на Compaq RA4100 полностью резервированные и пр.
Ввод в эксплуатацию осуществлял авторизованный сервисный центр, в общем, все как полагается.
Через месяц приходим утром-один из кластеров в дауне. Отказал контроллер RA4100, резервный должен был поднять конфигурацию, а не поднял. Хотя был исправен. RAID рассыпался... В общем, простояли весь день!!! Хорошо еще кластеров было два одинаковых. Контроллеры пришли через две недели.
А был бы виртуальный зоопарк? У меня волосы дыбом при мыслях об етом. Вот сейчас прислали такой... Ужос.

Bredonosec> ))) лучше денег дай )))

А ты купи слона!

Bredonosec> ну.. я как-то запомнил, что в сша самые дешевые мощности для хостинга чего угодно, вот и подумал, что наём сервов на некоторое время не есть что-то экстраординарное по сумме.. Впрочем, могу ошибаться.

Это те, которые тебе ничего не гарантируют. Кстати, вот там виртуализация используется вовсю. Но, практически, ни один бы не потянул нашу Базу. А, как хочешь с хотя бы парой 9-от после запятой, то цены совсем другие.


Bredonosec> Про экзотическое железо и мейнфреймы не буду спорить, не знаю. Знаю, что наша контора закупила парочку блейдов весной, и видел, как поочередно то один то другой сервис переводили на виртуальные машины.

Ну, так у меня и в СА-ке, и на нонешней работе, и дома (с далёкого 1999 года) виртуалки используются — на работах GSX, ESX и другие сервера. На моей машинке от Сана стоит, а домашнем лине стоит KVM поддерживаемая, ВМВаря, от Сана. Так вот на группу из 15 человек одного блейд сервера не хватает. Помирает железная машинка, если мы начинаем тестировать все сразу. Виртуализация она такая, хороша, когда 100% загрузки нет. Иначе начинаешь ждать. Скажем, наша База помрёт на виртуальных машинах или виртуальная машина помрёт очень быстро.

Bredonosec> То, что я высказал, буквально описывали в ноябре на семинаре "Инновации ставшие стандартом" представители айбиэма, интела и вмвари.

Ага, как же. Стало стандартом потому, что обычному человеку и малому бизнесу не надо очень мощной машины. Скажем, если в конторе 50 человек, они заняты не разработкой софта, не вводом/обработкой данных и не поддержкой хостинга, то им действиетльно будет дешевле захостится на виртуалках. Лучше у кого-то. А не покупать машинки и держать человека, чтобы он держал эти машинки в поднятом состоянии. Но в той же СА-ке только серверов мыльных было более 30 штук. И то падали. Попытались их на виртуалки перевести. Упали все мыльные сервера. Опять-таки, надо принимать во внимание, что одна железяка с виртуалками упадёт — минус куча машин. Поэтому подбор случаев, когда виртуалки могут полностью удовлетворить, должен быть очень тщательным. Ну и убер решением во всех вариантах не является.

Bredonosec> увы, прямую линку уже не найти на Go-tech

Да не надо линку. Я же сам частично разрабатывал софт, который управлял виртуалками, как часть инициативы в СА-ке. Так что все маркетинговые слова знаю.

Bredonosec> а как это выглядит со стороны юзера? Дважды в систему вводит данные? Или есть некая автосинхронизация?

В нашем случае пришлось написать примочки на старую систему и на новую систему, общение через WebServices. Т.е. старая система сообщала про новые записи, вебсервис их перекодировал, лазая по старой БД, новой БД, специальным БД, и отдавал новой системе. Как видишь, это сильно выходит за рамки того, что товарищ написал.

Bredonosec> масштабы и нелинейность - не спорю. Но принципиальную невозможность этим подтверждать - несогласен.

А я не говорю про принципиальную невозможность. Просто ресурсы ограничены. Никто не даст "бюджет США" на то, чтобы взять и обновить с полным дублированием оборудования.

Bredonosec> (шепотом - а у нас некоторые работники систему документооборота, введенную в 2003, до си пор не понимают =))

Ну, не знаю. В банке был целый отдел, который отвечал за тренировки. Т.е. понимать целиком они не понимали. Но какие кнопки нажимать в каком стандартном случае, вроде, знали. И всегда в филиале был человек, который разбирался лучше. Ну и всегда могут позвонить в поддержку. Понятно, что 100% покрыть не удавалось, но задача, как обычно, ставилась 80/20.

Как они их тренировали — не знаю. Может током закрепляли навык, может печенюшками.

Bredonosec> А контроль ошибок никакой не предусмотрен в системе?

Подожди, а причём тут контроль? У тебя приципиально наполнение БД другое. И поэтому код в старой системе не сможет корректно обрабатывать данные из новой БД, и наоборот, из новой системы не может корректно обрабатывать данные из старой БД. Смотри, у тебя раньше 000 раньше был признаком временного SSN, а 999 были нормальные номера. А стало 999 — временный SSN, а 000 — нормальным. Т.е., если хочешь написать систему, которая работает корректно с обеими БД, то тебе надо ещё дополнительный бит информации на каждый SSN — принадлежность (или источник) к БД. И это надо для всех обрабатывающих программ.

Bredonosec> нууу.. при таком подходе любое преобразование невозможно ))
Bredonosec> не спорю, что при более глубокой проработке оно может быть необходимо, но на этапе концептов - не думаю)

Ы? Это как? На солнце ночью полетим?

Bredonosec> Мне кажется, ты несколько преувеличиваешь...

Скажем, только eHealth в СА-ке имел около несколько лимонов строчек кода. Число строк только для файлов .C и .H на моём текущем проекте — 5,521,821. Это не считая java, cpp, hpp, c, h, py, sh и PL/SQL. А проектов много. Часть кода общая, но есть проекты, где всё своё. Скажем, управление метро и трамваями — всё своё. Оптимальное планирование — тоже всё своё. У железячников куча своего кода. Т.е. по компании, я бы сказал, у нас точно более 50,000,000 строчек кода. Это по американской части. У итальянцев, я думаю, что не меньше.

Bredonosec> эээ... или я не так описал, или ты не так понял..
Bredonosec> У нас база общая. Софт, обрабатывающий эту базу, на нескольких серверах лежит. Они автоматически переключаются (так понимаю, в порядке лоад балансинга) + включаясь взамен зависших. Разумеется, время от времени всё безбожно глючит и виснет (тогда и мне перепадает, хоть я за то не отвечаю вовсе, просто ко мне проще дозвониться )
Bredonosec> На некоторых из серверов может использоваться модицицированный вариант (или новый вариант) обработчика.

Дык, проблема в том, что в БД разные данные. Плевать, где код лежит. Старый и новый не могут вместе работать с одной и той же БД. В этом проблема. Лоад балансинг и прочее, это к архитектуре системы и её масштабируемости. А тут без этого проблема.

Bredonosec> Эти сервера дают попользоваться одному отделу и следят за результатом.
А как ты дашь одному отделу/филиалу, если у них БД разные? Соответственно и код. Ну и кучу вещей система сама обрабатывает. Те же пенсии ветеранам и просто пенсионерам, те же пособия по безработице, медикэйер, медикэйт, пенсионные отчисления, куча всего другого. И всё это должно быть сделано только один раз, а во внимание принимается вся история — размер пенсии, к примеру, зависит от предыдущих отчислений.

Bredonosec> У вас данный номер, социальный который меняется, он и является идентификатором в бд? Или таки есть иной? Чтоб, скажем, вносить в строку бд ячейку и со старым и с новым. И просто кто работает по новой системе, с новой версией пакета, получает ячейку с новым номером, а кто со старой - ячейку со старой. Или такой вариант тоже чрезмерно сложен? (хоть не улавливаю, чем)

Ы! Т.е. ты хочешь поменять структуру БД, при этом ещё и старые проги должны работать. А как ты в БД узнаешь, какая программа делала запрос? А в новых программах? А как ты потом новые в старые переделаешь (для другого изменения)? Т.е. где-то надо будет закодировать, какое поле программка должна запрашивать. В коде ли, в ini файле, в самой БД, но надо это сделать. Ну и видимо, каждое поле в БД надо бы продублировать. Т.к. неизвестно, какое из них захочется поменять в будущем. Правда проблемы с индексами начинают возникат — они тоже множаться. Скажем тот же oracle partitioning по обоим полям не удасться сделать. Размер при этом может растёт очень быстро.

Bredonosec> А в чем корневое различие в собственно бд? Почему решение из абзаца выше неприменимо и сообветственно общая структура бэкапа неприменима?
Хотя бы потому, что БД там существенно больше 40 лет. И нет у неё точно такой структуры. А дублировать каждое поле — накладно. Ну и минимальной переделкой не обойтись.

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

Bredonosec> нет времени по пунктам, но не понял, почему железяка упадет?
Есть у них такое свойство — падать. Ты думаешь, почему всякие дублированные и троированные комплексы, а так кластеры с горячим подхватам делают?

Bredonosec> виртуалки - это ж всего навсего файлы. Почему железяке умирать от смерти виртуалок?

Это как? Ты имеешь ввиду то, что с точки зрения хоста — это файлы? Умирают от массы вещей:
1. Если накосячили в хостовой ОС, то вероятность события наступить на такой косяк резко повышается — машина всегда загружена.
2. Нагрузка на железо всегда выше. Те же диски стрекочут не переставая. Каждая из гостевых хочет свои файлы получить своим способом. Т.е. там и директории, и служебные области, и всякие MBR с бут секторами свои. Всё это добро часто на одном большом диске — хостовая ОС часто держит их в виде файлов, т.е. сначала идёт доступ к файлу в хостовой ОС (прочитать весь путь по поддиректориям с использованием всех прелестей фаловой системы хоста), потом на гостевой добраться до файла тем же способом. При добавлении инфы на диск ещё всё хуже. Скажем, я предпочитаю разместить диски виртуалок сразу полностью, а не динамически расширяя. Тогда нет проблем с фрагментацией файла, эммулирующего диск и добавление и создание файлов в гостевой идёт значительно быстрее. А есть ещё своппинг.
3. Всякие прерывания надо тянуть дольше — сначала по системе хоста, потом по гостевой ОС.
4. Проц всегда занят почти на 100% (надо контекст переключать для всех виртуалок, а внутри виртуалок своего добра хватает), поэтому требования к охлаждению всей машины, а проца в частности, намного строже. Чуть запылился и писец приходит быстро. Правдо диски вылетать начинают быстрее от перегрева. Но видел, как вылетало и то, и другое.
5. С битой памятью начинаются очень интересные глюки. Они бывают размазанны по многим виртуалкам и поймать их становится трудно.

Mishka> Есть у них такое свойство — падать. Ты думаешь, почему всякие дублированные и троированные комплексы, а так кластеры с горячим подхватам делают?
Ну, не считая железоглюков и глюков оси, мне казалось, вероятность глюка от взаимодействия нескольких разноплановых сервисов таки выше, чем от одного.. Протестировать взаимное поведение в комплексе достаточно затруднительно.. Хотя б потому, что у каждого свой набор..

Mishka> Те же диски стрекочут не переставая. (....)
там еще очень рекламили хранилища на основе флеш-памяти. Мол и доступ рандомный быстрее, и прочая и прочая. Я спросил, как насчет ресурса - сначала попытались отмазаться и ответить на другой вопрос, но когда настоял, уточнили, что через 2-3 года "вы просто купите другой накопитель".

Mishka> 3. Всякие прерывания надо тянуть дольше — сначала по системе хоста, потом по гостевой ОС.
прерывания - это на инпут-аутпут? Чтоб вклиниться в процессы?
Мне казалось, они и так не особо критичны.. В смысле, если после твоего инпута машина только чеерз секунду отреагирует (после чего выделит этому процессу больше процевремени и станет реагировать быстрее) - не есть криминал..

Mishka> 4. Проц всегда занят почти на 100% .., поэтому требования к охлаждению всей машины, а проца в частности, намного строже. Чуть запылился и писец приходит быстро. Правдо диски вылетать начинают быстрее от перегрева. Но видел, как вылетало и то, и другое.
а фильтры на входе разве сейчас не ставятся?
А то подобное много обсуждалось где-то, но я никогда особо не интересовался..

Mishka> 5. С битой памятью начинаются очень интересные глюки. Они бывают размазанны по многим виртуалкам и поймать их становится трудно.
хы )) Да и без них найти бывает непросто..
Я на собственной рабочей машине 2 года не могу понять, что заставляет её рандомно виснуть - то по пару раз на день, то раз в пару месяцев. Все тесты проходит на ура, а косяк где-то есть.

Bredonosec> виртуалки - это ж всего навсего файлы. Почему железяке умирать от смерти виртуалок?

Была феерическая конфигурация из монстра на нём винда, на винде vmware под ней 10ка виртуалок с виндой ( манагеры заказчика обчитались манагерской макулатурой ). Так вот это всё регулярно под нагрузкой валило монстра даже после применения тонны патчей от микрософта/vmware.
(Последнее слово было - надо переходить на linux, но уже бушевал кризис и проект ушёл погулять).
Так что я бы поосторожней с утверждением, что это "всего лишь файлы". Там столько оптимизаций на скорость и т.п., что умирать есть от чего, особенно под нагрузкой.

vtvitus> Там столько оптимизаций на скорость и т.п., что умирать есть от чего, особенно под нагрузкой.
хм.. ну.. молчу )) Как сам поем устриц - может встряну ))

Mishka> 1.

Здесь должны быть прямые руки, холодный ум, опыт, опять же, какой-никакой. Вероятность можно понизить. Ну и тестирование-тестирование-тестирование.

Mishka> 2.

Часто, но не всегда.

Block IO device + LVM упрощает жизнь за счёт исключения прослойки между дисковым устройством виртуальной машины и дисковым устройством хоста.

Mishka> 3.

Вот это — очень печально. Например, я не уверен в том, что Asterisk с железными карточками будет нормально работать. Надо будет тестировать. Но при миграции виртуалки это всё, наверняка, будет отваливаться. Хотя, может быть, HOTPLUG_PCI поможет.

Mishka> 4.

Вот насчёт 100% занятости проца — не для всех случаев, надеюсь, говоришь? Потому что, если нагрузить хотя бы по 1 виртуалке на ядро, то всё в пределах нормы: винда в состоянии покоя на AMD Athlon(tm) II X3 445 кушает в среднем 15% времени, под Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz — примерно 4-5%. При этом, сам процессор практически не нагружен. Линуксы, соответственно, без нагрузки кушают 1-2% времени.

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

Ещё, BKL в 2.6.39 окончательно убили!

HolyBoy> Здесь должны быть прямые руки, холодный ум, опыт, опять же, какой-никакой. Вероятность можно понизить. Ну и тестирование-тестирование-тестирование.
От тебя не зависит. Только от создателей ВМ.

HolyBoy> Часто, но не всегда.
HolyBoy> Block IO device + LVM упрощает жизнь за счёт исключения прослойки между дисковым устройством виртуальной машины и дисковым устройством хоста.

А как это отменяет нагрузку на диски? Они стрекочат всё равно. У нас RHEL 5 стоит на виртуальных, так диски не замирают ни на секунду. Правда, у нас на 30 человек делиться, у каждого по 4 виртуалки. И Оракле эти виртуалки прикладывает очень хорошо. А система вертится у каждого работчая, там до фига процессов идёт и в БД пишется-читается дофигища.

HolyBoy> Вот это — очень печально. Например, я не уверен в том, что Asterisk с железными карточками будет нормально работать. Надо будет тестировать. Но при миграции виртуалки это всё, наверняка, будет отваливаться. Хотя, может быть, HOTPLUG_PCI поможет.

Хм, тут дело такое. Все ресурсы делятся на три типа: 1) Разделяемые (e.g. проц, память); 2) Захватываемые (e.g. СД, флоппик, разные USB); 3) Эммулируемые (сетевые карточки, видео карточки). В случае asterisk-а, это будет либо эммулируемые, тогда нужна очень серъёрзная поддержка устройств на уровне хоста для ВМ, либо захватываемые — тут попроще, устройство должно забраться в абсолютное пользование, и всё идёт редиректом в гостевую, а там стандартные свои драйвера будут. Но в любом случае зависит от создателя ВМ — есть ли поддержка.

HolyBoy> Вот насчёт 100% занятости проца — не для всех случаев, надеюсь, говоришь? Потому что, если нагрузить хотя бы по 1 виртуалке на ядро, то всё в пределах нормы: винда в состоянии покоя на AMD Athlon(tm) II X3 445 кушает в среднем 15% времени, под Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz — примерно 4-5%. При этом, сам процессор практически не нагружен. Линуксы, соответственно, без нагрузки кушают 1-2% времени.

Если Костя хочет замещать реальные машинки сервера, для которых нет альтернативы объединить из-за нагрузки, то почти для всех. Скажем, наша База в своё время виртуальный хостинг убивала. Ну и пример, который я приводил — в СА-ке было более 30 Exchange серверов. И то от нагрузки падали бывало. Вот их перевести на ВМ будет убийством. А какой-нибудь серверок на 2 человека, где только файлы открывают, то никаких пробелм не будет. Но виртуализацию пихают-то, как серебряную пулю для решения проблем с большим количеством машин.

HolyBoy> Под нагрузкой, опять же, тоже всё в пределах допустимого: каждая виртуалка грузит своё ядро и, при этом, отзывчивость внутри хоста и каждой виртуалки вполне приемлемая.
HolyBoy> Ещё, BKL в 2.6.39 окончательно убили!
У тебя будет всегда двойное переключение контетста на виртуалке — сначал дать таймслайс виртуальной машине, а внутри процессу.

Mishka> От тебя не зависит. Только от создателей ВМ.

Да, но поведение можно проверить тестами и если что-то не так, то найти выход.

Mishka> У нас RHEL 5 стоит на виртуальных, так диски не замирают ни на секунду.

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

В конце-концов, всё в деньги упирается.

Mishka> Правда, у нас на 30 человек делиться, у каждого по 4 виртуалки.

У меня делится иначе, народу больше будет, но и железа тоже больше. Посмотрим.

Mishka> В случае asterisk-а, это будет…

Я не совсем корректно выразился: дело в том, что запускать виртуалки на одном хосте я считаю глупым и бессмысленным делом, пригодным разве что для тестов. Б́ольшая часть эффективности теряется. А если кластеризовать виртуалки, то появляется проблема с оборудованием.

Внутрь виртуалки же, которую я использую (KVM), пробросить PCI можно. Вот что с ВМ будет, когда она мигрирует на другой хост и ВНЕЗАПНО потеряет PCI-устройство — пока не знаю. Полагаю, что отвалится. Или программа, использующая эти устройства, умрёт.

Mishka> Если Костя хочет замещать реальные машинки сервера, для которых нет альтернативы объединить из-за нагрузки, то почти для всех.

Ну, если те, что обсуждается, то да.

Mishka> Скажем, наша База в своё время виртуальный хостинг убивала.

Верю. Ведь на одну железку тут взгромоздили СУБД и web-сервер с сайтогенератором на питоне(?), да и на посещаемость жаловаться не приходится.

А вот убила бы она виртхостинг с разнесёнными на разные железки ВМ с сервисами — вопрос.

Mishka> Ну и пример, который я приводил — в СА-ке было более 30 Exchange серверов. И то от нагрузки падали бывало. Вот их перевести на ВМ будет убийством.

МС Эксченж?
Если он, то нафига? Незаменимый?

На чём основной затык был? Процессор? IO? Всё разом?

Mishka> Но виртуализацию пихают-то, как серебряную пулю для решения проблем с большим количеством машин.

А, пусть пихают. Я виртуализацию как вещь в себе не рассматриваю. Глупо, ИМХО, пытаться уменьшить количество загруженных по самое нехочу машин. Как раз, наоборот, надо количество железок увеличивать, уменьшая нагрузку на них и увеличивать надёжность созданием Failover'a, чтобы не вылетали они так, как ты выше про Exchange-сервера писал.

HolyBoy> Да, но поведение можно проверить тестами и если что-то не так, то найти выход.

Какими тестами?

HolyBoy> Ну и что? Диски тянут? Если тянут, то ок, если нет, то можно отдельное дисковое хранилище замутить, с шахматами и монашками RAID нужной конфигурации, который даст требуемый объём/скорость и обмениваться данными с ним по оптике/меди. Если тормоза продолжаются, значит, наблюдается просчёт в проектировании.

Что значит тянут? Если по производительности, то нет. Если по времени жизни, то умирают быстрее, чем на обычных серверах, но в рамках. А ферму мутить, так канал нужен скоростной. И тут уже вопрос, а что дешевле — поставить 50-200 машин по $1,000 (блэйды). Или несколько мощных серверов для ВМ и ферму мутить (в первой компании, не совсем ферма, но двухходовой оптический ящик от EMC сожрал всю выгоду от перехода с Sequent-ов на HP — стоил $500,000).

HolyBoy> В конце-концов, всё в деньги упирается.

Дык, ферма ВМ-к позиционируется, как решение необходимости многих машин при нехватке денег.

HolyBoy> Я не совсем корректно выразился: дело в том, что запускать виртуалки на одном хосте я считаю глупым и бессмысленным делом, пригодным разве что для тестов. Б́ольшая часть эффективности теряется. А если кластеризовать виртуалки, то появляется проблема с оборудованием.

Хех, ты пошёл уже в другую сторону. Посмотри зачем Костя предлагал виртуалки. В кластере с автоматическим распределением нагрузки или автоматическим подъёмом-подхватом упавшего, оборудование у машин-хостов должно быть аналогичное. Но тогда надо и решение, чтобы железные дубли не работали все сразу (в случае балансинга, оговорюсь, работают все сразу), а переводились в рабочее состояние и конфигурация бы доставлялась очень быстро. Ну и большинство народу таки ставят много виртуалок на одном хосте.

HolyBoy> Внутрь виртуалки же, которую я использую (KVM), пробросить PCI можно. Вот что с ВМ будет, когда она мигрирует на другой хост и ВНЕЗАПНО потеряет PCI-устройство — пока не знаю. Полагаю, что отвалится. Или программа, использующая эти устройства, умрёт.

Если на другом хосте есть такой же, то почему умрёт?

HolyBoy> А вот убила бы она виртхостинг с разнесёнными на разные железки ВМ с сервисами — вопрос.

Да не вопрос. СУБД-ха должна вращяться где-то. Просто есть задачи, которые не очень хорошо ложаться на такую архитектуру. Опять-таки, можно было бы поставить СУБД на специальную машину. Но дешевизной опять не пахнет.

HolyBoy> МС Эксченж?

Ага.

HolyBoy> Если он, то нафига? Незаменимый?
Корпорация решила, что на нём.

HolyBoy> На чём основной затык был? Процессор? IO? Всё разом?

Да всё разом. Когда в компании 15,000 человек, да куча колоборации идёт по мылу, да все жмут ответить всем, да с картинками и большими документами (SRS на 300-500 страниц), и, где поправил пару строк и всем в команеде зафуфырил...

HolyBoy> А, пусть пихают. Я виртуализацию как вещь в себе не рассматриваю. Глупо, ИМХО, пытаться уменьшить количество загруженных по самое нехочу машин. Как раз, наоборот, надо количество железок увеличивать, уменьшая нагрузку на них и увеличивать надёжность созданием Failover'a, чтобы не вылетали они так, как ты выше про Exchange-сервера писал.

Ну, так люди и делают. Другое дело, что в питч ВМ не укладывается. А так виртуалки для девелопмента очень удобная вещь, ИМХО. Особенно со снэпшотами.

Mishka> Какими тестами?

Долгими. Разными. Например, у меня один из тестов выявил, что vmware video не дружит с KVM.

Mishka> Если на другом хосте есть такой же, то почему умрёт?

Не такое же. И дело тут не только в приобретении железки. К примеру, одна из железок по E1 потоку связана с провайдером телефонии и нашей внутренней АТС. Если её дублировать на другом хосте, то физически провода и места, куда их втыкать, неоткуда взять.

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

Либо, придётся делать 2 ВМ с астерисками: одну жёстко привязать к железке, вторая будет мигрировать и связываться с первой по IAX2. И так со всем прочим уникальным оборудованием, к примеру, от 1С.

Mishka> Ага.
Mishka> Корпорация решила, что на нём.

ССЗБ.

Mishka> Да всё разом. Когда в компании 15,000 человек…

Из моего опыта и опыта знакомых: пока тот же постфикс успевал принять/переправить письма, проверить на вирусы, спам и тд и тп (на той же машинке ещё прокси работал), а сама машинка была чем-то древним (2 * Пент. 3), эксченчж-сервер, на гораздо более мощной машине регулярно падал. Количество обслуживаемого народу: порядка 200 чел.

Mishka> А так виртуалки для девелопмента очень удобная вещь, ИМХО. Особенно со снэпшотами.

Да, я про разработку забыл. Тут согласен. Очень удобно и дёшево.

Mishka> И тут уже вопрос, а что дешевле — поставить 50-200 машин по $1,000 (блэйды). Или несколько мощных серверов для ВМ и ферму мутить (в первой компании, не совсем ферма, но двухходовой оптический ящик от EMC сожрал всю выгоду от перехода с Sequent-ов на HP — стоил $500,000).

Это, кстати, интересный вопрос: а что будет дешевле по совокупной стоимости из этих двух вариантов? Я про затраты как на само железо, так и на сопутствующие вещи: охлаждение, электроэнергия на всё, помещение и тд и тп.

HolyBoy> Это, кстати, интересный вопрос: а что будет дешевле по совокупной стоимости из этих двух вариантов? Я про затраты как на само железо, так и на сопутствующие вещи: охлаждение, электроэнергия на всё, помещение и тд и тп.

Не знаю. В DXI-ке (та самая компания) сделали ставку на Sequent-ы. Всё-таки Sequent первые сделали (и считается, что изобрели) SMP архитектуру. Так для девелопмента была машинка на 4 486 на 25 МГц, а в продакшене стояло две 8 процессорных на 486 на 50МГц. Ну и памяти было больше. Так везде стояли ящики со сказёвыми дисками — 60 2 гиговых или 30 4 гиговых. Работало относительно быстро. Машинки относительно старые (я пришёл в компанию в марте 1995). БД были тогда на 100 гигов с постоянным пополнением. В день примерно приходило чуть менее лимона новых записей. Бывало, правда, и по 14. Сами машинки стоили много, но и обслуга стоила до фига. Типа поддержка Информикса поллимона в год, поддержка железа ещё лимон в год. Решили экономить. Попробовали не маштабный тест. Вроде пошло. Я правда, артачился. В общем взяли серию К-9000 на 16 процев. Поставили попробовать в продакшен и всё умерло. Я отвечал за расчтёты по ценам. Там вообще HP-PA 2.0 умирал по сравнению с 486DX. Зато всего $50,000 за K-9000. Стали искать, а что можно сделать. В общем, дошли до V серии с 32 процами, чтобы было похоже. Но дисковая система всё равно тормозила. А V серия уже $300,000 и более. И контракт на сопровождение другой — дороже. Для решения дискового вопроса пришлось EMC прикупить. А он сам стоил около полулимона и контракт. Вот так сэкономили. Плевались потом, но тут IBM купила Sequent и убила. И все плеваться перестали.

HolyBoy> Долгими. Разными. Например, у меня один из тестов выявил, что vmware video не дружит с KVM.

KVM — это что у тебя? ВМ с поддержкой на уровне ядра (Main Page - KVM) или переключалка клавы/мыши/видео? Если первое, то зачем vmware video — там своё есть?

HolyBoy> Не такое же. И дело тут не только в приобретении железки. К примеру, одна из железок по E1 потоку связана с провайдером телефонии и нашей внутренней АТС. Если её дублировать на другом хосте, то физически провода и места, куда их втыкать, неоткуда взять.

Хм, т.е. ты хочешь протянуть аппаратную поддержку по сети? А кто драйвера писал под это дело? А как же быть с железячными таймаутами и прочими прелестями? А что делать, если хост ОС упадёт? Т.е. у тебя не получается повысить надёжность за счёт кластера в этом месте — всё равно одна точка отказа.

HolyBoy> Поэтому, хочется, чтобы не упала ВМ, когда мигрирует с хоста, на котором есть железка, на тот, где её нет. Тогда, завязанная на IP часть будет работать и телефония останется для тех, кто этой частью пользуется.

У тебя с коробками связь по IP, правильно? Астериск только так, вроде, работает. Или есть карточки воткнутые прямо в машину? Если по IP, то надо делать согласование внутренних состояний двух сереверов астерикса для быстрого горячего подъёма. Если с железяками, то смотри параграфом выше.

HolyBoy> Либо, придётся делать 2 ВМ с астерисками: одну жёстко привязать к железке, вторая будет мигрировать и связываться с первой по IAX2. И так со всем прочим уникальным оборудованием, к примеру, от 1С.

А, если первая упадёт, что будет со связью по IAX2? И со связью с шелезяками?

Mishka> KVM — это что у тебя? ВМ с поддержкой на уровне ядра (Main Page - KVM) или переключалка клавы/мыши/видео?

Миш, разговор про виртуалки, какая тут переключалка⁈ (обрати внимание, он уже давно не соответствует разделу и теме)

Mishka> Если первое, то зачем vmware video — там своё есть?

Эмулируемая видеокарта. Могут быть разные. Я, поперву, включил vmware. Оказалось, что зря.


Mishka> Т.е. у тебя не получается повысить надёжность за счёт кластера в этом месте — всё равно одна точка отказа.

Я знаю. От этой точки никуда при текущем состоянии не уйти.

PCI по сети прокидывать смысла нет, даже если бы это и было возможно: Астериск слишком чувствителен к таймингам шины. Вариант из этого пункта: 1 мигрирующая ВМ, постоянно находящаяся на хосте с железякой и уходящая с него при каких-либо проблемах. Если при этом ничего, кроме связи по железке не отвалится, а при возврате всё восстановится, то он будет жить. Разумеется, связь по IP должна оставаться всегда.

Mishka> У тебя с коробками связь по IP, правильно? Астериск только так, вроде, работает. Или есть карточки воткнутые прямо в машину?

А это второй вариант, если предыдущий не сработает: запустить на машине с железом никуда не мигрирующую ВМ с Астериском, связать её по IP с другой, мигрирующей ВМ. На этой мигрирующей будет и основной диалплан и проч. и проч. В соответствии с этим диалпланом, звонки, которые должны идти через железки, будут по IAX2 посланы на первую ВМ.

Соответственно, если умрёт хост с железякой, то трафик между Астерисками прервётся, но звонки по IP будут продолжать приниматься/отправляться.

Т.о., в итоге всё равно надёжнее должно стать, чем сейчас, когда Астериск на одном хосте стоит и обслуживает как через железки, так и через IP.

Mishka> А, если первая упадёт, что будет со связью по IAX2? И со связью с шелезяками?

Если мигрирующая упадёт, то, связь с ней разорвётся, как и у всяких TCP-соединений, по таймауту.

А дальше, скорее всего, используя SRV-запись из DNS, клиенты определят, что пора подключаться к резервному Астериску. Скорее всего, к ещё одному на мигрирующей ВМ.

Собственно, целью придумывания этих вариантов было решение проблемы с уникальным немигрирующим железом. С мигрирующими ВМ проще: если надо, то просто добавляешь, пока ресурсы есть.


Вот с 1С всё хуже и лучше одновременно.

Там уникальное железо — ключ аппаратной защиты на USB, даже три: для сервера и пара — для клиентов. Соответственно, думать о покупке дополнительных никто не будет, и так уже расходы на IT нехилые выходят, т.к. собираемся попутно активное сетевое оборудование менять. Зато USB проще переставлять с хоста на хост, чем PCI-карты и существует проект usbnet. Посмотрим, что там получится сделать.


PS Очень интересно сперва спроектировать, какие сервисы и в каком количестве нужны, а затем, реализовать весь этот набор. Этим виртуальная среда мне нравится.

HolyBoy> И наши авиабазовские эльфы будут ещё рассказывать, что-то про «злых инородцев»? Ежели власти безнаказанно, как показано/рассказано в последние минуты, тырят такое бабло, то
..то они ничем не отличаются от воров при власти в любой иной точке мира.
Кстати новое продолжение уже 11-летнего марлезонского балета про "новую АЭС", на которую пилилось уже забыл сколько раз.

Westinghouse о новой АЭС: мы готовы инвестировать

Посетившие Литву в четверг представители консорциума Toshiba и Westinghouse подтвердили свое намерение инвестировать в новую атомную электростанцию в Литве и представили свое предложение. Его содержание не раскрывается.

«Факт, что премьер занимает руководящую позицию в этом проекте, показывает, насколько важен этот проект для Литвы и региона. (...) На самом деле, Westinghouse настолько уверен, что этот проект будет успешным, что готов в него инвестировать», – сказал после встречи с премьером Андрюсом Кубилюсом президент Westinghouse в регионе Европы, Среднего востока и Африки Андерс Джексон.

Он подчеркнул, что этот проект очень интересен компании. Джексон назвал сильные стороны компании – надежность и безопасность, а также гарантию, что АЭС будет построена вовремя и не выходя за рамки бюджета. (гы! прим. моё)

«В настоящее время мы осуществляем восемь проектов, и все они выполняются по намеченному графику», – утверждал он.

Toshiba хочет включиться в строительство АЭС в Литве, так как стране будет необходима независимый источник энергия. «Мы можем предложить топливо, строительство, эксплуатацию и надзор», – сказал после встречи старший вице-президент корпорации Toshiba и президент принадлежащей ей Power Systems Company Ясухару Игараши.

«Westinghouse является одной из наиболее ярких мировых компаний по развитию ядерных технологий. Мы оцениваем внимание этой компании как очень серьезные намерения потенциального инвестора. В настоящее время идут переговоры, предложения еще могут уточняться. Деталей мы не откроем, так как идут очень интенсивные переговоры», – сказал в четверг журналистам Кубилюс.

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

На прошлой неделе премьер встретился с гостившим в Литве президентом еще одного возможного стратегического инвестора – Hitachi, Хироаки Наканиши, который представил предложение своей компании.

Окончательное решение о возможном стратегическом инвесторе планируется принять в июле.

Литва вместе с Польшей, Латвией и Эстонией надеется построить новую АЭС в 2018-2020 г. Несколько недель назал премьер Андрюс Кубилюс сказал, что реальное строительство начнется в 2014 г.

Ранее стратегическому инвестору планировалось отдать 51% акций новой электростанции.

---

Вилемас: Литве подошел бы американский реактор

Находящиеся в Литве предствители консорциума Toshiba-Westinghouse сегодня подтвердили, что готовы стать инвесторами в строительство новой Висагинской атомной электростанции и предложили реактор мощностью в 1000 мегаватт, сказал руководитель Литовского института энергетики, профессор Эугениюс Ушпурас.

Он в интервью DELFI рассказал, что об этом услышал на презентации, прошедшей в Министерстве энергетики. Правда, о цене реактора ничего сказано не было.

Почетный профессор Каунасского технологического университета, академик Юргис Вилемас считает, что Литве подошел бы именно американский реактор.

На прошлой неделе в Литве гостил президент еще одного возможного стратегического инвестора - японской компании Hitachi - Хироаки Наканиши, который представил предложение своей страны. Японцы предлагают установить улучшенные кипящие ядерные реакторы ABWR нового поколения.

Главное - цена и модель финансирования

«Оба подходящие (реакторы), не могу ни один проталкивать, оба хороши. Сейчас, думаю, самое главное – какую цену и какую модель финансирования предложат. Однако об этом на встрече не говорилось, так как это коммерческие дела. О них известно только переговорной группе (Литва на данный момент ведет прямые переговоры с возможными инвесторами – DELFI)», - сказал сегодня Э.Ушпурас.

По его словам, американцы готовы инвестировать в Висагинскую АЭС.

«Обычно производители оборудования не бывают стратегическими инвесторами, однако сегодня американцы подчеркнули, что для них это несколько необычно, но они могут быть и стратегическими инвесторами», - сказал собеседник. (вероятно, власти упомянули о том, какими правами обладал стратегический инвестор Вильямс интернешнл, благодаря которому прямые убытки государства от деятельности компании составили более полутора тогдашних бюджетов страны. прим моё)

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

Один реактор обойдется минимум в 12 млрд. литов

Тем временем, Ю.Вилемас уверен, что Литве больше подходит американский реактор - как по технологическим параметрам, так и по мощности.

«Американские реакторы – это технологии сжатой воды. На данный момент у более 90% строящихся атомных электростанций – реакторы с водой под давлением. На Фукусиме, где произошла авария, был проект General Electric, и у них есть слабое место. В этой ситуации, возможно, психологический перевес на стороне реактора со сжатой водой. Многолетний опыт эксплуатации показывает, что они несколько лучше, чем кипящие ядерные реакторы», - сказал DELFI энергетик.

Jurgis Vilemas
© DELFI (A.Didžgalvio nuotr.)
Сейчас четыре таких энергетических блока строятся в Китае, строительство собирается начать и США.

Кроме того, по его словам, предлагаемые японцами реакторы несколько велики.

«И мощность кипящего ядерного реактора несколько велика – 1350 мегаватт, а для Литвы – чем меньше реактор, тем лучше. Реактор Westinghouse меньше – в 1000 – 1200 мегаватт. Например, основные строители атомных электростанций китайцы даже не думают работать с кипящими ядерными реакторами», - сказал Ю.Вилемас.

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

Mishka> Так для девелопмента была машинка на 4 486 на 25 МГц, а в продакшене стояло две 8 процессорных на 486 на 50МГц. Ну и памяти было больше. Так везде стояли ящики со сказёвыми дисками — 60 2 гиговых или 30 4 гиговых.

«Это канал про анимэ?»

а вообще прикалывает, как из кудрина делают новую икону
И стОит только показать на его собственные заявы, показывающие, что он тоже жук пилильщик - сразу недовольные минусы ))
Без аргументов, что характерно