информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяАтака на InternetЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Ташовикажете! Даёшь WorkGroups :) 06.03.09 16:43  Число просмотров: 3190
Автор: Ustin <Ustin> Статус: Elderman
<"чистая" ссылка>
> Долго смеялся, читая "страшилки" про срыв бизнес-процессов при перегрузе DC.
Ташовикажете! Даёшь WorkGroups :)
На самом деле это всего лишь пример. Ответьте пожалуйста на вопрос
> > что будет, если требования к какому-либо серверу изменятся, а всё "планировалось" под завязку? Как считать сервис/логический сервер, который имеет многобольшее пиковое потребление с нерегулярным наступлением этих самых пиков, а ещё и в сочетании с высокой критичностью для бизнеса?
в рамках Вашей модели?

> На моем личном 10-летнем опыте имелись DC на базе Pentium-II 350 и 96 Mbyte памяти которые без труда осиливали 800 пользователей без особого напряга.
А некоторые и мышей едят (с).
> Кроме того, все это мониторится уже много-много лет по SNMP и есть статистика
> по загрузке процессора и памяти DC. Ну вот например статистика по двум из таких
> DC за прошлый месяц. Средняя загрузка ЦП у обоих = 0%, пиковая загрузка 10% :))
Этот бизнес не вкладывается в свою инфраструктуру - либо он крайне убыточен, либо собирается за бугор с чемоданом денег. Заявленная техника должна была быть амортизирована ещё до 2004 года. Я не думаю, что кем-то востребованы методики по созданию убыточного бизнеса :) Богатые и успешные организации, я подозреваю, - не держат такого хлама на столь критичных участках.

> А теперь еще один тихий вопрос. А что на физических компьютерах при перегрузке автоматом поднимается частота процессора и запрыгивают модули памяти? :))
А должны? Вы сами в работе (лень искать) пишете, что типа физические компьютеры имеют неоправданно большие аппаратные возможности и предлагаете их сократить раз во много. Так что на физмашине _в рамках вопроса_ перегрузка намного менее вероятна и продолжительна по времени

> Иными словами, запас по ресурсам закладываются и в случае виртуальных
> машин и в случае физических компьютеров. В моей методики заложены и запасы
> и тестирование в режиме пика бизнес-процессов, только все это в одной статье
> не напишешь. Подробности найдете в самой работе. Ссылки на нее в статье есть.
Тут не телепаты, а в работе о методиках тестированиявообщеничего не сказано - а это, ИМХО, важная часть.

> Кстати распределяются не сервисы по серверам, а виртуальные машины по физическим
> компьютерам.... Следовало бы повнимательнее читать прежде что-то комментировать...
виртуальные машины - не сервисы? физические компьютеры - не сервера для них? Придирка к терминологии, т.к. придраться больше не к чему :)

> Матрица требований - действительно статическая... А вы что владеете
> серверным парком в котором серваки на ходу меняют частоту процессора
> и емкость памяти в зависимости от нагрузки от приложений и сервисов? :)
best practice вам в помощь. Вы можете поместить несколько подобных "нерегулярных" приложений в среду с вытесняющей многозадачностью и будет счастье

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

> Судя по комментариям, в самой дискретной оптимизации вы ничего не поняли
> или даже не пытались ввиду, видимо, нулевых знаний в этой области. Жаль.
Что есть дискретная оптимизация?

> Ну и наконец, критиковать чужое - мы всегда молодцы. А что лично ВЫ можете предложить по этому вопросу?
Кроме метода последовательных итераций (проб и ошибок * на здравый смысл) (читай - best practice) общего решения нет. Более того, оно, скорее всего, и не нужно (вобщемслучае) (спорно конечно, но даже в очень больших "бизнесах" всё решает именно этот самый BP), т.к. вероятность отказа старого к моменту оптимизации сервера от повышения загрузки оказывается неприемлемо высокой для начала собственно процедуры оптимизации.

> Только не отсылайте меня по ссылкам к Вest Practice - это сборник шаманских заклинаний для раболепных IT-обезьян :))))
Даа? Поверьте, у Вас предвзятое мнение :)
<site updates> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach