2차 SSD서버 개발을 마치며,.. LSD

안녕하세요.

SSD에 관심이 많으신 여러분..........

대략 2년 정도 노력 끝에 SSD를 기반으로한 DBMS 및 VOD 서버 개발를 2차 마무리 합니다.

조금 힘이 들었던 생각이 먼저 이네요.. 주위 전문가 분들께서 부정적인 의견도 많이 들었지만,

제 나름대론 성능과 안정성에 관련하여 잘 마무리 되었다고 판단을 합니다.

 

예전 의견으로

" HDD빼고 SSD 탑제 한다고 SSD서버 되나?" 라는 글도 올렸지만, 사실 HDD빼고 SSD만 장착해도

  성능과 안정성이 보장되는 시기가 빨리 오기를 기대 합니다.

 

그리고 제가 개발을 하면서 여러 느꼈던 의견을 몇자 적어 봅니다.

아주 기술적인 부분에 표현은 어렵지만 그래도 도움이 되는 의견일 것 같아 의견을 드립니다.

 

1. SSD 부품에 대한 의견 입니다.

   SSD가 IDE를 기반으로 디자인이 되어 최초 서버에 활용 하기엔 어려움이 아주 많았습니다.

   대략 지금은 SATA interface가 주가 되어 많은 안정화가 되었지만, 사실 아직도 프로토콜 교환 부분에는

   아직도 문제가 있는 상황 입니다.

   그 이유는 HDD기반 프로토콜을 그대로 활용을 해야 하고 SSD의 특성을 각 회사마다 디자인이 되어

   표준화에 문제가 있습니다.

   삼성과 인텔이 SLC기반 SSD를 현재 서버에 활용을 하고 있으나, 대다수의 여러 서버 및 특히 레이드에

   정합성이 아직 미흡 합니다.

   이유는 위에서 언급을 하였습니다.  NAND기반 SSD는 그 나름대로의 독특한 기능 예를 들어 균등마모 기술

   및 성능 유지를 위한 각 회사마다의 여러기술 등이 내부에 숨어 있어 앞단에서 열심히 통신을 해도 뒷단에

   선 죽어라 여러 일들을 하고 있기 때문입니다.

   그러나 최근 제품들은 앞단 일과 뒷단일을 병열로 처리 하는 기술등이 많이 보완이 되었으며, PCB 보드에

   서  사전 정지 작업을 위한 계층이 늘어난 상황입니다.

   그리고 한국의 SSD controller 회사인 인디링스 의 기술적인 밸류 업이 생각보다 월등하다는 결론도 얻었습

   니다. 인텔, 삼성과 버금가는 수준의 성능과 안정성을 가지고 있는것을 확인 하였습니다.

   특정한 기능에선 인텔 삼성보다도 앞선 기능이 있었습니다. 인디링스 화이팅!!!!!!

   2011년 정도는 아무 제품이나 활용을 해도 문제가 없을 정도의 제품이 나올 것으로 기대가 됩니다.

 

2. x86 서버

   현존 제품의 내할램 아키는 그나마 SSD의 특성을 아키텍쳐에 적용한 상황 입니다.

   그러나 작년 까지는 SSD적용이 불안 하였습니다. SSD는 구조상 Channel TR로 디자인 되어 있으며,

   현재 나오는 SLC급 SSD는 명확하게 내부 외부 통신을 Channel 단위로 통신을 합니다.

   조금은 미흡 했지만, 5400Chip set 보드는  Channel 구조는 아니였지만, FW에서 Channel 처리를 하면

   대략 8channel 수준은 무난하게 처리가 되었습니다. 결과적으로 DBMS 처리에는 최적 이었습니다.

   여하튼 최근 내할램 아키가 보완이 되어 나온 보드들은 Channel TR을 구조적으로 할 수 있도록 보완이

   잘 되었습니다. 제조사 마다 다르겠지만, 2010. 02월 이후 FW가 update된 보드는 CPU와 Memory가

   완벽한 Channel 구조를 갖고 있었습니다. 이 구조는 SSD가 대중화 되는 지름길이라고 저는 생각을 합니

   다.

 

