안녕Ȣ16;세요. 
/112;1060;드컨트롤러 사양 1069;lj16; 0169;법1012; 여쭤보/140;고 합니다.
현1116; /112;1060;드카드 1228;품1012; 비교 고/140;Ȣ16;lj16; 과1221;1077;니다.
비교Ȣ16;lj16; 모델1008; DELL PERC H330카드 , DELL PERC H730카드1077;니다. (사실 1228;품명1008; 1473;요한,163;1060; 아닙니다.)
홈6168;1060;1648;에서 찾아본 간략한 스6169;1008; 맨 아래와 같습니다.
현1116; 카드1088;체1032; 가ᅄ1;차1060;도 1080;1648;만 호환.104;lj16; /113;서버가 달라서 신1473;7176; 따1256;봐야Ȣ16;lj16; 상황1077;니다.
1228;가 볼수1080;lj16; 스6169;상황1008; 버6140;크기lj16; 3301060; 1339;고, 최대1109;치수량1008; 7301060; 1339;습니다.
홈6168;1060;1648; 상1032; 광고문구도 신ᅆ1;1060; Ǹ16;1077;니다. 
PowerEdge RAID Controller H330 
? Eight internal ports 
? Ideal for file, web, database and email servers 
? Trusted Dell PERC reliability with minimal maintenance effort
PowerEdge RAID Controller H730 
? Eight internal ports 
? 72-bit DDR3 interface drives 1GB non-volatile cache memory 
? Unsurpassed performance and enterprise-class reliability
1228;가 구1077;해서 사용Ȣ16;/140;고 Ȣ16;lj16; 목1201;1008; HPC계산클러스터+lustre파1068;시스템1004;/196; 구축Ȣ16;/140;고 합니다.
web, email 서버/196; 사용Ȣ16;lj16; ,163;1060; 아니고 대용량1032; 파1068;1012; 여러 노드에서 한꺼번에 Ǹ16;lj16; 1068;1060; 많아서,
IO에 병목1012; 피Ȣ16;기 위해서 lustre파1068;시스템1012; 설치Ȣ16;lj16;데 (실1228;/196; NAS서버에서 그런 ᅆ1;험1012; Ȣ16;였습니다.)
그에 상1025;Ȣ16;1648;않lj16; RAID컨트롤러ǐ12;문에 0156;목1105;7176;lj16; 1068;1060; 1080;1648;lj16; 않1012;까 Ȣ16;lj16;,172; 고0124;1032; 내용1077;니다.
1228;가 생각Ȣ16;lj16; 1228;가 사용Ȣ16;lj16; 시스템1008; 대역폭보다lj16; 파1068;개수에 더 큰 병목1012; 0155;습니다.
현1116;와 같1008; 상황에서 /112;1060;드카드 고/140;시 스6169; 1473; Ǻ12;떤 ǥ12;ǥ16;1012; 1473;1216;1080;,172; 봐야Ȣ16;lj16;1648; 1312;Ǻ16; ǥ12;ᓠ1;드립니다.
ᕬ1;시몰라 링크를 첨ǥ12;합니다. 
330 http://accessories.ap.dell.com/sna/productdetail.aspx?c=kr&l=ko&s=dhs&cs=krdhs1&sku=405-aahw
730 http://accessories.ap.dell.com/sna/productdetail.aspx?c=kr&l=ko&s=dhs&cs=krdhs1&sku=405-aahu
 330
| ||||||||||||||||||||||||||||||||||
 730
