none
Sharepoint server 2013.Несколько порталов RRS feed

  • Вопрос

  • Добрый день! Возник вопрос. Мне надо сделать два портала на Sharepoint 2013.  Один как интранет в компании, второй для филиалов. Сервера буду все виртуализировать. Как лучше разнести эти порталы для улучшения производительности? Хотелось бы, чтобы базы данных были разные.
    19 марта 2015 г. 5:54

Ответы

  • Добрый день,

    при таком количестве сотрудников не стоит думать о производительности, все должно работать отлично.

    Если у вас все будет в интранет, то делайте один сервер, максимум что может понадобиться - разнести по разным коллекциям сайтов (по количеству филиалов). Если требуется еще более разграничить по доступу, то сделаете другой web-application. Но если все они должны будут подавать заявки в единое место, то это должна быть одна коллекция сайтов с единым окном заявок.

    Продумайте сначала потребности и оптимизируйте бизнес-процесс, после чего вы поймете логическую структуру того, что вам действительно потребуется.

    Посмотрите топологии фермы. Пока что не убедили зачем вам нужен второй сервер.

    19 марта 2015 г. 8:17
  • Согласен с Максимом, при таком количестве сотрудников (менее 1000), разносить по серверам не имеет смысла, если есть желание можно разнести на разные веб приложения.

    что касается баз, то они могут быть разные у двух семейств сайтов в одном веб-приложении.

    выбор за вами.

    если нужно разные адреса и что бы сайты были в корне (http//portal1 и http://portal2), то можно по разным веб приложениям, если не принципиально (http//portal/sites/filial), то можно в одном.

    еще, судя по описания чувствую, что ЦО участвует в процессах на обоих порталах, предлагаю подумать над дальнейшим развитием процессов, т.к. увязать два семейства в один РП штатными средствами проблематично, возможно будет иметь смысл разнести по сайтам в одном семействе что бы пул задач у ЦО был один.

    в общем нужно все сесть и обдумать.

    19 марта 2015 г. 8:28
    Модератор

Все ответы

  • Добрый день,

    Если у вас интранет - ваш портал, то второй сервер где будет располагаться - в интра или экстра сети? Принятие решения зависит от топологии вашей сети - выносить второй сервер в DMZ или нет.

    Если вынос в DMZ не предполагается, то зачем их вообще разносить ? Делать одним сервером и все.

    Производительность: сколько человек всего будет работать и каков характер работы?

    19 марта 2015 г. 6:07
  • Все будет в интранете. Пользователей ЦО от 200 человек. Это задачи, документы.  Второй портал - это система заявок для доп.офисов. В этих заявках будут вставлять сканы документов, для сотрудников в ЦО. Сотрудники ЦО должны подтверждать или отклонять эти заявки. Вынос в DMZ не предполгаетсяя.
    19 марта 2015 г. 7:20
  • Добрый день,

    при таком количестве сотрудников не стоит думать о производительности, все должно работать отлично.

    Если у вас все будет в интранет, то делайте один сервер, максимум что может понадобиться - разнести по разным коллекциям сайтов (по количеству филиалов). Если требуется еще более разграничить по доступу, то сделаете другой web-application. Но если все они должны будут подавать заявки в единое место, то это должна быть одна коллекция сайтов с единым окном заявок.

    Продумайте сначала потребности и оптимизируйте бизнес-процесс, после чего вы поймете логическую структуру того, что вам действительно потребуется.

    Посмотрите топологии фермы. Пока что не убедили зачем вам нужен второй сервер.

    19 марта 2015 г. 8:17
  • Согласен с Максимом, при таком количестве сотрудников (менее 1000), разносить по серверам не имеет смысла, если есть желание можно разнести на разные веб приложения.

    что касается баз, то они могут быть разные у двух семейств сайтов в одном веб-приложении.

    выбор за вами.

    если нужно разные адреса и что бы сайты были в корне (http//portal1 и http://portal2), то можно по разным веб приложениям, если не принципиально (http//portal/sites/filial), то можно в одном.

    еще, судя по описания чувствую, что ЦО участвует в процессах на обоих порталах, предлагаю подумать над дальнейшим развитием процессов, т.к. увязать два семейства в один РП штатными средствами проблематично, возможно будет иметь смысл разнести по сайтам в одном семействе что бы пул задач у ЦО был один.

    в общем нужно все сесть и обдумать.

    19 марта 2015 г. 8:28
    Модератор
  • Сейчас вы меня убедили, что он не нужен:) Да и сам почитал.  А сканы, которые будут прикрепляться к заявке, они где будут храниться? В базе или в каталоге на диске?
    19 марта 2015 г. 8:30
  •  А сканы, которые будут прикрепляться к заявке, они где будут храниться? В базе или в каталоге на диске?
    по умолчанию в SQL 
    19 марта 2015 г. 8:31
    Модератор
  • Все в SharePoint хранится в SQL базе.
    19 марта 2015 г. 8:35
  • Все в SharePoint хранится в SQL базе.

    Если не настраивать RBS

    Обзор удаленного хранилища больших двоичных объектов в SharePoint 2013

    19 марта 2015 г. 8:37
    Модератор
  • C RBS они физически хранятся на HDD, а логически там без SQL не разобраться :)
    19 марта 2015 г. 8:39
  • логически там без SQL не разобраться :)
    согласен :)
    19 марта 2015 г. 8:40
    Модератор
  • Да вы все правильно поняли. Сейчас сидели обсуждали с руководителями как мы будем делать. Решение одно. Остановились на варианте с одним семейством. И двумя сайтами внутри этого семейства. Сейчас вопрос обстоит в том, как сделать так, чтобы документы хранились не в базе, а в файлово. Т.к. база слишком сильно разрастется от кол-ва поступаемых документов.
    19 марта 2015 г. 13:21
  • Добрый день, А какой у вас прогноз объема? SQL держит террабайты нормально с настроенным RBS, на скорости работы не сильно отразится. Можно конечно разместить документы в файловом хранилище и настроить поиск по этим документам, но тогда теряется весь смысл хранения информации в SharePoint. Вам нужно хранилище файлов(документов) или документооборот, или совместная работа с документами? Опишите ваши потребности-задачу подробнее, тогда вам предложат целесообразное решение.
    19 марта 2015 г. 13:37
  • У нас примерно 15 Доп. офисов, в каждом офисе в день делает от 5 до 20 заявок. В каждой примерно по 2-5 сканов документов. Это все передается в ЦО, тут заявка согласовывается и соответственно в ДО выдят результат, согласовано или нет. ШЕф говорит, что в старом портале на 2007м Sharepoint такая задача загрузила базу и работало медленно. Надо разобраться с RBS, думаю это будет как раз то что нужно.

    Плюс у нас еще планируется сделать что-то на подобии хелп деска для нашего департамента. Плюс  задачи по планированию и контролю внутренних задач ИТ отдела. 


    • Изменено AndreySV 20 марта 2015 г. 5:33
    20 марта 2015 г. 5:19
  • на скорость работы влияет не только размер базы но и количество элементов, персональные права, количество полей подстановки в списке и т.д.

    предлагаю предварительно ознакомится: Управление списками и библиотеками со множеством элементов

    20 марта 2015 г. 6:03
    Модератор
  • Описанная вами загрузка очень маленькая. SQL сервер делать на железе (не виртуализировать) и все летать будет. RBS для хранения сканов (конечно если это не полно цветные сканы в миллион DPI) не критично.

    20 марта 2015 г. 6:11
  • К сожалению на железном сервере поставить не получится, по крайней мере в ближайшие пол года, поэтому приходится виртуализировать. Собственно поэтому и думаю как лучше поступить.
    20 марта 2015 г. 6:33
  • SQL на виртуальной машине - вот ваше критическое место.
    20 марта 2015 г. 6:44
  • Оно понятно. Но от этого пока никуда не деться. Сейчас никто не купит хороший сервер под SQL
    20 марта 2015 г. 6:56