https://qumulo.wistia.com/medias/edmfzyg9rq
비디오 녹음
제 이름은 닉 래크입니다. 저는 에서 정보 기술 부국장입니다. 과학 컴퓨팅 및 이미징, 유타 대학의 연구 기관입니다. SCI 연구소에 대해 조금 말씀드리자면, 저희는 유타 대학교의 일부인 200개의 영구 연구 기관 중 하나입니다. 우리는 20명 이상의 학생, 직원 및 교수진이 있습니다. 우리는 주로 학교 컴퓨팅, 생명 공학과, 수학, 전기 및 컴퓨터 공학과에서 선발된 XNUMX명의 정년 트랙 교수진을 보유하고 있으며 거의 모든 교수진은 다른 부서에도 임명되어 있습니다. 따라서 우리는 매우 다양한 분야를 아우르는 그룹입니다. 우리는 모든 일을 많이 합니다. 따라서 명성에 대한 우리의 주장 중 하나는 과학 컴퓨팅의 오픈 소스 패키지, 그리고 그 중 선두는 "사이런,”라고 하는 문제 해결 환경입니다. "Seg3D, ImageVis3D, ShapeWorks, ViSUS, map3d"라는 패키지도 수행합니다. 이 모든 것이 오픈 소스입니다. 확인하고 싶다면 SCI 웹사이트에서 모두 볼 수 있습니다. 제 말은, 그것이 우리의 빵과 버터가 이 연구와 이미지 처리를 하고 있다는 것입니다. 따라서 데이터가 어디에서 오고 패키지가 무엇을 하는지에 대한 파이프라인에 대해 조금. 그래서, 우리는 이미지 기반 모델링, 여기에는 데이터 수집이 포함됩니다. 그래서 우리는 대부분의 경우 전자현미경 이미지, MRI 이미지, 모든 종류의 의료 이미지를 촬영합니다. 그런 다음 Seg3D 및 Cleaver와 같은 모든 패키지와 이를 처리하는 ShapeWorks가 있습니다. 우리가 원을 돌면서 이것은 일종의 워크플로이며 다음을 처리하는 ImageVis3D 및 FluoRender와 같은 일부 렌더링 응용 프로그램을 볼 수 있습니다. GPU 및 볼륨 렌더링.
따라서 우리는 다양한 이미지 유형을 처리하고 물론 이러한 모든 이미지 유형을 처리하기 위해 많은 데이터가 있습니다. 따라서 이러한 모든 다른 부문에서 소프트웨어 개발과 데이터 분석 모두에서 작업한다는 것은 우리가 실제로 구조화되지 않은 많은 양의 데이터를 보유하고 있음을 의미합니다. 따라서 우리 문제의 일부는 이것이 C++ 프로그램인 "HelloWorld"의 아주 작은 것부터 거의 XNUMX테라바이트 데이터 세트인 볼륨 렌더링의 토끼 망막 데이터 세트에 이르기까지 다양하다는 것입니다. 단일 파일 크기입니다. 그래서 우리는 아주 작은 것부터 아주 큰 것까지 모든 것을 운영합니다. 그리고 이 과정에서 임시 데이터도 많이 생성하는데, 이는 일종의 유지 및 추적에 큰 문제입니다. 이러한 큰 이미지 조각을 처리할 때 우리가 하는 일을 하기 위해 거기에서 생성되는 많은 중간 데이터가 있습니다.
이것이 우리가 스토리지를 구성하는 방식에 대한 일종의 레이아웃입니다. 우리 세계와 아마도 다른 많은 환경에서 네트워크 다음으로 중요한 것은 스토리지일 것입니다. 그것은 아마도 당신의 환경에서 가장 중요한 것 중 하나일 것입니다. 따라서 사실상 SCI의 모든 것이 스토리지 시스템과 연결됩니다. 두 개의 개별 Qumulo 클러스터가 있습니다.. 맨 아래에 하나가 있는데 이것이 QC208입니다. 그 중 24개가 있고 QC208 중 24개가 있는데 그 중간에 있습니다. 그리고 그것은 매우 특별한 이유로 분리되어 아래쪽에 있는 XNUMX은 일종의 오버헤드 및 일반 스토리지인 반면 QCXNUMX는 더 저렴하고 보조금에 작성하고 자금을 투입하는 것이 더 쉽기 때문입니다. 그래서, 우리가 이것을 그렇게 분리한 진짜 이유가 있습니다.
따라서 클라이언트의 경우 이 저장소에 모두 액세스하는 매우 다양한 클라이언트를 실행합니다. 200개 이상의 데스크탑, 웹 서버 및 웹 서비스, 이메일 서버에 이르기까지 이 두 클러스터의 모든 데이터를 백업하는 대규모 테이프 백업 라이브러리가 있습니다. 우리는 160 CPU 코어 범위에서 실행되는 대규모 공유 메모리 시스템을 보유하고 있습니다. 우리는 교수진이 특정 프로젝트를 수행하기 위해 가져오는 작은 전문 시스템을 많이 가지고 있으며, 두 개의 클러스터, 즉 하나의 CPU 전용 클러스터와 하나의 GPU 클러스터 간에 분할된 총 96개의 노드가 있습니다.
맨 위에는 저렴하고 그다지 유쾌하지 않은 보관소로 이어지는 작은 줄이 있습니다. 사용자가 실제로 임시 데이터를 Qumulo 시스템에 직접 쓰는 것을 허용하지 않습니다. 이는 모두 임시 데이터이기 때문입니다. 우리가 마지막으로 원하는 것은 다음 날 그냥 덮어쓰거나 누군가 잊어버리고 XNUMX년 동안 거기 앉아 있을 파일들로 우리의 큰 저장소와 멋진 저장소 시스템을 오염시키는 것입니다. 아무도 청소하지 않을 것입니다. 그래서 우리는 임시 데이터를 더 작은 시스템에 쓰고 모든 최종 데이터는 실제로 Qumulo 시스템에 저장되어 백업될 수 있고 사람들은 프로젝트의 다음 단계가 무엇이든 할 수 있습니다. 이 모든 다양한 연결을 위해 우리는 가난한 사람의 DNS만 사용하여 네트워크를 거의 순환하고 DNS 라운드 로빈을 수행합니다. 이 작업은 수년 동안 우리에게 매우 효과적이었습니다.
그래서 이것은 조금 더 많은 레이아웃입니다. 화면에서 보기가 조금 어렵지만 모든 클라이언트와 Qumulo 스토리지 사이에 10기가 스위치가 있습니다. 그리고 모든 스토리지를 Windows 상자, Linux 및 Mac으로 내보냅니다. 우리는 90%가 Linux와 Mac입니다. Samba용으로 SMB를 수행하는 몇 가지 Windows 상자가 있습니다. Qumulo에서 우리에게 정말 좋은 점은 우리가 Qumulo를 얻었을 때 우리가 Windows 사용자가 아닌 모든 Active Directory 서버의 수명을 다할 수 있었다는 것입니다. 활성 디렉토리. 그런 다음 사용자가 Qumulo 파일 시스템과 상호 작용하는 방식으로 Linux 상자 두 개를 여러 10기가바이트 인터페이스가 있는 제어 노트로 전용했으며 데이터 마이그레이션 및 여러 시스템 간에 데이터를 앞뒤로 이동하는 데 사용합니다. 그리고 그것들은 모두 NFS를 통해 이루어집니다. 우리는 또한 Linux 상자를 사용하여 그 위에 있는 Qumulo API를 통해 모든 관리 스크립트를 실행합니다. 이는 우리에게 매우 효과적이었고 매우 효율적이었습니다.
물론 우리는 이 모든 훌륭한 스토리지를 보유하고 있지만 데이터는 공백을 싫어합니다. 따라서 여유 공간이 있으면 채워집니다. 특히 고등교육을 하고 대학원생들과 일하면 넘칠 때까지 채워주겠죠? 따라서 대학원생과 함께 일하는 사람은 누구나 이것을 알고 있습니다. 오른쪽에 있는 가파른 선은 연초에 임시 데이터를 삭제하고 모든 데이터를 프로덕션으로 이동하기 시작했을 때입니다. 년도. 물론 스토리지는 실제로 제한된 리소스입니다. 따라서 데이터가 어디로 가는지 아는 것은 현재 하고 있는 일뿐만 아니라 미래의 용량 계획을 위해서도 정말 중요합니다. 예약을 시작하고 연구 예산에 스토리지를 맞추기 위해 얼마나 미리 시작해야 하는지 알고 있습니다.
따라서 이것은 Q08에서 제외되었으며 왼쪽에서 약간 강조 표시된 열을 볼 수 있습니다. 사용자가 많은 데이터를 작성했으며 그 아래에서 사용자가 작성한 경로를 정확히 볼 수 있습니다. 그것은 약 52테라바이트의 데이터이며 그래프에서 막대 하나를 클릭하기만 하면 누가 그것을 썼고 그 데이터가 어디로 가는지 알아내기가 정말 쉽습니다. 물론 목표는 연구자가 연구를 계속할 수 있도록 돕는 것입니다. 당신은 연구원에게 "죄송합니다. 우리 시스템에 공간이 없습니다"라고 말하고 싶지 않을 것입니다. 따라서 용량 계획은 발생하는 일의 중요한 부분입니다. 그래서 우리는 이것을 다른 해상도에서 볼 수 있습니다. 30주입니다. 또한 Qumulo 시스템이 기본적으로 Qumulo의 API와 함께 API와 함께 제공하는 72일 해상도에서 이를 XNUMX일 해상도로 볼 수 있습니다. 나중에 추가 분석을 위해 이 모든 데이터를 별도의 시스템에 덤프할 수도 있습니다.
자, 용량 계획의 일부입니다. 연구를 계속하는 한 그 다음 부분은 용량 억제입니다. 우리에게 데이터가 어디에 있고 얼마나 사용되는지 실시간으로 파악할 수 있다는 것은 매우 중요합니다. 그래서 이것은 "Neuro"라고 불리는 약 30테라바이트의 프로젝트를 보여줍니다. 이 프로젝트가... 간질 및 발작 상태와 같은 상태에 대한 깊은 신경 자극을 포함하는 프로젝트인 이유 중 하나입니다. 그래서 그들은 많은 신경 자극을 하고 있습니다. 그들은 이 프로젝트를 수행하는 것을 상상할 수 있는 최악의 데이터 IO 사례를 가지고 있습니다. 따라서 10개의 스레드가 있는 5개의 Xeon256 서버에서 실행됩니다. 이러한 스레드 각각은 대략 2,600개의 스레드가 있는 경우 N1 값이 포함된 16개의 파일을 작성한 다음 해당 파일을 모두 실행합니다. 그리고 하나의 숫자가 포함된 하나의 파일을 작성하기 때문에 그들의 성능은 극악이었습니다.
그리고 이제 이 시스템과 우리가 한 다른 성능 조정 덕분에 이제 일부 IO 문제를 완화하는 데 도움이 되는 일부 Python 스크립트를 작성했습니다. 그러나 네, 그것은 아마도 한 번에 2,500개의 숫자가 포함된 작은 파일 하나에 관한 것입니다. 꽤 잔인합니다. 물론 이러한 용량 제한의 일부는 "이봐, 할당량에 도달했습니다."라고 말하는 아주 작은 스크립트가 있다는 것입니다. 그래서 우리는 이 모든 스크립트를 다음과 같이 작성했습니다. 쿠물로 API. 우리는 인력 할당량을 할당했으며 이제 IT 쪽에서 무슨 일이 일어나고 있는지 알고 있을 뿐만 아니라 때때로 이러한 스크립트를 보내 사용자에게 알리고 다음과 같이 말할 수 있습니다. 할당량 위반 상태" 교수진은 사용자가 데이터를 어떻게 사용하고 있는지 알고 싶어하고 우리 환경에서 프로젝트별 및 그룹별 보고서를 생성 및 작성하기가 쉽습니다.
물론 성능은 여기에서 고성능 시스템에 대해 이야기하고 있습니다. 따라서 성능은 결국 꽤 중요하지만 시스템이 제대로 작동하지 않는 경우 아무도 사용할 수 없다면 얼마나 많은 스토리지가 있는지는 중요하지 않습니다. 고성능 스토리지를 사용할 수 없으면 187입니다. 따라서 이러한 측정항목을 이해하고 관찰하는 것은 우리가 하는 일에서 매우 중요한 부분입니다. 맨 위에 있는 것은 초당 약 9메가를 쓰는 것을 볼 수 있습니다. 그렇게 많이 읽지는 않습니다. 아침 00시에 최고를 찍었기 때문에 흥미로운 일입니다. 그래서, 일부 대학원생들이 실제로 정오까지 잠을 자지 않는 것을 보는 것은 일종의 좋은 일입니다. 그러나 궁극적으로 이 숫자는 무엇을 의미합니까? 교수 연구원에게 120MB 또는 187MB는 무엇을 의미합니까? 이것이 의미하는 바는 궁극적으로 그들에게 통찰력이 필요한 때라는 것입니다. 결과를 다시 받는 데 얼마나 걸립니까?
그리고 좋은 성과를 내기 위해서는 엄청난 숫자지만 사람들에게 단순한 숫자보다 더 의미 있는 것으로 변환되어야 합니다. 성과가 좋지 않으면 화난 고객과 화난 교수진이 발생하며 일반적으로 화난 교수진은 자신의 사무실에서 화를 내지 않습니다. 그들은 내 사무실에 와서 내 사무실에 화를 내는데, 이는 일반적으로 좋은 일이 아닙니다. 다른 흥미로운 점 중 하나는 오늘 아침에 제가 추가한 것입니다. 여기 하단 모서리에 있는 스파이크입니다. 오늘 아침 우리 시스템을 보고 이 스파이크를 보았고 "글쎄, 그 스파이크는 무엇입니까?"라고 말했습니다.
그리고 Qumulo 시스템은 실제로 알아내기가 정말 쉽습니다. 오늘 아침에 거기에 있는 스파이크는 실제로 이전에 큰 스파이크를 수행한 동일한 사용자였습니다... 보여드리겠습니다. 사실 바로 저 하얀색 선입니다. 해당 데이터를 작성한 동일한 사용자이며 오늘 아침에 동일한 사용자이고 사용자가 수행하는 작업이 30년임을 알아내는 데 약 2018초가 걸렸습니다. 이 권리를 얻으십시오. 그는 "심해 소행성 충돌의 시각화 및 분석에 전념하는 2018 EEE Cyviz [SP] 콘테스트"에서 작업하고 있습니다. 그러니까, 그게 XNUMX년이 아니라는 것을 고려하면, 그 학생은 이미 자신의 일정보다 훨씬 앞서 일을 하고 있고, 이것은 또한 학생으로서는 이례적인 일입니다.
좋습니다. 성능에 대해 더 자세히 설명하자면, Qumulo 시스템은 클라이언트 성능을 분석하는 정말 좋은 방법을 제공합니다. 위쪽에 있는 녹색 항목 중 하나가 많은 읽기를 수행하고 있는 것을 볼 수 있습니다. 쓰기 작업을 수행하는 시스템이 있습니다. 좋은 점은 드릴다운할 수 있고 모든 데이터가 어디로 가고 있는지 정확히 어떤 디렉토리를 매우 빠르게 볼 수 있다는 것입니다. 이것은 200개의 데스크탑과 수많은 다른 시스템을 다룰 때 우리에게 정말 도움이 됩니다. 어떤 시스템이 어디에 쓰고 있는지 파악하는 것은 매우 중요합니다. 이것은 우리가 매우 많은 숫자를 보는 데 익숙하지 않았기 때문에 실제로 Qumulo 지원과 몇 가지 흥미로운 전화 대화로 이어졌습니다. 이전 시스템에서는 Qumulo에서와 같은 성능을 달성할 수 없었습니다.
공황 상태에서 실제로 Qumulo 지원팀에 전화를 걸었기 때문에 사실 좀 웃겼습니다. 나는 무엇을 합니까? 그것은 내 클러스터를 죽일 것입니다.” 그들은 "오, 괜찮아요. 걱정하지 마십시오.” 그래서, 몇 번 후, 우리가 단순히 익숙했던 성능 수치를 보기 시작했을 때 가을이 시작되었습니다. 이제 우리는 그것에 많이 익숙해졌고 호출할 때 했던 지원 문제가 없습니다. 불필요하게.
따라서 물론 성능의 일부인 전체 성능은 가동 시간입니다. 지난 28년 동안 우리는 시스템에 120%를 기록했습니다. 작년에 우리는 약 68분의 가동 중지 시간을 가졌습니다. 그것은 단지 패치와 사소한 업그레이드를 수행하기 위한 것이었습니다. 따라서 Uptime 성능의 관점에서 볼 때 우리에게는 믿을 수 없을 정도로 안정적이었습니다. 그래서 재미있는 이야기가 아닌 Uptime에 대한 한 가지는 우리 데이터 센터의 사소한 결함으로 인해 100분의 런타임이 있지만 전원이 꺼지면 냉각이 되지 않고 냉각이 중단됩니다. 20도에서 XNUMX도까지 약 XNUMX분.
이제 우리가 6년 전 Qumulo로 테스트를 하고 생산 환경을 구축하는 과정에 있었을 때 완전히 관련이 없는 Salt Lake Valley의 두 가지 정전으로 하루에 두 번 발생했습니다. Qumulo 시스템에서 일반적으로 큰 클러스터에서 발생하는 일은 모든 것을 종료하는 자동화된 스크립트가 있다는 것입니다. Qumulo 클러스터에는 아직 그런 기능이 없었습니다. 그래서 말 그대로 데이터 센터에 들어가서 모든 전원 코드를 뽑았습니다. 자, 이것은 절대적으로 권장하지 않는 일이지만 Qumulo 시스템에서 하루에 두 번 했습니다. 우리가 보유한 모든 스토리지 시스템과 모든 디스크 어레이 중에서 Qumulo는 결함, 데이터 손상, 디스크 손실 없이 돌아온 유일한 제품입니다. 그것을 처리하는 유일한 시스템이었습니다. 다른 공급업체의 기본 코어 세트 파일 시스템에서 15개 노드에서 XNUMX개의 드라이브가 손실되었습니다. 우리의 싸고 쾌활한 시스템은 완전한 손실이었습니다. 그것은 모든 단일 드라이브를 잃었습니다.
그래서 제 생각에 그것은 흥미로운 테스트였습니다. 여러분에게 권하고 싶지는 않지만 우리는 할 수 있었습니다. 물론, 오늘날 우리는 이 용량 계획을 가지고 있고 이제 이 모든 데이터를 볼 수 있기 때문에 이제 어디로 가야 하는지, 어떻게 계획해야 하는지 알 수 있습니다. 이것은 향후 24년 동안의 일종의 마이그레이션 계획입니다. 10년차에는 내년에 또 다른 QC40를 추가할 예정입니다. 내년에는 208개를 더 추가할 예정입니다. 그런 다음 XNUMX년차에 하나를 추가합니다. 그 시점에서 우리는 네트워크를 XNUMX기가에서 XNUMX기가로 업그레이드한 다음 다른 QCXNUMX을 추가할 것입니다. 이것이 일종의 마이그레이션 계획이며, 물론 스케일 아웃 솔루션이기 때문에 다운타임 없이 모든 것을 문자 그대로 추가할 수 있습니다. 우리는 그것들을 네트워크에 연결하고, IP를 부여하고, 그것은 우리에게 아주 좋습니다.