| ||||||||||||||||||||||||||||||||||
http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell-PowerEdge-RAID-Controller-H330.pdf
캐쉬없고 Raid 0, 1, 5 지원
12Gb/s SAS HBA
H730은 SAS3108 기반의 신형 Raid 카드고요 (Nvcache도 2Gb)
하드웨어 Raid 카드를 원하시면 H730으로 가셔야 하며
Lustre파일시스템을 설치할 정도의 IO에 병목을 경험한적이 없어 정확한 설명은 힘들지만
H730 RAID Card 라면 컨트롤러 때문에 발목잡히는 일은 없을꺼 같습니다.
그렇다면 왠만한 raid controller 다 좋을겁니다.
MDS는 작은 파일들이 많기때문에 cache가 크면 좋아보이지만 lustre는 file system 수준의 mds HA를 지원하지 않기때문에 무척 조심해야 합니다. 설마 drbd를 사용하는건 아니겠죠???
MDS 서버만이라도 LSI-Sync controller를 사용하시는것을 검토해 보셔도 좋을겁니다.
저도 배워갑니다 ^^;
좋은 RAID컨트롤러를 사용해야할 순위가 MDS > OSS > Mater = Compute 가 맞습니까?
업체에 문의하기 전에 저도 좀 알아야 할 것 같아서 문의드립니다.
견적문의하여 받은 업체마다 lustre구성이 조금씩 달라 뭘 알아보려고 하더라도
현재 배경지식이 부족한 상태에서 체감하는 진입장벽이 높습니다.(업체를 아직 정하지못한 상황에서 자세히 묻기도 힘듬)
제가 이해한 바를 봐주셨으면 합니다.
MDS : 메타데이터서버 - 파일의 객체정보를 저장하는 서버.
OSS : 오브젝트스토리지서버 - 보통의 스토리지이지만 IO를 관장하는 CPU가 필요함.
MDT : 메타데이터타겟 - 마스터노드.
OST : 오브젝트스토리지타겟 - 컴퓨팅노드.
BMT 1달씩 퍼지게 걸어서 에러가나지 말고 풀퍼포먼스가 나아합니다만
그것을 수치화해서 이야기 해줄수 있는 사람은 국내 몇사람 안됩니다.
개인적으로 국내 1호 Lustre Certified Engineer (2006년인가...) 입니다. Lustre는 모르시면 정말 사용하면 않됩니다. 믿고 NFS로 가심이...
현재 처해진 상황은 NFS로 변경할 수 없는 상황입니다.
정확히 제가 사용해본 것은 NAS로 구성되어있는 RAID6스토리지를 16개 계산노드가 IO작업을 하는 클러스터입니다.
제가 Lustre를 고려하는 이유는 이전에 HPC구성에서 NAS로 구성해본 결과 큰 병목이 일어났습니다.
제가 본것은 IO파일개수가 늘어남에 따라 JFS파일시스템의 경우 굉장히 느려지는 병목이 발생합니다.
(참조 : https://mindplusplus.files.wordpress.com/2011/02/stepwise-threads1.png )
그때 Lustre를 이용하면 여러 파일을 IO하더라도 느려지는 현상이 발생하지 않는다고 판단하여 구성을 하려고합니다.
그러한 현상만 일어나지않는다면 NFS,NAS,Lustre등 세세한 속도차이는 중요하지않습니다.
스스로 구성하는 것은 아니기때문에 구성상의 어려움은 차치하고,
사용할때도 Lustre에 대해서 모르면 사용하기 어려운 부분이 생기는 것이면,
배워서라도 해야하는 상황입니다. (계약하는 회사의 담당엔지니어분과 2cpu와 구글의 힘으로)
결론적으로 Raid컨트롤러의 중요도는 MDS, OSS에 있다는 점을 알게되어 감사드립니다.
박문형님 말대로 구성이 끝난다음에 알 수 있는 총체적인 상황이고,
해당 병목현상이 실제 일어날지 어떨지 여부도 모르는 상황에서 안개속을 더듬적거리면서 걸어가는 심정이지만
답변 감사드립니다.
IO가 길기때문에 일어날 수도 있고 RPC request가 너무 자주와서 일어날 수도 있습니다.
OSD의 수량을 늘려서 해결이 되는 경우는 IO가 길기 때문에 발생하는 병목을 해결하는거구요 RPC request가 많아서 발생하는 이유는 OSD를 늘려서 해결되지 않습니다.
소위 작은 IO가 많아서 발생하는 경우가 해결하기 어려운 경우인데 이때는 Lustre도 별 다른 방법이 없습니다.
흔히 말하는 MDS에 병목이 있어서 발생하는 문제인데 Lustre는 EXT4와 99.9999% 동일한 File System을 MDS용 파일시스템으로 사용합니다. 다시말하면 NFS를 EXT4로 설정한 시스템에서 해결하지 못하는 IO는 Lustre도 해결하지 못합니다.
LUSTRE를 아는 사람이 사용해야한다는 말은 구성을 할 줄 아느냐가 아닙니다.
예를들어서 시작으로는 Lustre를 Client까지 kernel build 및 module을 사용하는데 여러대의 서버중에 1대가 IO중에 멈추거나 하면 전체 시스템이 hang이 걸릴수 있습니다. 이렇게 되면 어떻해야하는지 난감해 지지요.
오래전에 저희 고객중에서 lustre를 사용하다가 새벽에 kernel upgrade를 했습니다. 리부팅을 하니까 당연히 부팅이 실패하겠죠. 그때 고객이 300대 정도 서버를 운영했었는데 300대 서버가 모두 멈추니까 많이 당황했겠죠.
다른이유는 Lustre를 storage입니다. MDS/OSD에 조금이라도 문제가 발생하면 전체 file을 손실할 수 있습니다. 복구도 불가능합니다. 아주 자주있는 일입니다. 몇년전에 뭐 대학 물리학과 대학원에서 lustre 데이터가 날아가면서 3년치 실험결과를 모두 날린적이 있습니다. 박사과정 대학원생 2명은 학교를 1년 더 다녔습니다.
2CPU+판매하는 회사의 엔지니어+google을 믿고 해도 결국은 님께서 해결해야 합니다. 특히 판매하는 회사의 엔지니어가 할 수 있는일은 설치/검수 까지일꺼고 향후 장애해결은 아마도 어려울 겁니다. (개인적인 생각)
방금 생각이 났는데 더 좋은 방법은 Xyratex나 DDN 등에서 판매하는 Lustre Appliance를 사용하는 겁니다. 누군가가 책임지고 문제 해결에 나설수 있는것만으로도 안심이죠.
저는 여기까지.