'전체 글'에 해당되는 글 1243건

아... 개인적으로는 이 Jazz버전이 훨 나은듯...
나이를 먹어서인가...
들어보면 Jazz 버전 원본 노래의 가사는 그대로 사용하더군요  ㅋ

리믹스 버전 : Richard Cheese People = Shit

원곡 : SLIPKNOT People = Shit

이 자료는 SharePoint Product & Technologies Team Blog에서 보았던 자료 중 하나 입니다. 그 문서를 나름대로 멋대로 번역한 문서입니다. 이 번역 문서는 MS 공식이 아니므로 인용될 수 없습니다. 인용하시고 싶으시면, 원본 문서를 참조하시기 바랍니다. 해당 문서는 Word 문서로 되어 있으며 이 내용의 원본 백서(White Paper)는 http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409 에서 다운로드 받을 수 있습니다.

정보 아키텍처 기준 권장사항

성능 향상을 하려면, 제일 먼저 수립해야 하는 것이 바로 정보 아키텍처이다. 이 정보 아키텍처를 수립에 다음 사항들을 고려하여 수립하도록 한다.

SharePoint 제품 군 및 기술의 소프트웨어 한계 범위에 맞추어 정보 아키텍처를 수립

소프트웨어 한계 범위에 대한 더 자세한 사항은  Plan for software boundaries (http://go.microsoft.com/fwlink/?LinkID=105578&clcid=0x409)를 참고한다.

최대 관리 범위의 컨텐츠 데이터베이스의 제한 크기.

실제 적용 환경에 맞는 성능 및 관리적인 측면에 맞추어 데이터베이스 사이즈를 계획한다.

• SharePoint 제품 및 기술 팀에서 제품 성능 향상을 위해 지원을 하다 보면, 대부분 컨텐츠 데이터베이스가 100GB를 넘은 상태가 되어 튜닝 작업에 어려움을 겪는 경우가 많았다. 혹시 데이터베이스의 설계가 100G를 넘기는 형태가 될 것 같다면 가급적 다음 지침들을 따르도록 한다.
  • 데이터만 저장하기 위한 별도 사이트 콜렉션을 구성한다.
  • SharePoint에서 제공하는 백업/복원 도구를 사용하지 말고, SQL Server 또는 Microsoft System Center Data Protection Manager 에서 제공되는 백업 솔루션을 이용 한다.
  • 100GB 크기 컨텐츠 데이터베이스상에 있는 솔루션 들에 대해 이동 작업을 수행하기 전에, 반드시 SQL Server가 동작 중인 서버에서 I/O 서브 시스템을 중점 테스트한다.
• 가능하면, 100GB에 도달된 컨텐츠 데이터베이스에 있는 사이트 컬렉션에 있는 데이터들을 적절히 나누어 새로운 컨텐츠 데이터베이스에 새로운 사이트 콜렉션을 두어 옮겨야 성능 또는 관리적인 문제를 최대한 방지할 수 있다.
• 여러 개 사이트 콜렉션이 담긴 컨텐츠 데이터베이스가 약 100GB를 넘지 않도록 설계한다.

주의: 여기서 제한된 사항들은 SharePoint 제품 군에서 사용되는SQL Server에 대한 권장 사항들 이다. 일반적인 SQL Server에 대한 지침은 아니다.

버전 관리 및 휴지통에 대한 저장 장소 확보하기.

사이트 내에 버전 관리 혹은 휴지통을 사용하거나, 사용할 계획이라면, 사이트 용량제한(Quota)으로 인해 발생될 잠재적인 문제점들에 대해 미리 확인해야 한다.

• 버전 관리를 하고 있는 라이브러리(문서, 그림 등등)에서 과거 버전 데이터들이 이용한 용량 때문에, 사이트 제한 용량을 초과 할 수 있다. 이 점을 주의해서 구성하도록 한다.
• 일반적인 사이트에서는 한 단계 혹은 두 단계의 휴지통을 사용한다. 
  첫 번째 단계의 휴지통(사용자가 직접 사용하는 사이트 휴지통)에서 사이트 제한 용량(Quota)을 초과 시키는 원인이 될 수 있다. 그에 반해 두 번째 단계 휴지통(사이트 콜렉션 - 사이트 모음 - 에서 제공되는 휴지통)은 사이트 제한 용량(Quota)과는 관계없이 동작된다.
  그러나 두 번째 단계의 휴지통에 담기는 사항들은 사이트 콜렉션에서 사용하는 저장 공간에 저장되기 때문에, DB 자체 용량을 초과하는 불상사가 발생할 수 있다.  가급적이면 각 단계의 휴지통에 담긴 내용들은, 일정 주기에 자동으로 지워 지도록 설정하는 것이 좋다.

저장 공간 관리를 위한 용량 제한 템플릿 사용하기

비슷한 성격의 사이트 콜렉션들에 대해서 가급적 용량 제한 템플릿을 사용한다. 용량제한 템플릿들은 사이트 콜렉션에 저장 공간에 대한 제한을 일괄적으로 적용 할 수 있고, 용량이 부족하면 자동으로 관리자에게 이메일로 알림을 보낼 수 있다. 그러나, 템플릿이 적용/변경 되기 전에 만들어진 사이트들에서는 효과가 없다.

많은 문건을 가진 리스트 성능 관리하기.

문건이 지나치게 많은 리스트로 인해 리스트의 View 및 구조에 여러가지 문제를 일으킬 수 있다. 그 문제들에 대해 아래와 같이 대처하도록 한다.

• SharePoint 제품 군에서는 큰 사이즈의 리스트를 지원한다. 그러나, 반드시 사용자 View에서 발생되는 문제점들에 대해 적절한 문제 대응을 위한 설계가 필요하다.
• 많은 문건을 가지고 있는 리스트에서 View의 성능을 향상 시키려면, 리스트 내 한 개 또는 여러 개의 인덱스를 구성한다. 그리고 최소  한 개 이상의 인덱스 처리된 필드에  필터를 설정하도록 한다. 만일 여러 개 필드에 대해 필터를 설정하였다면, 많은 양의 문건을 필터시켜 주는 필터를 첫 번째로 하는 것이 좋다. 필터된 값들이 같아도, 전체적인 필터 성능이 향상 될 수 있기 때문이다.
• 큰 사이즈의 리스트에서 View를 만들 때, 최대 표시 수를5,000 개 보다 적은 수가 나올 수 있도록 하는 것이 좋다.
• 위에서 제시한 규칙을 적용한 View를 리스트의 기본 보기(View)로 설정한다.
• 큰 사이트의 리스트가 아니라면 리스트 단계(예를 들면, list의 root 부분 또는 단일 폴더 등) 에서 가급적 2,000개의 문건만 넣는 것이 좋다. 그래야 최소한의 성능 보장을 할 수 있다.
• 리스트 내 필드 개수가 몇 개인지를 파악하도록 한다. 너무 많은 수의 필드가 있으면 아이템 개수와는 별개로 성능 저하의 원인이 된다.

  
매우 큰 사이즈의 리스트로 설계했거나, 현재 구성되어 있다면, 다음 내용들을 참고할 것을 강력하게 권장한다.

• Manage lists and libraries with many items (http://go.microsoft.com/fwlink/?LinkID=105579&clcid=0x409)
• Working with large Lists in Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=105580&clcid=0x409)

늘 버릇대로 내 홈페이지 주소를 브라우저에 입력하고, 혹시나 있을 댓글(사실 거의 한달에 한번? 그것도 친구 한 녀석만) 있을까봐, 혹시나 방명록에 누가 있을까바 해서 들렸다.

그런데.. 왠걸...트래픽 오버 페이지가 떴다...

이게.. 무슨 일인가 싶어서, 관리 페이지에 가보니, 내 제한 용량을 거의 다 잡아먹은 녀석을 발견했다.

79.166.10.147

어느 나라 녀석인지는 모르겠지만(워낙 컴퓨터 돌려 치기들을 잘해서리...) 왜 남의 서버에 찝적 거려서 오버 시키는 걸까...

뭘 도데체 다운 받길래 그랬나.. 의문이다.

일단 웹서버 상에서 막긴 했는데, 다른 IP로 또 오버 시키면... 어떻게 할까.. 고민중이다.

이 자료는 SharePoint Product & Technologies Team Blog에서 보았던 자료 중 하나 입니다. 그 문서를 나름대로 멋대로 번역한 문서입니다. 이 번역 문서는 MS 공식이 아니므로 인용될 수 없습니다. 인용하시고 싶으시면, 원본 문서를 참조하시기 바랍니다. 해당 문서는 Word 문서로 되어 있으며 이 내용의 원본 백서(White Paper)는 http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409 에서 다운로드 받을 수 있습니다.

서두

WSS 3.0 및 MOSS 2007의 성능은 Microsoft® SQL Server®의 설정, 데이터 입/출력(I/O)을 처리하는 서브 시스템의 성능에 따라 좌우 된다.( SharePoint 제품 군 및 기술에서 SharePoint란, Windows SharePoint Services 및 Office SharePoint Server 두 제품 모두를 의미한다.). 이 문서는 SharePoint 제품 군 및 기술과 관련된 각종 데이터 저장 관련 설정 및 감시 방법 중 권장하는 사항들을 기술한 내용이다.
SharePoint 제품 군 및 기술에서 가장 중요한 부분이라고 볼 수 있는 것은 바로 잘 만들어진 인프라 스트럭처 설계와 효과적인 감시 시스템, 그리고 잘 튜닝된 제품 환경이라고 볼 수 있다.
이를 위해 SharePoint 제품 군 및 기술 팀에서는 자체적인 투자를 하여 처음부터 끝까지 - 최초 SQL 서버 용량 산정에서부터 응용 프로그램 서버, 웹 프론트 엔드 서버 용량까지 - 가장 효율적인 용량에 대해 계산할 수 있도록 도와 줄 수 있도록 근거들을 마련 하였다.
이 근거를 마련하기 위해서 응용 프로그램 서버 및 웹 프론트 엔드 서버에 까지 부하를 주면서 다양한 사례로 부하를 주고, 동시에 SQL 서버 등 각 Farm을 감시하면서 가장 좋은 사례들을 추려 낸 것이다. 웹 프론트 엔드 서버에 요청 시 전체 응답에 소요되는 시간을 세세히 파악하여 보았으며, 웹 프론트 엔드 서버에서 일반 최종 사용자들을 최대 받아 들일 수 있는 용량, 웹 프론트 엔드 상에서 쌓이는 큐의 크기 및 용량 한도를 넘을 때 발생되는 각종 이벤트들을 파악할 수 있었다.

먼저 알아야 할 것과 준비 사항

하드웨어를 구매하기 전에, 제일 먼저 현실적인 정보 아키텍처를 구성할 필요가 있다( 정보들의 전체 논리적인 구조 및 대략적인 정보 사이즈). 그리고 SharePoint 제품 군 및 기술들과 SQL Server를 동작 시키기에 필요한 각종 요구사항에 따른 성능의 변화들을 판단해야 한다. 또한 이 배포 작업에는 반드시 관련된 자원 계획을 수립할 필요가 있다.
전체적인 배포 계획에 대한 자세한 지침 사항들은 아래의 내용들을 참고하도록 한다.

•    Planning and architecture for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=105576&clcid=0x409)
•    Planning and architecture for Windows SharePoint Services 3.0 technology (http://go.microsoft.com/fwlink/?LinkID=105577&clcid=0x409)

만일 기존에 구축된 환경에서 업그레이드 하는 것이라면, WSS 3.0과 MOSS 2007로 업그레이드 되면서 더 다양해진 기능들 및 변경된 배경 기술들에 대해서 정확히 파악하고 있어야 한다. 특히 이전 버전에서 구축된 인프라 스트럭처 자원들에서 새로운 버전에서 추가적으로 요구되는 사항들에 대해 그 차이점들을 명확히 파악하고 대처할 수 있도록 준비하는 것이 중요하다.

설계에 고려되어야 할 사항

각 설계 중 주요한 사항을 나누면 아래의 3가지로 나눌 수 있다.
•    최적화된 성능
현재까지 대부분의 성능 향상의 작업은 하드웨어 외 적인 부분에서 찾을 수 있었다. 특히 자원의 병목현상과 같은 문제점 같은 경우, 대부분은 병목을 발생하는 원인을 정확히 파악할 수 있는 감시 시스템을 구축하고, 여유로운 자원 쪽으로 적절히 부하 분배를 할 수 있도록 구성하는 것이 중요하다. 대처가능 하도록 유연한 설계와 배포를 하면, 단순한 하드웨어 확장 같은 방법보다 훨씬 더 나은 결과를 가져올 수 있다.

•    규모 산정,
늘어나는 사용자 또는 사용자의 동선에 따른 변화 추이를 항상 파악할 수 있도록 한다. 이에 맞추어 별도 Farm을 재구성하지 않고도 추가적인 SQL 서버 구축, 저장 공간 추가, 및 사이트 와 SSP 추가 구축만으로 계속 확장 할 수 있도록 설계해야 한다. 또한 규모가 늘어나면서 서비스 중단 시간이 길어지는 문제에 대한 대처 방안에 대해서도 설계에 포함 시켜야 한다.

•    관리적인 측면
저장 장치에 대한 관리에 대해 설계 하도록 한다.  매일하는 관리 작업(백업을 수행하거나, SQL 서버 재 인덱싱 작업과 같은)
그리고 가끔 하는 작업(컨텐츠를 복원하거나, 원격 사이트 서비스 중단 복구 작업)으로 나누어 보다 편하게 작업 할 수 있도록 구성한다.

다른 곳에서 구한 것은 아니고, MSDN 내의 Subscription을 통해 받은 RC1 입니다.이미 Vista가 나온 상태이기 때문에, 전체적인 UI 구성이나, 배치 등은 Vista에서 보여준 형태 거의그대로여서 큰 문제점은 없더군요.

우려 했던 드라이버 문제들도, 이미 나온 Vista 드라이버로 거의 설치가 되었습니다.(최소한 제 개인 개발 PC내의 드라이버에서는 문제가 없더군요)

Vista가 가지고 있던 클라이언트의 UI가 깨끗히 걷히고, 딱 필요한 부분만 적용된 것 같습니다.그리고 2003에서 처음 제시했던 서버 Role에 대한 페이지도 더 다양하게 제시되어 있어

훨씬 접근성도 좋더군요.
게다가, 2003에서 .NET 1.1이 미리 들어가 있던 것 처럼 이번 2008에는 2.0이 미리 들어가 있었습니다. 또한 3.0도 추가 옵션을 통해 더할 수 있었으며, WPF(Windows Presentation Framewrok) 및 WWF(Windows Workflow Framework)도 있더군요.

게다가 이번에 가장 놀라게 한 것은 IIS 7.0.
일단 기능 추가 부분에서 훨씬 다양한 조건들과 옵션들의 압박도 대단했지만,
iismgr ( IIS Manager )는 정말이지 걸작이다 싶습니다.
거의 완벽하게 UI 스럽게 뜯어 고쳐서, 자주 만져주지 않으면 정말이지 딴세상 가버릴듯 하더군요.

일단, Vista 기반의 드라이버와 프로그램들이라면, 2008을 쓰는데는 무리가 없어보입니다.
이제 MOSS 2007을 설치해 보고, 무엇이 부족한지 무엇이 좋은지를 차츰 확인해 보도록 하겠습니다.

* update
  Vista나 XP에 설치하고 나면 C:\program files\Common files\WindowsLiveInstaller\MsiSources 위치에 MSI 파일들이 위치해 있군요. 그 파일들만 있으면 MSI 설정만 변경하여 설치가 가능하다고 하군요.
자세한 내용은 http://extremeperformance.blogspot.com/2007/12/windows-live-writer-xp-x64.html 를 참조하세요~

* update
 위의 버전을 설치하게 되면 사용하는데는 문제 없었지만, 문제가 있었다. 특히 플러그 인과 같은 것이 제대로 설치되지 않았다. 게다가 이 프로그램의 버전업은 새로운 버전을 받아 설치하는 것인데, 이 후버전은 설치가 안되니, 업그레이드는 안되는 것이라고 보면 될 것 같다. 게다가 묘하게 자주 깜빡 거리는게 좀 거슬린다.

Windows 2003에서는 이상하게 공식 Windows Live Writer가 설치되지 않는다.

그래서 언제나 다운로드를 받아 놓고서는 집에서는 설치도 못해보고 발을 뺐다.

그렇다고 기껏 설치한 Windows 2003을 버리고 XP를 설치하기엔 왠지 억울 했다.

(개인적으로 성능은 2003이 더 낫다고 생각됨)

그래서 Microsoft 에서 제공되는 Application Verifier 라는 도구까지 동원해서 운영체제

호환성까지 속여 보려 했는데... 실패 했다.

그러던 어느날.. 브라우징 끝에, Google에서 Windows Live Writer install to windows 2003 이라는

검색어로 찾던 도중, 포스팅 된 좋은 글을 하나 발견, 그 링크를 따라 들어가다가,

마침 Windows Live Writer 개발 팀 블로그로 보이는 곳 까지 갔다.

( 근데, 이 웹페이지는 독일에서 만들었는지 .de 로 끝난다. )

그 곳에서 MSI 파일로 된 설치 본이 있었고, 난 그것을 낼름 받아 설치했다.

WLinstaller.exe 라는 파일을 받아 설치하면 영원하게 설치할 수 없고, 최신 버전인 MSI를 받아 설치하면,
아무런 호환성 테스트 없이 즉시 설치 들어가 준다.

일단, 그 덕에 설치했고 간단하게 세팅 완료~

다양한 Blogging desktop tool 들이 있긴 하지만, 유료거나, 한글 미숙지원 뿐인데,
이건 꽤 잘 만들어진 것 같다.

저녁에 퇴근하면서 조금씩 포스팅을 해야 겠다.

지지 난주에는 거의 매일 포스팅을 했었는데, 근좌 묘하게 바쁘고, 혼잡하게 지내다 보니,

포스팅은 커녕 일조차 제대로 하지 못한 느낌이다.

조금씩 정리하듯 글쓰면서 생각의 정리라는 것을 해봐야 겠다.

MOSS 2007 기술에 대한 정리가 이제 시작된듯 싶고, 그에 관련된 수많은 글들이

포스팅 되고 있어, 읽고만 있어도 할 것이 너무 많아 보인다.

일단, 그들의 글들을 읽고 나만의 생각들을 정리해서 담아봐야 겠다.

SPUser를 등록하는 방법은 사실 간단하다.

SPWeb.SiteUsers.Add("계정ID", "이메일주소", "보여줄 이름", "기타 메모")

위의 방법으로 사용하게 되면, 사용자 목록에 등록이 된다. 그러나 이렇게 등록하는 것으로는 해당 사용자가 사이트 내에서 제대로 활용할 수 없을 뿐더러 로그인 해봐야, 액세스 거부 창이나 팍팍 뜬다.

그러면 그 즈음 되서 권한 부분을 체크해 보게 된다.

게임은 지금 부터다.
그렇다면 이 권한 등록하는 방법들이 어떻게 있을까?

하나는 MOSS 2007에서 제공되는 그룹에 추가하는 방법이 있고, 다른 하나는 한사람 자체에 따로 권한을 주는 방식이다.

1. MOSS 2007에서 제공되는 그룹에 추가하는 방법
보통 그룹은 기본적으로 "사이트이름"+" 구성원", "사이트이름" + " 관리자" 형식으로 생성되어 진다.
그래서 보통 아래와 같은 형태로 짜기도 한다.

    SPGroup group = web.Groups["Members"];
    SPUser user = web.SiteUsers["KNOIE\\neohind"];
    group.AddUser(user);

그런데 그 그룹 이름이라는게 로컬라이즈 된 이름이라서 만일 "테스트 사이트" 라는 이름의 사이트에는 "테스트 사이트 구성원" 이런 식의 이름이 그룹이름이 된다. 객관적으로 좀 너무한 이름이지 않을까 싶다. 예제와 같은 이름이라면 위의 코드가 아래처럼 되어야 할 것이다.

   SPGroup group = web.Groups["테스트 사이트 구성원"];
   SPUser user = web.SiteUsers["KNOIE\\neohind"];
   group.AddUser(user);

좀... 너무 하지 않을까? 왠지 하드 코딩하는 기분을 지울 수 없고, 만일 어디에 포팅된다면.. 왠지 대박이지 않을까?
(저 같이 유지보수나 남아서 X 치우다 보면, 우울해집니다.)

그렇다면 어떻게 하면 좋을까?
이를 위해서 SPWeb에는 아래와 같이 관련 그룹에 대한 개체를 바로 꺼내 쓸 수 있는 부분이 있다

SPWeb.AssociatedOwnderGroup // ( 관리자 )

SPWeb.AssociatedMemberGroup  // ( 구성원 )

SPWeb.AssociatedVistorGroup // ( 방문자 )

즉 위의 예를 기준으로 변경해 보면 아래와 같은 코드가 된다.

  SPGroup group = web.AssociatedMemberGroup;
  SPUser user = web.SiteUsers["KNOIE\\neohind"];
  group.AddUser(user);

그 외 그룹(디자이너, 계층 구조 관리자)들은 알아서....

여튼 저 그룹에 Users 항목에 SPUser 형태로 더해 주면 된다. 그러면 자동으로 해당 권한을 할당해 줄 수 있다.

2. 개별 계정별 개별로 권한 매기기.

여기서 부터는 조금 복잡하게 돌아간다. 아마도 SPGroup에 특정 권한 쎄우려고 할 떄 사용하곤하는데, 이 또한 개별적으로 처리할 수 있다.

SPUser user = web.SiteUsers["KNOIE\\neohind"];
// 만일 관리자, 구성원, 방문자 단위가 아닌 기능별로 Roledefinition을 만드는 방법을 별도로 더 파악해야 함.
// 범위를 넘어가므로 여기서는 Contributor 즉, 구성원으로 권한을 설정.
SPRoleDefinition defContribute = web.RoleDefinitions.GetByType(SPRoleType.Contributor);
SPRoleAssignment roleContribute = new SPRoleAssignment(user as SPPrincipal);
roleContribute.RoleDefinitionBinding.Add(defContribute);
Web.RoleAssignments.Add(roleContribute);

위의  순서대로 보면 먼저 SPRoleDefinition을 생성 한다.
그리고 난 뒤 SPRoleAssignment를 생성한다. 여기서 생성할 때는 권한을 설정하려는 대상(보통 SPUser나 SPGroup)을 넣는다.
그리고 SPRoleAssgignment 내에 RoleDefinitionBinding에 앞서 만든 SPRoleDefinition을 추가한다.
맨 마지막으로 만들어진 SPRoleAssignment를 실제 권한을 설정하려는 Web, List, ListItem에 추가한다.