3. SSD서버 구성의 핵심 사항

    보드 자체가 channel TR 구조라는것은 TR하는 길이 여러개이면서 병렬로 처리 할수 있다는 것입니다.

    OS에 예를 들면, contextswitch 와 interrupts, forks등에 수치가 높으면, 높을 수록 안정성이나 성능에

    이슈가 됩니다. 결국은 응용프로그램들이 잘 디자인이 되어야 하는데,,,,,  그러치 못한 경우가 허다하여

    어려움이 많을 것입니다. HW적으로 그나마 해결해 주는 방법이 바로 위 언급 한 사항들을 줄려 주는 방법

    입니다. 이것을 줄리는 방법은 PIO, DMA, TEO 기술이 Channel 단위로 각각 역활을 분담하여 처리를 하

    면  broker방법으로 디자인 된 AP라 하더라도 어느 정도는 정리 할 수 있습니다.

 

    그리고 windows의 경우는  OS에서 자동으로 제공해주는 값들을 잘 받아 처리하면 큰 무리가 없습니다.

    아주 좋은 성능 발휘는 못하더라도 무난 하다고 볼 수 있습니다.

    그러나 Linux 기반은 확연히 다릅니다. OS 버전별로 성능 차이가 커서 고생이 많이 됩니다.

    지금은 OS에 관계없이 4.xx, 5.5까지 무리 없이 처리 되도록 하는것이 제일 어려운 결과 였습니다.

    SSD서버가 DISK IO는 조으나, 여러 주변 부품들과의 정합성이 더 중요한 상황입니다.

    이 정합성이 미흡하면, 전체 시스템 성능이 안정할 수 가 없는것이 어쩌면 SSD서버의 단점일수도 있습니

    다. 1) 는 당연히 레이드와의 정합성과 2) 보드와의 정합성, 특히 PCI-E 슬롯은 절대 어드레스가 있어

    상당히 신중해야 합니다.  한번 기억된 어드레스를 끝까지 물고 있기 때문에 잘 다루어야 정합성에 문제가

    없을 것입니다. 또한 가상으로 절대번지를 만들어 사용하는것도 방법입니다.

 

    그리고 음!! DBMS의 경우는 LAN port를 보드에 있는것을 대다수 활용 하지만, 4~20Gbps LAN Card를

    사용 해야 할 경우는 Data TR 부분과 network TR부분을 잘 다루어야 합니다.

    성능에 절대적인 이슈가 있습니다.

    더 이상의 의견은 어렵구요^^  아주 핵심적인 의견입니다.

    PCI type SSD의 경우 1개 성능은 우수하나, 여러개를 활용 할 경우 성능 특히 Bandwidth가 떨어지는 이유

    가 이것입니다.

 

    PCI-E 슬롯이 많이 필요로 하는 경우 이것을 잘 control 하지 못할 경우 경험해보신 분들은 아시겠지만,

    시스템이 완전 갑니다. 보드가 엉망이 되는 경우 입니다.

    PCI-E 슬롯을 많이 활용 한다고 성능이 올라가는것이 아닙니다.

    내가 어떻게 활용 하겠는지 명확하게 설정이 되어야 합니다. PCI-E BUS 구조의 Channel은 정해져 있으

    며, 그이상은 공유 합니다. 이때 부터 문제가 발생을 합니다.

    DISK도 IO  network 도 rx, tx 각기 프로토톨은 다르지만, 보드의 BUS는 정해져 있습니다.

 

    이것을 잘 활용해야만, 성능과 안정성을 답보 할수 있습니다.^^

 

    개인 의견이지만, 참조가 되었으면 합니다.

  

    줜장 이기택