IT Professional 썸네일형 리스트형 기가 막힌 Active Directory 의 계정 관리, Unix 에도 적용할 수 없을까?(2) 지난 번 글에 AD 의 유용성과 이 기능을 Linux 나 Unix 에 쓸 수 없을까... 하는 생각을 해 봤다. (지난 글 http://masterjoe.tistory.com/entry/기가-막힌-Active-Directory-의-계정-관리-Unix-에도-적용할-수-없을까) 소규모 환경에서는 오픈 소스 기반의 SAMBA 를 사용해도 무리가 없다. 아니 소규모 환경 (약 10 대 이하의 관리 대상 서버 환경) 에서는 구태여 무리해서 Linux 를 AD 에 조인할 필요도 없다. 하지만, Linux 의 서버 대수가 (가상이건 물리건) 급격하게 증가하면서 발생하는 문제.... 관리 불가능한 수준의 로컬 계정과 Root 패스워드 관리와 싸워야 한다.... 자... AD 의 계정과 통합하기 위해서는 몇가지 사전 조.. 더보기 기가 막힌 Active Directory 의 계정 관리, Unix 에도 적용할 수 없을까? 요즘의 IT 의 화두는 단연 보안이다. 이전에도 예산이 없어도 우선적으로 수행하는 것이 보안 관련 업무라는 것은 누구라도 다 아는 사실이다. 자.. 보안에 더해서... 요즘 갑자기 Microsoft 의 라이센스 이슈가 기승이다. 그 아래 깔린 이야기는 별로 상관하지 않기로 하고.. 하여간에 돈을 낼 능력이 있는 고객사를 대상으로 뭔지도 모를 알송달송한 SPLA 같은 라이센스를 들이 밀지 않나, 기존에 멀쩡하게 사용하던 DBMS 의 가격을 10배를 올리지를 않나... 솔직히 MS 제품을 사용한다는 것은 싼맛에 사용하는 것이 대부분인데... MS 가 요구하는 대부분의 가격은 Unix 로 구축하는 것보다는 약간 싸고, 기존의 사용 라이센스를 사용하는 것보다는 훨씬 비싼... 그래서 Unix 로 가기에도 힘든 .. 더보기 MS SQL 서버의 Transaction 로그 관리 대용량 DBMS 를 사용하는 경우, 일부 사용자들은 Log 수준을 Simple 로 정의하므로서 I/O 성능적인 향상이 있을 것이라는 추측을 하게되고 실제로 그렇게 하는 경우가 있다. 다른 제품들과는 다르게 SQL Server, RDBMS 의 로그는 단순한 로그가 아니라 Data 의 일부로 취급 받는다. 시스템의 상태 정도를 나타내는 로그의 수준이 아니라, 비정상적인 방법으로 Transcation-log 를 읽거나 줄이는 경우 정상적인 시작이 되지 않는 것도 이 때문이다. 대용량 DBMS 를 사용하는 경우, 일부 사용자들은 Log 수준을 Simple 로 정의하므로서 I/O 성능적인 향상이 있을 것이라는 추측을 하게되고 실제로 그렇게 하는 경우가 있다. 하지만 이는 잘못된 생각이다. Full 모드의 경우 알.. 더보기 멀쩡하게 돌아가던 SQL 이 갑자기 Lock 이 발생하며 멈춘다면...(1) Ghost Cleanup 주구 장창 높은 시스템 점유율을 나타내면서 시스템의 속도를 떨어뜨리는 문제를 해결하는 것도 문제지만... 한번씩 그것도 주기적으로 시스템을 무응답 상태로 빠뜨리는 상황이 종종 있다. 이 경우에 Batch 형태로 돌아가는 작업을 잡아 내게 되면 정말 Happy 하지만, 유감스럽게도 대부분의 경우 Batch 가 없는 경우가 많다. (실제로 Batch 가 있다면 벌써 개발자 수준에서 처리를 하는 경우가 대부분이다.) 각각의 Case 가 있지만.. 일단 첫번째 Case Ghost Clean up 에 대하여 알아 보자. Ghost Cleanup 갑자기 Lock 이 발생하면서 단 몇 ms 면 끝날 Select 문이 짧게는 1분 길에는 수십분에 걸쳐서 실행되는 경우가 있다. 물론 중요 서비스라는 난리가 아닐 것이고... 더보기 기업 환경에서의 Mac 클라이언트의 관리 아이폰이 인기를 끌면서 덩달아 Mac 의 인기도 증가했다. Windows PC 에 비해 월등한 기능을 가지지 못햇지만, 사용자들 중의 Mac PC 를 선호하는 사용자들이 증가하고 있고, 업무 환경에서 Mac 의 사용도 증가하고 있다. 문제는 국내 대부분의 IT 환경이 Windows 제품군 기준으로 증가했고, 대부분의 관리 체제가 Windows 기반으로 구성된 것이 현실이다. 문제는 Mac 역시 Windows 못지 않은 강력한 컴퓨팅 파워와 파일 전송 기능을 가진다는 것인데, 보안을 중시하면 현재의 기업 환경에서 물리적인 제어 이외에는 Mac PC 에 대한 제어 방안이 없다는 것이 문제다. Active Directory - Windows 클라이언트 제어를 위한 저변이 넓은 효과적인 대안 인정하건 인정하지 .. 더보기 MS SQL 병목 탐지 시스템 인프라 담당자에게는 미안한 말이지만, 시스템 파라메터 열심히 튜닝하는 것보다, 쿼리 한줄, DB 옵션 하나 수정하는게 훨씬 성능이 잘 나온다는 이야기 들이 있다. 맞는 말이다. (나도 시스템 엔지니어지만, 맞는 건 맞는 거니까...) 그런데 솔직히 SQL 을 제대로 튜닝하는 DBA 를 만나기가 쉽지 않다. 튜닝은 고사하고 SQL 에 뭐거 문제인지 진단하는 방법론을 가지는 엔지니를 만나는 것도 꽤 어려운 일이다. 그렇다면, MS SQL 을 다루는 사람들은 왜 이렇게 튜닝을 힘들어 할까? 물론 오라클 만큼이나 시장이 성숙하지 않은 것은 사실이지만, 적지 않은 기간 동안 운영되어 온 SQL 은 왜 이렇게 튜닝 파워가 낮을까? 그 이유는 아마도 툴의 부재라고 보인다. (이건 아마도 가장 큰 책임은 MS .. 더보기 MSCS 의 Heartbeat 단절로 인한 서비스 영향도 최소화 설정 서로의 상태를 체크하는 것이 무엇보다도 중요하다. 운영 중인 서버의 HW 또는 SW 적인 장애로 인한 서비스의 중단을 최소화하기 위하여 적용되는 가장 일반적인 기술이 이중화다. Microsoft 에서 제공하는 이중화 기술은 MSCS (Microsoft Cluster Service) 로서 제조사의 기술로서 압도적으로 안정적인 기술을 보인다. 이 기술은 알다 시피 SQL, 파일 서버 등에 적용되고 Exchange 는 2010 부터 DAG 이라는 기술을 적용하면서 MSCS 를 졸업했다. (실제로 익스체인지는 HW 적인 가용성 문제보다는 SW 적인 파일 시스템의 손상으로 인한 시스템의 장애가 발생하는 경우가 더 많았기에, MSCS 의 기술이 그다지 많은 도움이 되지 않는 경우가 많았다.) MSCS 는 기본적으로.. 더보기 추가 기능 "Redemption Helper Outlook Extension"(C:\Program Files\ToDo Sync Helper\Redemption.dll) 관련 오류 발생시 아웃룩의 중요성은 점점 중요해 지고 있다. 그런데 문제는 중요한 아웃룩 인 만큼 줄줄이 문제를 일으키는 원인이 될 수 도 있다는 것... 뭔가 일을 하다 보면 아래와 같은 메시지를 보는 경우가 있다. "Redemption Helper Outlook Extension"(C:\Program Files\xxxxxxx\Redemption.dll)을(를) 로드할 수 없거나 Outlook에서 사용할 수 없습니다. 추가 기능 "Redemption Helper Outlook Extension"(C:\Program Files\xxxxxxx\Redemption.dll)을(를) 로드할 수 없거나 Outlook에서 사용할 수 없습니다. 업데이트에 대한 자세한 내용은 추가 기능 제조업체에 문의하십시오. 업데이트가 없는 경우 추.. 더보기 Microsoft SQL Server CPU 경합 방지 옵션 SQL 서버를 운영하다 보면 개발 머신이 아닌 경우, 대부분의 서버에서 멀티 CPU 시스템을 사용하게 된다. 당연히 CPU 가 많은 경우가 CPU 가 적은 경우보다 빠르겠지만, 그렇지 않은 경우가 몇가지 있는데, 병렬 처리로 인한 Deadlock 발생, 그리고 동일한 자원의 사용을 위한 경합에 의한 장애가 발생하는 경우이다. 먼저 CPU 의 병렬 처리로 인한 Deadlock 은 아래를 참고... http://masterjoe.tistory.com/entry/Deadlock-의-진단과-해결 CPU Core 의 개수에 준하게 TempDB 의 파일을 만든다. 그리고 일반적으로 해야 하는 설정이지만, 빼먹는 설정이 바로.... Temp DB 의 설정이다. 일단 설정의 방법 부터 알아 보자. 1. 각 서버의 CP.. 더보기 SQL 서버 사용 중 Query 나 DML 이 인덱스 사용을 비 정상적으로 할 때... SQL 스키마 구조에서 가장 중요한 것이 무어냐고 묻는다면, 단연 인덱스의 효율성이라 이야기 할 수 있다. 아무리 많은 Data 가 증가할 지라도, 인덱스를 효율적으로 사용하는 쿼리는 이론상 속도의 저하가 발생하지 않는다. RDBMS 상에서 Data 가 늘어 가는 것은 오히려 당연한 이치이고, 아무리 많은 Data 가 증가할 지라도, 인덱스를 효율적으로 사용하는 쿼리는 이론상 속도의 저하가 발생하지 않는다. (백업이나 Data 관리의 부하가 증가하는 것은 다른 문제로 하자.) 그런데, 정말 잘 만든 인덱스를 타지 않는 쿼리가 있다면... 성능에 심각한 문제를 발생하게 될 것이다. 문제는 두가지다. 우리가 잘못했거나... MS 의 최적화기가 잘못 동작하거나.... 대부분의 경우 최적화기가 오동작을 하는 것.. 더보기 이전 1 2 3 4 5 6 다음
