ARUBA INSTANT WI-FI: ПРОСТІ, ПОТУЖНІ, ДОСТУПНІ
Тодд Кліндт ([email protected]) - консультант по SharePoint, має звання SharePoint MVP
Йтиметься про те, що таке правильна настройка і як виправити настройки в фермі. Якщо ви зробите все так, як описано в даній статті, у вас будуть прекрасні умови для створення гарної ферми, по крайней мере, кількість помилок буде знижено.
Помилка № 1: економія на оперативній пам'яті або обсязі жорсткого диска для SharePoint
Я багато раз спостерігав безрадісну картину: бідний беззахисний сервер SharePoint працює на межі своїх можливостей, щоб ощасливити користувачів, але він зв'язаний по руках і ногах через обмежених ресурсів. Така ситуація є звичайною при «агресивному» віртуалізації. Сама по собі віртуалізація - річ непогана, але вона повинна бути організована розумно і без жертв з боку SharePoint.
Якщо SharePoint не вистачає оперативної пам'яті, це обмежує його функціонування, щоб міг втиснутися в доступний обсяг. SharePoint також отримує менше в пулах веб-додатків і перезаписує ці пули частіше. Зменшення кешування і збільшення повторних циклів запису знижує продуктивність SharePoint і уповільнює роботу кінцевих користувачів, оскільки SharePoint повинен компілювати той же самий код ASP.NET знову і знову. А нещасні користувачі не потрібні нікому.
Помилка № 2: використання віртуалізованних сервера Microsoft SQL
Як вже говорилося в попередньому розділі, віртуалізація - непогана річ. Але вона дозволяє адміністраторам робити помилки, скажімо так, у великих масштабах. Візьміть віртуальний SQL Server. В контексті SharePoint цей процес може бути особливо болючим. Головна помилка, яку я зустрічав під час віртуалізації SQL Server, - це перевантаження базового сервера (хоста), незалежно від того, що тому причиною - недолік оперативної пам'яті, часу процесора або простору на диску. Оскільки весь вміст SharePoint зберігається на сервері SQL Server, якщо SQL Server повільний, то і SharePoint буде повільним.
Очевидне рішення - перемістити SQL Server на фізичну систему, де йому не потрібно буде ділитися ресурсами. Переміщення SQL Server подалі від SharePoint - це нескладний процес, який описаний на сайті www.toddklindt.com/sqlalias.
Якщо ви не можете отримати фізичну систему для SQL Server, тоді, як мінімум, переконайтеся, що віртуалізованних екземпляр SQL Server може працювати. Для початку перевірте, чи правильно налаштовані його віртуальні диски. Введення-виведення - це одна з областей, де віртуалізованних SQL Server сильно навантажений, а погано налаштовані диски посилюють проблему. Крім того, постарайтеся встановити віртуальні диски гостьових систем SQL Server на окремі фізичні диски на хості. Це допоможе поліпшити введення-виведення, а значить, вбереже SQL Server від конкуренції з гостьовими системами. Нарешті, не слід дозволяти хосту віртуалізації перевищувати розмір власної оперативної пам'яті. Якщо хост повинен виконувати підкачування для того, щоб відповідати заданим розміром оперативної пам'яті, то SQL Server буде гальмувати.
Помилка № 3: використання майстра настройки ферми
Майстер налаштування ферми Farm Configuration залишає свої «брудні відбитки» по всьому SharePoint, і може бути проблематично «відмити» їх все. Однак деякі місця поправити можна. Почніть з своїх веб-додатків. Створіть веб-додаток для My Site і дайте йому повне доменне ім'я Fully Qualified Domain Name (FQDN), таке як mysites.company.com. Створіть хост My Site в кореневій папці веб-додатки. Використовуйте команду Windows PowerShell, яка називається Move-SPSite, для переміщення My Site в одну базу даних контенту, а потім приєднайте цю базу даних контенту до свого нового веб-додатку. Крім того, вам буде потрібно налаштувати служби User Profile Service і оповістити її про новий місцезнаходження My Site.
Помилка № 4: використання неправильного URL при створенні веб-додатки контенту
Проблема може здатися не такою вже глобальної, але вона виникає у багатьох в самий невідповідний момент: під час збою. У деяких випадках адміністратори оновлювали сервер SharePoint або їм було потрібно перебудовувати його, і вони забували про заголовках хоста, які вручну вказали декількома місяцями раніше. SharePoint відновлюється і працює, але під час з'єднання з SharePoint кінцеві користувачі бачать блакитну заповнює сторінку IIS 7 замість сторінки SharePoint, побачити яку вони очікували.
Оскільки SharePoint записує заголовки хоста тільки тоді, коли створюється веб-додаток, ви не можете виправити неполадки в веб-додатках. Доведеться створювати їх заново. Це і погано, і добре одночасно. Добре, тому що ви не втратите ні краплі контенту, на створення якого користувачі витратили багато зусиль. Погано, тому що ви втратите всі налаштування, над якими самі так старанно працювали.
Перший крок - це документування всіх ваших налаштувань веб-додатки. У більшості випадків їх трохи і ви розумієте всі зміни, які справили. Після цього від'єднайте базу даних контенту від свого веб-додатки. Збережіть бази даних, вони вам можуть знадобитися. Потім зробіть копію файлу web.config для цього веб-додатки. Деякі настройки, такі як аутентифікація на основі форм Form Based Authentication (FBA) і налаштування кеша BLOB, знаходяться в цьому файлі. Нарешті, зайдіть в Central Administration і видаліть веб-додаток. SharePoint доведеться видалити зайві матеріали. Найнебезпечніша частина роботи завершена.
Екран 1. Створення нового веб-додатки
Дуже важливо привласнити зрозумілі імена базі даних контенту. Вам повинно бути достатньо поглянути на ім'я бази даних контенту, щоб дізнатися, з яким веб-додатком вона взаємодіє. Це одна з тих речей, які здаються незначними, але є безцінними в разі відновлення після аварії. Якщо база даних контенту, яку ви від'єднали від веб-додаток перед видаленням, не має таких імен, скористайтеся нагодою, коли будете створювати веб-додаток заново. Дайте новій базі даних контенту зрозуміле ім'я, а потім за допомогою PowerShell-команду Move-SPSite для переміщення колекцій сайту в нову базу даних. Якщо у вашої бази даних вже є ім'я, введіть його під час процесу створення нового веб-додатки. Якщо у вас було кілька баз даних контенту, надішліть листа з що залишилися після створення веб-додатки.
Після того як веб-додаток створено, ви можете скорегувати налаштування так, як вам потрібно. Велика частина налаштувань може бути змінена в розділі Central Administration. Якщо ви виконали будь-які зміни в файлі web.config в вихідному веб-додатку, то тепер саме час скопіювати ці зміни в заново створений файл web.config. Ви можете використовувати таку програму як Notepad ++ (notepad-plus-plus.org) для порівняння цих двох файлів. У підсумку ви отримаєте добре написане веб-додаток, на яке можна буде покластися в разі збою.
Помилка № 5: запуск веб-додатків або службових додатків в роздільних пулах додатків
Веб-додатки та службові додатки запускаються усередині пулу додатки, який є процесом W3WP.exe, запущеним на сервері. Поки у вас немає причини робити інакше, слід запустити всі веб-додатки SharePoint всередині одного пулу додатків. Те ж саме стосується і службових додатків. Запуск кожного веб-додатки в своєму пулі додатки робить неефективним використання пам'яті сервера. Кожен пул додатків має мінімальний приріст більш ніж в 100 Мбайт, і його частка в пам'яті може бути збільшена в міру кешування часто оновлюваного контенту. На екрані 2 показано кілька процесів W3WP.exe, запущених як sp_webapps; це результат запуску веб-додатків в роздільних пулах додатків.
Екран 2. Результат запуску веб-додатків в роздільних пулах додатків
Всі ми стикалися з ситуацією, коли SharePoint «гальмує» вранці, оскільки пули додатків оновлюються після ночі і їм потрібно «розігрітися» і записати контент в кеш заново. Множинні пули додатків означають, що той же самий контент зберігається в кеші багато разів. Велика частина користувачів турбується. Багато з них при цьому розмірковують про способи покарання для нас, адміністраторів, за погану продуктивність SharePoint.
Що стосується службових додатків, то цю проблему легко вирішити. Перш за все, переконайтеся, що у вас хороший службовий пул додатків, який можна використовувати. Я рекомендую назвати його пул Default SharePoint Service App Pool, щоб він виявився у верхньому рядку всіх ваших списків. Використовуйте спеціальну обліковий запис sp_serviceapps (зверніться на сайт облікових записів www.toddklindt.com/service) для ідентифікації пулу. Більшість службових додатків дозволяють переводити їх в новий пул службових додатків шляхом зміни їх властивостей в Central Administration. Якщо ця можливість недоступна там, пошукайте її в PowerShell.
Веб-додатки - більш складний випадок. Непросто змінити пул додатка, який використовує веб-додаток. На щастя, в нашому розпорядженні є PowerShell. Опис цього процесу не відповідає темі даної статті, але я детально розповідаю про нього на сайті: www.toddklindt.com/changeapppool.
Помилка № 6: використання одного облікового запису для всього
Ви також можете виконати дії, які я описав на сайті www.toddklindt.com/sp_farm, щоб надати облікового запису правильні дозволу для адміністрування SharePoint без потреби у використанні іншого привілейованої облікового запису.
Помилка № 7: збереження налаштувань бази даних SharePoint за замовчуванням
Коли SharePoint створює своє сімейство баз даних, він робить кілька невдалих припущень. Наприклад, настройки автоматичного збільшення: файли бази даних увелчіваются по 1 Мбайт, щоб гарантувати, що вони будуть автоматично реагувати на найменше підвищення навантаження. Це не тільки сповільнює SQL Server (який уповільнює SharePoint), але і відбивається на файлах бази даних, які розподіляються по всіх дисках дуже маленькими фрагментами пам'яті в 1 Мбайт.
SharePoint також створює велику частину своїх баз даних, особливо бази даних Config і Content, з моделлю відновлення, налаштованої на Full. Це чудово, але якщо ви хочете відновити дані, ви повинні правильно управляти процесом або підступні файли.ldf будуть повільно і методично заповнювати жорсткий диск. Якщо ви думаєте, що користувачі турбуватимуться, коли побачать, що SharePoint гальмує через фрагментованих баз даних, уявіть, що вони зазнають, коли SharePoint повністю встане з-за повного заповнення дисків SQL Server.
Щоб виправити цю помилку, встановіть налаштування автоматичного зростання своєї бази даних так, щоб її не потрібно було нарощувати часто. Для більшості ферм я рекомендую змінити автоматичне зростання по 1 Мбайт до 500 Мбайт або 1 Гбайт. Автоматичний зростання повинен бути останнім засобом. Хтось, адміністратор SharePoint або окремий DBA, повинен заздалегідь наростити бази даних так, щоб автоматичне зростання був непотрібним.
Помилка № 8: блокування кешування BLOB
Не знаю як ви, але я ніколи не чув, щоб користувачі говорили: «SharePoint занадто швидкий. Чи не могли б ви зробити так, щоб він відповідав трохи повільніше? »Ми всі хочемо, щоб SharePoint доставляв користувачам файли так швидко, як тільки це можливо. Однак найчастіше я бачу ферми SharePoint з Неактивована кешуванням BLOB. кешування BLOB є одним з найпростіших і найменш дорогих способів підвищити продуктивність SharePoint. Це не тільки допомагає швидше доставляти користувачам файли, але і полегшує експлуатацію SQL Server. Всі виграють.
Це здається найпростішим рішенням: тоді давайте ж включимо кешування BLOB! Кешування BLOB насправді є функцією IIS; SharePoint просто отримує вигоду від цього. Таким чином, щоб активувати кешування BLOB, потрібно змінити файл web.config веб-додатки на кожному сервері. Така настройка вже існує, її потрібно просто активувати. За замовчуванням файли web.config знаходяться в каталозі диска С: \ inetpub \ wwwroot \ wss \ virtualdirectories. Кожне веб-додаток має підкаталог і файл web.config. Відкрийте один з цих файлів і пошукайте таку строчку:
Щоб активувати кешування BLOB, замініть False на True і збережіть файл web.config. Крім того, ви можете перемістити файл в каталозі на диску С на будь-який інший диск. Параметр maxSize вказує значення в гигабайтах, а за замовчуванням є 10 Гбайт. Якщо дозволяє простір, ви можете збільшити цей розмір.
Якщо редагування цього файлу в Notepad на всіх ваших серверах не доставляє вам задоволення, ви можете використовувати PowerShell для автоматизації процесу. Вам ще потрібно виконати процес на кожному сервері, але використання PowerShell швидше і знижує ймовірність помилки. Для початку завантажте сценарій з сайту www.toddklindt.com/blobcache і збережіть його у файлі, названому blobcache.ps1. Цей сценарій містить дві функції: Enable-SPBlobCache і Disable-SPBlobCache. Кожна функція бере веб-додаток з конвеєра і активує або блокує BLOB-кешування для цього додатка. Код для активації BLOB-кешування на кожному веб-додатку в фермі виглядає так:
Помилка № 9: не встановлено PDF iFilter
Більшість організацій має величезну кількість файлів PDF на фермах SharePoint. Кінцеві користувачі хочуть мати можливість досліджувати зберігається на них інформацію, використовуючи SharePoint Search. Установка PDF iFilter дуже проста. У Adobe є безкоштовний PDF iFilter, який ви можете інсталювати. Посилання на порядок завантаження і детальну інформацію можна знайти на сайті support.microsoft.com/kb/2293357. Вам потрібно встановити iFilter тільки на тих серверах, які грають роль Search Index, хоча установка на що залишилися серверах SharePoint теж не зашкодить. Якщо у вас велика ферма і ви хочете скоротити час індексування файлів PDF, ви можете використовувати PDF iFilter від Foxit (www.foxitsoftware.com). У цього продукту більш висока продуктивність, ніж у Adobe iFilter, але він платний.
І знову ви можете використовувати PowerShell, щоб полегшити завдання. Брайан Лалансетте, творець AutoSPInstaller (autospinstaller.codeplex.com), написав чудовий сценарій, який автоматично завантажує, встановлює і задає налаштування PDF iFilter. Даний сценарій є частиною пакета, тому я виділив відповідні частини і привів їх на сайті www.toddklindt.com/PDFSearch. Збережіть цей файл як pdfsearch.ps1. Він містить дві функції: Configure-PDFSearch і Configure-PDFIcon. Перша встановлює і задає налаштування iFilter, а друга додає значок PDF в інтерфейс SharePoint. Як і в описі сценарію в розділі «Помилка № 8», встановіть функції за допомогою файлу pdfsearch.ps1, а потім виконайте їх.
Помилка № 10: сервери SharePoint не спрямовані на самих себе
Я переконався, що кожен сервер в фермі SharePoint вказує сам на себе для всіх веб-додатків. Якщо я отримую епізодичні звіти про те, що SharePoint не відповідає, я з легкістю можу використовувати RDP для реєстрації на кожному сервері і спробувати виправити SharePoint. Якщо це спрацьовує, я знаю, що сервер працює. Якщо SharePoint не піддається корекції, я знаю точно, в якому журналі Microsoft User Location Server (ULS) мені слід шукати помилку. Мені не потрібно думати про те, в який зовнішній веб-сервер балансувальник навантаження послав мій запит. Чим швидше ви доберетеся до правильних файлів журналів, тим швидше проблема буде вирішена.
Ваш шлях індексу Search на самого себе має й іншу перевагу: це підвищує продуктивність для ваших кінцевих користувачів. Якщо ви не направите сервер Search на себе самого, то він буде виконувати пошук даних, потім дозволить DNS виконати свою роботу, а потім знову почне пошук в залежності від зовнішнього веб-сервера, який йому вказала служба DNS. Цей сервер практично і відправляє сторінки вашим кінцевим користувачам. Примушувати сервер виконувати подвійну роботу означає, що всі будуть чекати довше.
Екран 3. Файл hosts в звичайному середовищі SharePoint
На помилках вчаться
Існує багато способів завдати шкоди SharePoint. Я думаю, що не один раз робив всі ці помилки. Однак приємно, що все можна виправити. Просто дотримуйтесь інструкцій, викладених в цій статті, і ваша ферма SharePoint буде завжди у відмінному стані.
Поділіться матеріалом з колегами і друзями