2008년 10월 29일 수요일

MS SQL Server 2005 interoperation problem with Linux client


MS SQL Server 2005와 Linux client (WAS로  Tomcat 실행) 연결 문제 때문에 몇 시간을 허비했는데, 간신히 해결했습니다.  시스템 환경 정보는 다음과 같습니다.
  1. DBMS Server:
    1. MS SQL Server 2005 Ent. with SP2 (x64)  on Windows Server 2003 std. with SP2 (x64)
    2. Hardware: Smart Start HP DL 580G5
  2. DBMS Client:  (Linux)
    1. Tomcat 6.0.18 on Cent OS Linux 5.1 (x64)
    2. Kernel: 배포본에 포함된 버전을 그대로 사용 (2.6.18-53.el5 #1 SMP)
    3. Microsoft SQL Server 2005 JDBC Driver 1.2 (Unix version)
    4. Hardware: HP DL360G5
  3. DBMS Client: (Windows)
    1. Windows Server 2003 std. with SP2 (x64)
    2. Hardware: HP DL360G5

증상은 아주 재미있습니다.
  1. 1. Tomcat 을 startup  --> SQL Connection 테스트 웹 페이지를 호출합니다.  여기까지 잘 됩니다.
  2. 다른 사용자는 접속하지 못합니다. (테스트 사이트이므로)
  3. 1분 정도 기다렸다가 다시 테스트 웹 페이지를 호출합니다.  -> 동작하지 않습니다
  4. SQL Server Mgmt. Studio에서 SP_WHO2 sp를 이용해서 체크하면, Linux client 에서 Connection이 사라진 것을 확인할 수 있습니다.  why? (Tomcat은 아무런 문제없이 실행 중인데.....)
  5. 다른 Windows client 에서 접속하는 Connection은 이상없이 잘 유지되고 있습니다.
  6. 이제 Tomcat (WAS)의 Connection Pool , JDBC 설정의 문제인가 싶어서 열심히 googling 합니다..
  7. ......  Google, Google, Google, Google, Google, Google ......
  8. ........문제는  여전히 해결되지 않고 너무 졸리고 피곤합니다 :-(
  9. 지쳐서 다른 Windows Machine에다가 JDK/Tomcat을 올려서 테스트. 
  10. 같은 소스인데, 잘 동작합니다!!!!!!
  11. 개발자는 Linux O/S 문제니까 어서 Windows로 재설치해서 해결하자고 무언의 압박을 줍니다. (Platform에 독립적인 Java의 강점을 살려서...)
  12. 이제 당신은 .... ?????

이제 왜 Windows Client만 잘 되는지 의심이 생깁니다.  SQL Server 2005 에서 Orphaned Connection을 정리하는 KeepAlive 기능에 대해 설명한 내용이 눈에 들어옵니다.
  1. KeepAlive의 기본값은 30초 (30,000 miliseconds)
  2. 체크 간격은  1초 (KeepAliveInterval)
  3. 최대 5번(TcpMaxDataRetransmissions) 정도 체크
  4. 정리하면 대략 35초에 1회씩 idle 상태의 SQL Connection 점검합니다.  일반적인 Windows Client 라면  acknowledge 응답을 통해서 연결이 계속 유지됩니다. (예: Game 서버)
  5. SQL Server 에서 Keep Alive 값을 변경해 봅니다.... 끊어지던 간격이 달라지는 것을 확인할 수 있습니다.
  6. 일단 KeepAlive가 영향을 주는 부분 같습니다. 그런데, 이걸 장시간 (예: 3600초 = 1시간) 설정하는 것은 역시 꽁수(workaround)입니다. 우아하지 않습니다 ~~
  7. 시스템의 TCP/IP 레지스트리 항목을 보면서,  Linux와 Windows 시스템 간의 궁합에 대해 사뭇 비판적으로 접근하게 됩니다........


해결책
  • 크게 고민하지 않고, 바로 테스트를 했습니다. 
  • Win2k3 SP2부터 추가된 SNP 기능 (RSS, TCP Offload)를 비활성화시켰습니다.
  • 문제가 해결되고, 정상 동작함을 확인했습니다.   그래서, SQL Server의 Keep Alive 설정은 Default 유지.
  • DBA도 행복하고, OS를 재설치하지 않게 된 SA도 행복해졌습니다.

결론

  • SQL 2005의 Keep Alive 기능은 Windows Client에 대해서만 훌륭하게 작동하는 것 같다.
  • Windows Server 2003 서버와 Linux 서버의 Tcp/IP Socket 문제가 생길 때,  꼭 SNP/RSS/TCP Offload  관련 레지스트리를 비활성화 해보자.
  • Platrom이 짬뽕인 환경은 아무튼 좀 짜증난다. 가급적 일관성 있게 유지하자.

관련자료
  1. SQL Protocols: Understand special TCP-IP property “Keep Alive” in SQL Server 2005
    http://blogs.msdn.com/sql_protocols/archive/2006/03/09/546852.aspx
  2. Windows 2003 SP2 설치후 네트워크가 되지 않는 문제
    http://blogs.technet.com/sankim/archive/2007/05/30/windows-2003-sp2.aspx

2008년 10월 24일 금요일

[Security Update] Microsoft Security Bulletin MS08-067 – Critical

MS의 공식적인 패치 발표 일정과 무관하게 긴급 공지된 보안 업데이트입니다.  그만큼 중요하다고 판단되므로 즉시 업데이트할 것을 권장합니다.

 

Microsoft Security Bulletin MS08-067 – Critical

Vulnerability in Server Service Could Allow Remote Code Execution (958644)

아래는 [마이크로소프트 보안공지] 메일의 내용입니다.

 

제목: 서버 서비스의 취약점으로 인한 원격 코드 실행 문제점 (958644)

최대 심각도:

Windows 2000, Windows XP, Windows Server 2003: 긴급

Windows Vista, Windows Server 2008: 중요

취약점으로 인한 영향: 원격 코드 실행

탐지: Microsoft Baseline Security Analyzer로 컴퓨터에 이 업데이트가 필요한지 점검할 수 있습니다.

영향을 받는 소프트웨어: Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 (아래 링크에서 영향을 받는 소프트웨어와 다운로드 위치를 확인하십시오)

시스템 재시작: 보안 업데이트 적용 후 시스템을 재시작해야 합니다.

 

 

특히 Windows Server 2000/2003 과 같이 Firewall 이 기본적으로 활성화되지 않는 서버들에 대해서는 긴급히 패치하는 것이 바람직합니다.