Вторую сессию я освещать не буду, так как ничего особенно нового для себя я не увидел. Всякие там кунштюки, которыми пользуются хакеры, аудиторы и администраторы для проверки сетей, систем и голов на прочность сами по себе вещь интересная, но рассказано откровенно нового ничего не было.
Третья сесия для меня опять оказалась посвящена MOSS. На сей раз речь шла о Large-Scale deployments, то есть об инсталляциях, в которых от терабайта и более данных завязано в SharePoint.
1) PoSh. Собственно, не новость – PoSh это наше все, в больших фермах очень должен будет в будущем выручить администраторов многих ферм или больших ферм.
2) Старый факт, гласящий, что в одной базе данных может храниться много коллекций сайтов (несколько тысяч, вообще говоря), а вот одна коллекция сайтов не может быть растянута на несколько баз остается истиной и в MOSS 2010.
3) Докладчики особо упирали на то, что 99% проблем с производительностью sharePoint это проблемы с SQL. Пришлось добавить в их список еще некоторые экзотические сценарии.
4) Схема отношений баз данных по степени бурности I/O выглядела приблизительно так:
Разумеется, есть всякие оговорки, что имеется в виду общий рисунок I/O, а не, скажем, во время резервного восстановления и прочее. Однако, как было сказано, таких паттернов, как для сильно нагруженной базы поиска не видывали даже в команде Exchange. Это цитата, если что =)
5) Интересный метод обнаружения проблем: если на Front-End сервере резко возрастает потребление памяти, значит, есть какие-то проблемы. Обычно, опять-таки, с базами или с общей производительностью.
6) Как не поддерживалась никакая репликация данных средствами ни SharePoint, ни SQL, так и не поддерживается. И ничто не предвещает. Ну и обойдемся – есть решения третьих компаний. Хотя… =)
7) Разные вкусности для регулирования размеров запросов. Например, можно ограничить этот самый размер и тут же сказать, что вот с десяти утра, скажем, в течении трех часов можно и больше.
8 Для администраторов так же есть встроенный BPA, возможность из коробки отслеживать самые медленные страницы или смотреть, что и сколько времени заняло при выполнении того или иного запроса. То есть теперь можно определить, что виновато в медленно открытии страницы: база, Front-End или Web-Part.
9) На логи можно повесить обработчик событий, аналогично Event Viewer’у в Windows 2008.
10) Самое главное для меня, из-за чего я уже почти готов обновляться: MOSS 2010 IS FREAKING SQL MIRROR AWARE!!! То есть теперь я могу наконец-таки встроенными средствами обеспечить работу своих порталов с зеркалированными базами. Это ли не прекрасно? =)
В общем, посмотрим, благо, публичная демо-версия будет доступна уже в ноябре.
Комментариев нет:
Отправить комментарий