Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | |
Вероятно так. 18.03.09 10:49 Число просмотров: 2898
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Мне кажется под дискретной оптимизацией понимается
> параметрическая, где параметры - дискретные. Не более того.
Вероятно так.
> По поводу самой работы - не понимаю вообще зачем ее читать
> и спорить о ней, если она только сообщает "вот я проделал
> ...
> при этом обсуждение сформировалось нешуточное. Что
> обсуждаете?
Проскочила какая-то идея. Вероятно неплохая. Я не совсем врубился. Второго марта выдвинул мысль, что есть более эффективные способы решения таких задач. Контраргументов не последовало.
В принципе проблема использования скрытых ресурсов встала уже давно, как только начали производится от 100Мгц процессоры. В пике и гигагерца мало, но пик короток. В результате мы сидим сутками за компами, используя не более 0.1%-1% процессорных ресурсов. Расточительство. С винтами то же самое. В офисах на дисках, емкостью от 100Гб стоит только ОС, МСОфис и чуть других прог общим весом 2-3Гб. С оперативкой та же история. Вот и начали появляться проекты распределенных вычислений, распределенные сетевые хранилища. Предствте, что задача хорошо параллелится, а в офисе парк на сотню компов. С чем мы иногда в результате сталкиваемся? На некоторых базах получение выписки может затягиватся на несколько часов. Программеры нахуевничали однозначно. С другой стороны сэкономили бабло на программерах, задействовали парк техники на 90% и то, что раньше считалось час, сейчас на 60 компах считается минуту. Для этого какой-то инструмент нужен, но какой? И этот вопрос слишком глубокий.
|
|
<site updates>
|
Концептуальный подход к повышению эффективности использования вычислительных ресурсов корпоративных сетей при применении технологии виртуальных машин 28.02.09 13:06
Publisher: dl <Dmitry Leonov>
|
Концептуальный подход к повышению эффективности использования вычислительных ресурсов корпоративных сетей при применении технологии виртуальных машин
П.А. Рахман
Аннотация
В статье рассматривается проблема повышения эффективности использования вычислительных ресурсов в современных корпоративных сетях, анализ существующих подходов к ее решению и обзор предложенного автором метода решения проблемы, базирующегося на применении технологии виртуальных машин. Подробно рассмотрены алгоритмы двухэтапной реорганизации корпоративной сети с целью повышения эффективности использования вычислительных ресурсов при применении технологии виртуальных машин.
Полный текст (pdf, 160k) [ .keep/vminfra1.pdf ].
Полный текст
|
|
Господа! Спасибо за высказанную критику, однако, давайте... 08.07.09 22:03
Автор: PavelAR Статус: Незарегистрированный пользователь
|
Господа! Спасибо за высказанную критику, однако, давайте расставим кое-какие точки над i:
1) Сама по себе виртуализация - не моя идея, об этом еще говорили лет 60 назад, а то и раньше.
Хотя и идея витала давно, но реально активно воплощаться в жизнь в виде конкретных програм-
мных решений конкретно для PC-шной платформы только в конце 90-х годов. Могу ошибаться, но
кажется именно VMware Inc. начала первая активно продвигать свое ПО для виртуализации, по-
том с опозданием Microsoft и некоторые другие компании присоединились к этому делу. Так что
спорить о самой идее виртуализации глупо. Она дает и плюсы и минусы, пессимисты и парано-
ики склонны преувеличивать минусы, остальные же используют ПО от VMware и счастливы :)
2) Таким образом, речь сейчас не о том, плохо или хорошо заниматься виртуализацией сервер-
ного парка, а о том если уж делать (то есть решение о виртуализации считается уже принятым),
то как лучше к этому подойти. И здесь вариантов немного: первое - раскидать виртуальные ма-
шины наобум по хост-машинам (как делает большинство, ибо это проще всего), второе - все же
включить мозг и подойти к задаче распределения не как IT-слесарь, а как IT-инженер. Инженер в
отличие от слесаря собирает некоторые исходные данные (включая разного рода статистику) и
затем на основе некоторого метода (как правило математически обоснованного) получает неко-
торое обоснованное инженерное решение, которое он внедряет, потом тестирует, если что-то не
так, ищет причины этого, вносит коррективы в исходные данные, снова решает, ну и так далее...
На момент 2005 года, перекопав множество наших и еще большее число зарубежных источников
по теме исследования ничего путного не нашел, везде были только рекламные лозунги, что типа
виртуализация это круто, плюс к этому несколько вариантов "с потолка взятых" рекомендаций
по поводу распределения ресурсов и не более того. Поэтому я и взялся за формализацию (в том
числе и математизацию) задачи распределения виртуальных машин по физическим компьютерам,
и я получил некоторую законченную методику проработанную и с точки зрения строгой математи-
ки, так и с точки зрения инженерных нюансов... Но разумеется, все нюансы учесть невозможно и
идеальную процедуру по оптимизации серверного парка при внедрении технологии виртуальных
машин создать никому не под силу, даже Microsoft или VMware (на момент когда я закончил свою
методику, они вообще никаких методик не предлагали оставляя все на усмотрение и опыт адми-
нов, которые тем более не заморачивались и делали так, как больше нравится). Однако, это была
первая методика, то есть хоть что-то в условиях, когда вообще ничего не было. Теперь, конечно,
в VMware тоже спохватились, проводят исследования, ну и в их флагманском продукте VMware
Infrastructure 3 появилась такая фича как DRS (что-то типа автоматизированная система анализа
загрузки ресурсов ESX-хостов, и ручного или автоматического перераспределения виртуальных
машин по ESX-хостов. Разумеется DRS - это ноу-хау, ее суть хранится в тайне за семью замками.
3) В последние годы интерес к теме оптимизации при виртуализации ресурсов у меня практически
сошел на нет и потому дискутировать об этом особым желанием не горю. Проще говоря, в свое вре-
мя я предложил некоторую методику, на тот момент никаких других более менее научно обоснован-
ных альтернатив не было. Кому нравится - использует ее, кому не нравится - не использует, кто-то
вообще ненавидит саму идею виртуализации как таковую, и до всего до этого мне нет никакого дела.
Как говорится не нравится - не ешьте, придумывайте что-то свое, если способны, а я покритикую :)
|
| |
Cовременные реалии показывают, что жесткая привязка... [fix] 09.07.09 03:15
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 09.07.09 03:30 Количество правок: 3
|
Cовременные реалии показывают, что жесткая привязка виртуальных серверов к хостам себя уже изжила. Сейчас широко применяется автоматическая миграция виртуальных серверов кластера между физическими серверами. Да и VMware сильно утрачивает свою актуальность всвязи с очень быстрым развитием Hyper-V.
> 3) В последние годы интерес к теме оптимизации при
> виртуализации ресурсов у меня практически
> сошел на нет и потому дискутировать об этом особым желанием
> не горю. Проще говоря, в свое вре-
> мя я предложил некоторую методику, на тот момент никаких
> других более менее научно обоснован-
> ных альтернатив не было. Кому нравится - использует ее,
> кому не нравится - не использует, кто-то
> вообще ненавидит саму идею виртуализации как таковую, и до
> всего до этого мне нет никакого дела.
> Как говорится не нравится - не ешьте, придумывайте что-то
> свое, если способны, а я покритикую :)
А смысл? Мы используем то, что уже придумано и расчитано - остается только применить. Здесь в основном инженеры, а не ученые. Если сказано производителем софта, что для "того-то" рекомендуемые системные требования "такие-то", то зачем утруждаться и проверять сие утверждение пересчетом по сложным алгоритмам? Надо просто последовать рекомендациям производителя.
|
| | |
Что же... вторую особенность местного IT-населения я тоже... 09.07.09 15:41
Автор: PavelAR Статус: Незарегистрированный пользователь
|
Что же... вторую особенность местного IT-населения я тоже уловил - современный российский
IT-инженер = де-факто слесарь. Также как электрик или сантехник не заморачивается никакими расчетами пользуясь готовыми шаблонными решениями и рекомендациями, к которому его нау-
чил его мастер-наставник (тоже слесарь, только постарше), так и наш IT-шник открывает guide,
manual или help, находит подходящий вариант для своей задачи, и набирает последовательность
команд (или кликов мышью в нужных меню) один в один как указано в шаблонной инструкции, ну
разве что только IP-адреса и названия различного рода объектов отличаются. В лучшем случае
потом делает некоторый "тюнинг" (громко называя это оптимизацией), но опять же не на основе
анализа и расчетов обоснованными методами, а на основе "так кажись наверное будет лучше".
Мне казалось народ здесь с более или менее адекватным высшим техническим образованием
и может отличить банальную слесарскую настройку по guide от инженерного проектирования.
Не хотел никого обидеть, но факт остается фактом, IT-инженеров здесь нет, только IT-слесари,
вечно ожидающие чужие (в основном западные решения), не имеющие никаких собственных.
P.S. Ради интереса в той же Википедии посмотрите определение термина "Инженер" - специа-
лист с высшим техническим образованием, создатель информации об архитектуре материаль-
ного средства достижения цели или способа изготовления этого средства. Всем желаю удачи.
|
| | | |
Вы говорите очень странные вещи... 09.07.09 16:37
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 11.07.09 01:36 Количество правок: 2
|
Вы говорите очень странные вещи...
Да, здесь есть люди с адекватным высшим образованием, но не эти люди писали машины виртуализации и встраивали в процессоры Intel поддержку виртуализации. Те, кто это делал, описали методы и дали необходимые рекомендации по реализации.
Нет смысла заниматься расчетами необходимого быстродействия железа, но есть смысл заниматься расчетом надежности системы - хранения, резервирования и обработки данных, используя методы и рекомендации производителей технологий.
> P.S. Ради интереса в той же Википедии посмотрите
> определение термина "Инженер" - специа-
> лист с высшим техническим образованием, создатель
> информации об архитектуре материаль-
> ного средства достижения цели или способа изготовления
> этого средства. Всем желаю удачи.
И я о том же самом. Не больше - не меньше.
|
|
Поначалу думал научпоп статья для СМИ журнала... 11.04.09 00:00
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 11.04.09 00:05 Количество правок: 1
|
... уж слишком не ИТшный язык :)
Потом глянул список литературы, особенно 5 источник, и понял, что это академический язык, а я его подзабыл, уже более пяти лет практик :)
Еще догадываюсь, что текущая статья - это на дтн?:)
Теперь по сути.
Сказано много и верно, но основным трендом ИТ управления является - ИТ как инструмент для бизнеса и соотв. СОА и ИТИЛ/ИТСМ. Методики ИТСМ достаточно формализированы и позволяют построить детерминированные (те в числах) индикаторы эффективности. Но числа эти актуальны только конкретного бизнеса, а копи-паст текстов ИТСМ в статье излишен.
В задачи реорганизации пропущена часть анализа бизнес потребностей. С результатом которой необходимо сравнивать анализ существующей ситуации. И искать пути решения найденных расхождения. Стоимость изменений, последствия изменений.
Также, в описании выбора серверного оборудования, пропущен фактор управляемости серверной инфраструктурой, который имеет не меньший весовой коэф, чем описанные мощность, доступность и тд. Фактор управляемости не дает преимуществ бизнес сервисам напрямую, но влияет на остальные факторы.
Адекватно реализовать управляемость возможно только на специализированной серверной платформе, поэтому гонятся за мелкой памятью или накопителями никто не будет. Тк они на данное время изначально в сегменте не серверного аппаратного обеспечения.
В стоимость владения ИТ инфраструктурой забыли добавить стоимость ИТ окружения, например, охлаждение и (параметры) питания.
Думаю, необходимо доработать терминалогию, исправив в соотв с мировыми ИТ тредами.
Первую часть "ни о чем", с "бытовыми" сравнениями и описаниями, те без метрик, значительно сократить, сосредоточившись на теме виртуализации. Убрать "бытовую" формализацию угроз. Реализация требований бизнеса, в тч и по непрерывности, не зависит от виртуализации как таковой. Реализовать возможно и на физических серверах. Виртуализация - это не более чем инструмент для реализации требований, а будет ли он более эффективный, чем другие инструменты - вам и надо показать, желательно в математической модели :) Иначе теряется научность - повторяемость.
Сосредоточиться на подходах (как то так термин должен звучать) управления распределения виртуальных машин с целью оптимального использования вычислительных мощностей серверных аппаратных средств. Остальные метрики необходимо рассмотреть в контексте не ухудшения их значений и, возможно, улучшения.
Причем не стоит это управление выносить в бизнес. Современные средства виртуализации позволяют автоматически распределять исполнение виртуальных машин по разным алгоритмам и весовым коэф.. А если и не автоматически - то это задача не бизнеса (заказчика и постановщика требований ИТ сервисов), а ИТ (исполнителя требований).
В задачах виртуализации есть и другие задачи (по ИТСм), не только управление мощностями, а они совсем не раскрыты.
ЗЫ: я бы не стал делать скоропалительные и неправильные выводы, например, что рабочие станции изначально слабее серверов. Их характеристики соответствуют бизнес требованиям выполняемых на них бизнес операциях. Те графические и музыкальные станции значительно превосходят контроллер АД, но "пролетают" перед "калькулятором"-рендером. также в пролете рабочие места персонала АХО (секретаря, например) :)
|
| |
Спасибо, наконец-то, первый серьезный конструктивный... 15.04.09 22:00
Автор: PavelAR Статус: Незарегистрированный пользователь
|
Спасибо, наконец-то, первый серьезный конструктивный комментарий.
По поводу модели - смотрите вторую мою статью на этом же сайте и
тоже надеюсь на конструктивный комментарий. Сама по себе статья
не имеет никакого отношения к получению какой-либо ученой степени,
и тем более каких-либо надбавок за них, о которых тут истерично вопил
один оппонент, не имея ничего другого сказать более конструктивного.
|
|
К сож. статья ни о чем... 06.03.09 09:44
Автор: 3pt Статус: Незарегистрированный пользователь
|
К сож. статья ни о чем...
...А надеялся на лучшее...
|
| |
Угу, тем более в разделе internals. IMHO, место этим произведениям в misc, если место вообще 06.03.09 10:07
Автор: Ustin <Ustin> Статус: Elderman
|
|
|
| | |
Я тоже надеялся на более конструктивные комментарии, 06.03.09 13:18
Автор: RahmanPA Статус: Незарегистрированный пользователь
|
Я тоже надеялся на более конструктивные комментарии,
а не каменты в стиле "низачот", "фтопку". Ну раз на большее
интеллекта не хватило, спасибо и за эти невероятно "обос-
нованные" и "аргументированные" замечания :)
|
| | | |
Без обид. Тут не роботы, а люди. У каждого свой характер и... 10.03.09 12:52
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 10.03.09 12:57 Количество правок: 1
|
> Я тоже надеялся на более конструктивные комментарии,
> а не каменты в стиле "низачот", "фтопку". Ну раз на большее
> интеллекта не хватило, спасибо и за эти невероятно "обос-
> нованные" и "аргументированные" замечания :)
Без обид. Тут не роботы, а люди. У каждого свой характер и эмоции. Не игнорируйте резкие высказывания. Попробуйте за любыми фразами найти то, что вы ищите. "Низачет" и "фтопку" - отрицательный отзыв, а отрицательный результат тоже результат. Ждать, что потребность в виртуализации будет 100% глупо. Для определенной группы задач и 1% это очень много. Взглянув на проблему со стороны хочется заметить, что где-то идея может и пригодиться, но ждать того, что хотя бы 10% потенциальных пользователей указательным и большим пальцем обнимут горло со словами "нам эта виртуализация нужна вот как!" не следует. Представте себя руководителем какой-нибудь коммерческой конторы и дайте ответ на вопрос "Что вы скажете человеку, который будет вам предлагать воспользоваться уникальной системой распределенных вычислений типа dnet"? Только не представляейте себя руководителем РосГидроМета или Центра Ядерных Исследований.
|
| | | |
Слов "низачот", "фтопку" и проч не было 06.03.09 13:41
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 06.03.09 13:42 Количество правок: 1
|
, в то же время я довольно развёрнуто обосновал бессмысленность предпосылок и бесполезность Вашей работы для сообщества.
Т.е., возможно, расчёты в рамках матмодели и верны (я их не видел, т.к. в автореферате только описание, а в дисере, как я себе понимаю, должна быть какая-нибудь практическая часть), сама матмодель несостоятельна ввиду приведённых аргументов. И так как, я подозреваю, ответить нечто вразумительное на них Вам проблематично, Вы начинаете делать какие-то утверждения насчёт моего интеллекта
|
| | | | |
Ого! Ну и самомнение! :) Господин Ustin един в миллионах... 16.03.09 17:11
Автор: RahmanPA Статус: Незарегистрированный пользователь
|
> , в то же время я довольно развёрнуто обосновал
> бессмысленность предпосылок и бесполезность Вашей работы
> для сообщества.
Ого! Ну и самомнение! :) Господин Ustin един в миллионах лицах
некоего выдающегося сообщества :) Будьте любезны приложить
ФИО и подписи всех членов это поистину чудного сообщества :)
> Т.е., возможно, расчёты в рамках матмодели и верны (я их не
> видел, т.к. в автореферате только описание, а в дисере, как
> я себе понимаю, должна быть какая-нибудь практическая
> часть), сама матмодель несостоятельна ввиду приведённых
> аргументов. И так как, я подозреваю, ответить нечто
> вразумительное на них Вам проблематично, Вы начинаете
> делать какие-то утверждения насчёт моего интеллекта
"Матмодель несостоятельна" - и это мне говорит тот, кто сам
спрашивал меня в другой ветке комментариев "Что такое дис-
кретная оптимизация?" В наглости господину не откажешь :)))
|
| | | | | |
Я пока не услышал ни одного голоса "за" кроме Вашего, причём не аргументированного кроме как "Ustin-дурак" ничем 17.03.09 14:41
Автор: Ustin <Ustin> Статус: Elderman
|
> > Т.е., возможно, расчёты в рамках матмодели и верны (я их не видел, т.к. в автореферате только описание, а в дисере, как я себе понимаю, должна быть какая-нибудь практическая часть), сама матмодель несостоятельна ввиду приведённых аргументов. И так как, я подозреваю, ответить нечто вразумительное на них Вам проблематично, Вы начинаете делать какие-то утверждения насчёт моего интеллекта
> "Матмодель несостоятельна" - и это мне говорит тот, кто сам
> спрашивал меня в другой ветке комментариев "Что такое дис-
> кретная оптимизация?" В наглости господину не откажешь :)))
Чёрт, опять я попутал понятия... Не специалист я в вопросе, вычмат прогуливал...
Несостоятельна совокупность приближений исходной задачи к вашей матмодели, а с введением зависимости от времени сама матмодель становится непригодной для решения задачи, что и было по ошибке названо несостоятельностью матмодели.
То, что Вы пытаетесь выкручиваться введением поправок аля 25% свободных ресурсов не добавляет веса ни Вашим критериям, ни Вашей работе.
|
|
много букв :( про что там? 02.03.09 22:39
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
|
|
| |
Работа ни о чем... Много воды и мало конкретики. 03.03.09 15:33
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 03.03.09 19:00 Количество правок: 1
|
|
Ко всему прочему, там очень много сильно устаревших понятий и стереотипов.
|
| | |
Статья является одной из многих частей большой работы и в... 06.03.09 13:35
Автор: PavelAR Статус: Незарегистрированный пользователь
|
> Ко всему прочему, там очень много сильно устаревших понятий
> и стереотипов.
Статья является одной из многих частей большой работы и в силу ограничений
на количество страниц редакций журналов, работу приходилось резать и комп-
рессировать по содержанию. Хотите подробностей - ищите всю работу целиком,
в списке литературы ссылка на нее есть. Кроме того, все это писалось в 2004
году, и вполне возможно, что за 5 лет как производители, так и их поклонники
нагородили кучу новых терминов и стереотипов, называя старые известные
вещи новыми более пафосными и гламурными именами, и не более того :))))
|
| |
Нам поведали, что DC требует не более 64 МБ ОЗУ и порядка 1-1.5 ГБ дискового пространства 03.03.09 11:11
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 03.03.09 12:05 Количество правок: 2
|
, а также дали ещё одно пространное определение виртуальной машине.
Дальше идёт куча воды аля поиск эффективного оптимального распределения N сервисов по M серверам с заданными статическими весами в куче разных приближений разной степени приближенности, но нигде не написано, что будет, если мы отдадим DC заложенные афтаром ресурсы, а потом произойдёт пиковая нагрузка типа большой репликации по медленной линии (я не спец по DC, но тем не менее) и бизнес встанет нах (ну, если админа нет).
Другими словами, что будет, если требования к какому-либо серверу изменятся, а всё "планировалось" под завязку? Как считать сервис/логический сервер, который имеет многобольшее пиковое потребление с нерегулярным наступлением этих самых пиков, а ещё и в сочетании с высокой критичностью для бизнеса?
> Истинная же цель – решить задачу, обратную задаче балансировки нагрузки, то есть сосредоточить логические серверы на некотором множестве компьютеров таким образом, чтобы задействованные компьютеры были загружены максимально, а все незадействованные компьютеры были свободны
Матрица критериев не статическая - каждый критерий зависит от времени с разной предсказуемостью и степенью отклонения от среднего, поэтому:
Решение этой задачи не актуально никогда - оно в силе только в момент постановки.
Короче, может быть эта работа и имеет ценность, но только в сочетании с ещё большей работой по нахождению матрицы ограничений, которая, есть у меня очень сильное подозрение, будет далеко не булевой :) - и тем не менее человек получит учёную степень, так как продраться через рассуждения даже в автореферате неподготовленному человеку не так просто
http://www.microsoft.com/windowsserver2003/evaluation/sysreqs/default.mspx
|
| | |
Первый раз - утром, второй - вечером. Народ толпой идет... 29.05.09 10:13
Автор: lazy_anty Статус: Member
|
> произойдёт пиковая нагрузка типа большой репликации по
> медленной линии (я не спец по DC, но тем не менее) и бизнес
> встанет нах (ну, если админа нет).
Первый раз - утром, второй - вечером. Народ толпой идет работать, проходная гудит ))
|
| | |
Долго смеялся, читая "страшилки" про срыв бизнес-процессов... 06.03.09 14:00
Автор: RahmanPA Статус: Незарегистрированный пользователь
|
> , а также дали ещё одно пространное определение виртуальной
> машине.
> Дальше идёт куча воды аля поиск эффективного оптимального
> распределения N сервисов по M серверам с заданными
> статическими весами в куче разных приближений разной
> степени приближенности, но нигде не написано, что будет,
> если мы отдадим DC заложенные афтаром ресурсы, а потом
> произойдёт пиковая нагрузка типа большой репликации по
> медленной линии (я не спец по DC, но тем не менее) и бизнес
> встанет нах (ну, если админа нет).
> Другими словами, что будет, если требования к какому-либо
> серверу изменятся, а всё "планировалось" под завязку? Как
> считать сервис/логический сервер, который имеет
> многобольшее пиковое потребление с нерегулярным
> наступлением этих самых пиков, а ещё и в сочетании с
> высокой критичностью для бизнеса?
>
> > Истинная же цель – решить задачу, обратную задаче
> балансировки нагрузки, то есть сосредоточить логические
> серверы на некотором множестве компьютеров таким образом,
> чтобы задействованные компьютеры были загружены
> максимально, а все незадействованные компьютеры были
> свободны
> Матрица критериев не статическая - каждый критерий зависит
> от времени с разной предсказуемостью и степенью отклонения
> от среднего, поэтому:
> Решение этой задачи не актуально никогда - оно в силе
> только в момент постановки.
>
> Короче, может быть эта работа и имеет ценность, но только в
> сочетании с ещё большей работой по нахождению матрицы
> ограничений, которая, есть у меня очень сильное подозрение,
> будет далеко не булевой :) - и тем не менее человек получит
> учёную степень, так как продраться через рассуждения даже в
> автореферате неподготовленному человеку не так просто
Долго смеялся, читая "страшилки" про срыв бизнес-процессов при перегрузе DC.
На моем личном 10-летнем опыте имелись DC на базе Pentium-II 350 и 96 Mbyte
памяти которые без труда осиливали 800 пользователей без особого напряга.
Кроме того, все это мониторится уже много-много лет по SNMP и есть статистика
по загрузке процессора и памяти DC. Ну вот например статистика по двум из таких
DC за прошлый месяц. Средняя загрузка ЦП у обоих = 0%, пиковая загрузка 10% :))
А теперь еще один тихий вопрос. А что на физических компьютерах при перегрузке
автоматом поднимается частота процессора и запрыгивают модули памяти? :))
Иными словами, запас по ресурсам закладываются и в случае виртуальных
машин и в случае физических компьютеров. В моей методики заложены и запасы
и тестирование в режиме пика бизнес-процессов, только все это в одной статье
не напишешь. Подробности найдете в самой работе. Ссылки на нее в статье есть.
Кстати распределяются не сервисы по серверам, а виртуальные машины по физическим
компьютерам.... Следовало бы повнимательнее читать прежде что-то комментировать...
Матрица требований - действительно статическая... А вы что владеете
серверным парком в котором серваки на ходу меняют частоту процессора
и емкость памяти в зависимости от нагрузки от приложений и сервисов? :)
Ей-богу, это даже уже не смешно, а просто смертельно скучно...
Судя по комментариям, в самой дискретной оптимизации вы ничего не поняли
или даже не пытались ввиду, видимо, нулевых знаний в этой области. Жаль.
Ну и наконец, критиковать чужое - мы всегда молодцы. А что лично ВЫ можете
предложить по этому вопросу? Только не отсылайте меня по ссылкам к Вest
Practice - это сборник шаманских заклинаний для раболепных IT-обезьян :))))
|
|
|
подробно о проекте
Анализ криптографических сетевых...
