Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Ташовикажете! Даёшь 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-обезьян :)))) Даа? Поверьте, у Вас предвзятое мнение :)
|
|
|