이번에는 1 년 동안 Docker 를 기반으로 프라이빗 클라우드를 구축하는 과정에서 우리가 겪었던 문제, 해결 방법, 경험, 그리고 우리의 경험과 사고를 공유함으로써 여러분을 격려하고자 합니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 성공명언)

프로덕션 환경에서 Docker 를 사용한 경험과 체험이 있다. 프라이빗 클라우드 프로젝트는 20 14 크리스마스 기간 동안 시작되었습니다. 반년여의 발전과 세 차례의 대진흥을 거쳐 점차 일정한 규모를 형성하였다.

구조

클러스터 관리

당시 Docker 자체의 클러스터 관리 기능은 아직 성숙하지 않았기 때문에, 우리는 방금 부상한 Swarm 을 선택하지 않고 업계에서 가장 성숙한 OpenStack 을 사용하여 Docker 와 KVM 을 동시에 관리할 수 있었습니다. Docker 는 가상화 비즈니스 요구 사항을 충족하기 위해 가상 시스템으로 운영됩니다. 미래의 아이디어는 애플리케이션을 마이크로서비스로 분할하여 애플리케이션 기반 PaaS 배포 및 게시를 가능하게 하는 마이크로서비스입니다.

OpenStack 을 통해 Docker 를 어떻게 관리합니까? OpenStack+nova-docker+Docker 의 아키텍처 모델을 채택했습니다. Nova- docker 는 StackForge 의 오픈 소스 프로젝트입니다. Nova 의 플러그인으로서 Docker 의 RESTful 인터페이스를 호출하여 컨테이너의 시작 및 중지를 제어합니다.

IaaS 를 기반으로 어플리케이션 유연성, 그레이스케일 업그레이드 등의 기능을 지원하고 일정 예약 전략을 지원하여 PaaS 계층의 주요 기능을 구현하는 스케줄링 등의 구성 요소를 개발했습니다.

Docker 와 Jenkins 를 모두 기반으로 CI (지속적인 통합) 를 구현합니다. Git 의 프로젝트에 Git 푸시가 발생하면 Jenkins Job 자동 빌드가 트리거됩니다. 프로젝트가 성공적으로 구축되면 Docker 이미지가 생성되어 미러 웨어하우스로 푸시됩니다. CI 생성 Docker 미러는 PaaS 의 API 또는 인터페이스를 통해 개발 및 테스트 환경의 인스턴스를 업데이트하고, 프로덕션 환경의 인스턴스를 최종 업데이트하여 지속적인 통합 및 지속적인 제공을 가능하게 합니다.

네트워킹 및 스토리지

네트워크 측면에서 Dell 은 기본적으로 Docker 가 제공하는 NAT 네트워크 모드를 사용하지 않습니다. NAT 는 성능 손실을 초래할 수 있습니다. Linux bridge 및 Open vSwitch 는 OpenStack 을 통해 지원되므로 iptables 를 시작할 필요가 없습니다. Docker 의 성능은 물리적 시스템의 95% 에 가깝습니다.

컨테이너 모니터링

모니터링 방면에서 컨테이너 도구를 개발하여 컨테이너 부하 값 계산을 실현하여 원래의 top, free, iostat, uptime 등의 명령을 대체했습니다. 이렇게 하면 컨테이너에서 일반 명령을 사용할 때 비즈니스에서 전체 물리적 시스템이 아닌 컨테이너의 값을 볼 수 있습니다. 현재 우리는 Lxcfs 를 우리 플랫폼에 이식하고 있습니다.

또한 주요 프로세스 모니터링, 로그 모니터링, 실시간 PID 번호, 네트워크 연결 추적 번호, 컨테이너 oom 경고 등 호스트에 몇 가지 임계값 모니터링 및 경고를 추가했습니다.

중복 및 격리

중복성과 격리 방면에서 우리는 대량의 중복 방안과 기술 준비를 했다. Docker 데몬을 시작하지 않고 오프라인으로 docker 의 데이터를 복구할 수 있습니다. Docker 는 물리적 시스템 간 콜드 마이그레이션, 동적 CPU 확장/축소, 네트워크 입출력 디스크 입출력 속도 제한도 지원합니다.

발생한 문제 및 해결책

1 년도 채 안 되어, 우리는 상품화와 실제 사용에서 다양한 문제를 만났다. Docker 를 사용하는 프로세스도 Docker 를 지속적으로 최적화하고, 문제를 지속적으로 찾고, 문제를 해결하는 프로세스입니다.

우리의 현재 생산 환경은 CentOS 6.5 입니다. 한때 업무 측은 자신이 사용하는 Docker 컨테이너가 물리적 시스템이라고 착각했고, Docker 컨테이너에 또 다른 Docker 를 설치했는데, 순식간에 커널 충돌이 발생하여 같은 물리적 시스템의 다른 Docker 컨테이너에 영향을 미쳤다.

커널 버전 2.6.32-43 1 이 네트워크 네임 스페이스를 제대로 지원하지 않아 Docker 에 bridge 를 만들면 커널이 충돌할 수 있다는 분석이 나왔다. 상류에서는 이 버그를 2.6.32-43 1 에서 2.6.32-504 로 업그레이드한 후 문제가 해결되었습니다.

또 다른 사용자가 작성한 프로그램에는 버그가 있는데, 생성된 스레드는 제때에 재활용되지 않아 컨테이너에 많은 스레드가 있습니다. 마지막 호스트는 "bash: fork: 메모리를 할당할 수 없습니다" 라는 오류 메시지로 명령이나 ssh 로그인을 수행할 수 없지만 사용 가능한 메모리를 보면 충분합니다.

분석에 따르면 커널의 PID 격리 지원은 완벽하지 않으며 PID _ MAX (/PROC/Sys/Kernel/PID _ MAX) 는 전역적으로 공유됩니다. 한 컨테이너의 PID 수가 최대 32768 개에 도달하면 호스트 및 기타 컨테이너가 새 프로세스를 만들 수 없습니다. 최신 4.3-rc 1 컨테이너당 pid_max 제한만 지원.

또한 docker 의 호스트 커널 로그가 무질서한 문제를 일으킬 수 있음을 관찰했습니다. 분석 결과 커널에는 log_buf 버퍼가 하나만 있으며, printk 에서 인쇄한 모든 로그는 먼저 이 버퍼에 배치됩니다. 컨테이너의 docker host 와 rsyslogd 는 syslog 를 통해 커널의 log_buf 버퍼에서 로그를 가져와 로그를 혼동합니다. 이 문제는 컨테이너에서 rsyslog 구성을 수정하고 호스트에서 커널 로그만 읽도록 함으로써 해결할 수 있습니다.

또한 장치 매퍼 dm-thin 폐기로 인한 커널 충돌 등의 문제도 해결했습니다.

경험과 사고

마지막으로, 우리의 경험과 사고를 공유하세요. KVM 의 검증된 가상화 기술에 비해 컨테이너에는 아직 미비한 부분이 많다. 클러스터 관리, 네트워크 및 스토리지 외에 가장 중요한 것은 안정성입니다. 안정성에 영향을 미치는 주요 요인은 격리의 불완전성이며 한 컨테이너로 인한 문제가 전체 시스템에 영향을 줄 수 있다는 것입니다.

컨테이너의 Memcg 는 slab 캐시를 재확보할 수 없으며 더티 캐시 수를 제한하지 않으므로 OOM 문제가 발생하기 쉽습니다. 또한 pid_max 와 같은 procfs 의 일부 파일 인터페이스는 컨테이너 기반이 될 수 없습니다.

또 다른 점은 용기 아래의 운영 및 유지 관리 수단과 경험에 미치는 영향입니다. Ss, free, df 등과 같은 일부 시스템 유지 관리 도구. , 컨테이너에서 사용할 수 없거나 결과가 물리적 시스템과 일치하지 않습니다. 시스템 유지 관리 툴은 일반적으로 procfs 아래의 파일을 액세스하는데, 이러한 툴은 수정이 필요하거나 적응이 필요하기 때문입니다.

컨테이너가 완벽하지는 않지만, 우리는 여전히 용기의 미래 발전에 대해 매우 낙관적입니다. Kubernetes, Mesos, Hyper, CRIU, runC 등 컨테이너와 관련된 오픈 소스 소프트웨어. , 우리의 관심의 초점입니다.

질문과 대답. A

Q: 컨테이너 간의 로드 밸런싱은 어떻게 이루어집니까?

A: 컨테이너 간 로드 밸런싱은 PaaS 와 SaaS 수준에서 더 많습니다. Dell 의 P 계층은 도메인 이름 또는 이름 서비스를 통해 외부 공용 인터페이스를 제공하는 레이어 4 및 레이어 7 의 동적 라우팅을 지원합니다. 컨테이너 기반 그레이스케일 업그레이드와 탄력적인 확대/축소를 실현할 수 있습니다.

Q: OpenStack 이 CentOS 6.5 를 실행하고 있습니까?

A: 네, 하지만 OpenStack 과 Docker 가 의존하는 패키지를 업그레이드했습니다. 우리는 내부 yum 소스를 유지 관리합니다.

Q: 컨테이너 IP 는 정적 정렬 또는 동적 획득입니까?

A: 이것은 운영 및 유지 보수 부서에서 관리하는 네트워크 모델과 관련이 있습니다. 인트라넷에는 DHCP 서비스가 없으므로 IaaS 계층의 경우 컨테이너의 IP 가 정적으로 할당됩니다. PaaS 계층의 경우 DHCP 서비스가 있으면 컨테이너의 App 에 노출된 IP 와 포트가 동적일 수 있습니다.

질문: Ubuntu 를 배치할 때 사용해 본 적이 있습니까? 이 두 시스템 간의 차이점을 연구한 적이 있습니까? 또한 OpenStack 에서 이러한 가상 시스템을 어떻게 모니터링합니까?

A: Ubuntu 는 운영 환경에서 CentOS 를 사용하고 있기 때문에 시도해본 적이 없습니다. 우리의 미들웨어 팀은 회사의 기계를 감시할 책임이 있다. 모니터링 팀과 협력하여 모니터링되는 에이전트를 호스트와 각 컨테이너에 배포하여 가상 시스템처럼 모니터링할 수 있습니다.

물론 컨테이너의 데이터는 cgroups 에서 검색해야 합니다. 이 부분의 데이터 추출 작업은 저희가 수행합니다.

Q: 컨테이너 간의 네트워크 선택에 대한 제안이 있습니까? 가상 네트워크 카드는 물리적 네트워크 카드보다 성능 손실이 적지 않다고 한다. Docker 가 가지고 있는 직법과 ovs 는 감당할 수 있나요?

답: 컨테이너 네트워크에서는 기본 NAT 방식을 사용하지 않는 것이 좋습니다. NAT 는 성능 손실을 초래할 수 있기 때문입니다. 앞서 말씀드렸듯이, iptables 를 시작할 필요가 없습니다. Docker 의 성능은 물리적 시스템의 95% 에 가깝습니다. Docker 의 weaves 밑바닥은 브리지나 오픈 vSwitch 를 사용해야 한다. Nova-docker 의 소스 코드를 보면 더 쉽게 이해할 수 있습니다.

Q: 고정 IP 는 LXC 를 통해 구현됩니까?

A: 고정 IP 구현은 nova-docker 의 novadocker/virt/docker/vifs.py 에서 구현됩니다. 구현 원칙은 IP 명령을 통해 veth 쌍을 추가한 다음 IP link set/ip netns exec 와 같은 일련의 명령을 사용하여 수행하는 것입니다. 정형의 원리는 직물의 원리와 비슷하다.

Q: 컨테이너에서 프로세스 gdb 를 어떻게 관리합니까? 너는 광발을 컨테이너에 포장했니?

A: 컨테이너의 gdb 에는 문제가 없습니다. 직접 yum 으로 gdb 를 설치할 수 있습니다.

Q: * * * * 스토리지를 컨테이너에 직접 담을 수 있습니까?

A: 시도해 본 적은 없지만, docker -v V 를 통해 이런 방식은 문제없을 겁니다.

Q: Docker 데몬을 시작하지 않고 오프라인으로 Docker 의 데이터를 복구하려면 어떻게 해야 합니까?

A: 오프라인 복구의 원칙은 dmsetup create 명령을 사용하여 임시 DM 디바이스를 만들고 Docker 인스턴스에서 사용하는 DM 디바이스 번호에 매핑하는 것입니다. 이 임시 장치를 설치하면 원시 데이터를 복구할 수 있다.

Q: Docker 는 물리적 시스템 간 콜드 마이그레이션을 통해 동적 CPU 확장/축소를 지원합니다. 네트워크 입출력 디스크 입출력 속도 제한은 어떻게 이루어집니까? 자세히 말씀해 주시겠어요?

A. Docker 의 콜드 마이그레이션은 nova-docker 를 수정하여 OpenStack 마이그레이션을 수행하는 인터페이스입니다. 특히 docker 를 통해 제출되고, docker 가 내부 레지스트리로 푸시되고, docker 가 스냅샷을 당겨 두 물리적 시스템 간에 수행됩니다.

동적 CPU 용량 확장/축소, 네트워크 입출력 디스크 입출력 속도 제한은 주로 novadocker 를 통해 cgroups 의 CPU, IOPs, bps, TC 매개변수를 수정하여 이루어집니다.

Q: 앞으로 드림롱 프로젝트를 고려할 것인가, 아니면 Swarm 을 선택할 것인가?

A: 이것들은 모두 우리의 선택입니다. 우리는 벌떼를 고려할 수 있다. Magnum 의 밑바닥은 Kubernetes 와 같은 클러스터 관리 체계를 호출하기 때문에 Swarm 이나 Kubernetes 를 직접 선택하는 것이 Magnum 보다 낫다. 물론, 이것은 단지 나의 개인적인 견해일 뿐이다.

Q: 귀하의 서비스는 동일한 이미지를 기반으로합니까? 서로 다른 이미지인 경우 컴퓨팅 노드가 컨테이너를 신속하게 시작할 수 있도록 어떻게 보장합니까?

A: 운영 및 유지 보수 부서는 일관된 기본 이미지 세트를 유지 관리합니다. 다른 업무의 미러링은 이 미러를 기반으로 합니다. 연산 노드를 초기화할 때 docker pull 을 통해 로컬에서 기본 미러를 당기는 것도 많은 기업들의 일반적인 관행입니다. 내가 알기로는 텐센트와 360 은 모두 비슷한 방법이다.

Q: 기존 * * * 스토리지를 사용하여 핫 마이그레이션을 계속하는 것을 고려해 본 적이 있습니까?

A: 분산 스토리지와 * * * 공유 스토리지를 모두 고려하고 있습니다. 다음으로, 우리는 용기의 열 마이그레이션을 계획하고 있다.

질문: 공용 IP 를 컨테이너에 직접 바인딩합니까, 아니면 다른 방법으로 컨테이너 전용 IP 에 매핑합니까? 그렇다면 원래 계층 2 VLAN 격리를 어떻게 해결합니까?

A: 우리는 프라이빗 클라우드이고 부동 IP 는 포함하지 않기 때문에 공용 IP 라고 생각할 수 있습니다. VLAN 의 레이어 2 격리는 스위치에서 수행할 수 있습니다. Open vSwitch 를 사용하여 서로 다른 VLAN 을 분할하여 Docker 컨테이너와 물리적 시스템의 네트워크 격리를 실현했습니다.

Q. 디바이스 매퍼 DM-thindiscard 에 대해 자세히 설명해 주시겠습니까?

A: 4 월에는 종종 두 개의 호스트가 이유 없이 재부팅됩니다. 내가 가장 먼저 생각한 것은 /var/log/messages 로그를 보는 것이었지만, 재부팅 시간이 다가오자 재시작과 관련된 정보를 찾지 못했다. 그런 다음 /var/crash 디렉토리에서 커널 충돌 로그 vmcore-dmesg.txt 를 찾았습니다. 로그 생성 시간은 호스트 재부팅 시간과 일치하며 커널 충돌 후 호스트가 자동으로 재시작됨을 나타냅니다. "드라이버/MD/persistent-data/DM-btree-remove.c:181의 커널 오류!" 。 스택에서 볼 수 있듯이, dm-thin 은 폐기 준비를 하고 있다. 버그의 근본 원인은 알 수 없지만 직접적인 원인은 폐기 작업으로 인해 발생하므로 폐기 지원을 꺼서 피할 수 있습니다.

모든 호스트 구성에서 폐기 기능을 비활성화한 후에도 같은 문제가 더 이상 발생하지 않습니다.

올해 CNUTCon 컨퍼런스에서 텐센트와 대중평론은 그들이 Docker 를 사용했을 때 이 붕괴를 언급했는데, 그들의 해결책은 우리와 똑같다. (윌리엄 셰익스피어, 텐센트, Northern Exposure (미국 TV 드라마), 스포츠명언)

Q: 임계값 모니터링 및 경고 블록에 높음, 중간, 낮음 수준의 경고가 있습니까? 현재 저급 경보가 나타나면 사용자 액세스를 제한하거나 현재 사용자가 사용 중인 서비스를 차단하거나 사태를 방치하기 위한 조치를 취할 것인가?

A: 경보의 경우, 운영 및 유지 관리 부서에는 온라인 비즈니스의 안정성을 담당하는 전문 PE 가 있습니다. 경고가 발생하면 서비스와 PE 모두 동시에 경고 정보를 받습니다. 단일 가상 시스템에 영향을 미치는 경우 PE 는 비즈니스에 심각한 경우 적시에 업무 중단을 통보합니다. 우리는 PE 와 협력하여 업무 측이 제때에 업무를 옮길 수 있도록 할 것이다.

Q: 자체 개발 컨테이너 도구가 오픈 소스입니까? GitHub 에 코드가 있습니까? 왜 아직 오픈 소스가 아닌가요? 후기 오픈 소스가 가능합니까? 모니터링 컨테이너의 세분화에 대해 어떻게 생각하십니까?

A: 현재 오픈소스는 없지만 오픈소스는 문제없다고 생각합니다. 우리의 좋은 소식을 기다려 주세요. 컨테이너의 세밀한 모니터링과 관련하여 주요 아이디어는 호스트 수준에서 컨테이너의 상태를 모니터링하는 것이고 컨테이너의 내부 모니터링은 업무 당사자가 수행하는 것입니다.

Q: 컨테이너 레이어는 레이어 수에 관심이 있습니까? 기본 파일 시스템이 ext4 입니까? 최적화 전략이 있습니까?

물론, 우리는 가지고 있습니다. 미러 수준을 병합하여 docker 가 미러를 당기는 시간을 최적화했습니다. Docker pull 에서 각 계층을 확인하는 데 시간이 오래 걸립니다. 레이어 수를 줄이면 크기가 작아질 뿐만 아니라 docker 당기기 시간도 크게 단축됩니다.

Q: 컨테이너의 memcg 는 slab 캐시를 재활용하거나 더티 캐시 수를 제한하지 않아 OOM 문제가 발생하기 쉽습니다. -캐시 문제를 어떻게 처리합니까?

A: 실제 경험에 따르면 일부 캐시를 사용 메모리로 계산하여 실제 사용 값에 최대한 가깝게 계산했습니다. 또한 컨테이너의 경우 메모리 경고 임계값이 적절하게 낮아집니다. 컨테이너 OOM 에 대한 경보도 증가시킵니다. CentOS 7 로 업그레이드하는 경우 특정 제한 사항에 맞게 kmem.limit_in_bytes 를 구성할 수도 있습니다.

질문: 컨테이너 네트워크의 격리에 대해 더 자세히 말씀해 주시겠습니까?

A: 액세스 격리. 현재 2 층 격리는 주로 VLAN 을 사용하며, 이후 VXLAN 을 격리하는 것도 고려된다. 네트워크 트래픽 제어, 우리는 OVS 에 포함된 포트 기반 QoS, 기본 TC, 트래픽 기반 흐름 제어 등을 사용합니다.

Q: 모두 CentOS 6.5 를 사용합니까? 이 기술이 실현되었다. 운수인가요, 개발인가요?

A: 안정은 생산 환경 1 위입니다. CentOS 6.5 는 주로 회사 전체의 운영 및 유지 보수를 담당하고 있습니다. 대형 버전이 업그레이드될 때 우리는 운영 유지 관리 부서에 건의할 것이다. 가상화 자체의 안정성을 동시에 향상시킵니다.

Q: 컨테이너 간 직접 통신은 어떻게 합니까? 네트워크는 어떻게 설정합니까?

A: 같은 물리적 기계에 있다는 말인가요? 현재는 여전히 IP 를 통해 소통한다. 특정 네트워크는 브리지 모드나 VLAN 모드를 사용할 수 있습니다. Emc 는 Open vSwitch 를 사용하여 컨테이너 간에 격리하거나 통신할 수 있는 VLAN 모드를 지원합니다.

Q: Dcoker 를 통합하기 위해 nova-api 를 사용하고 있습니까? Docker-API 와 같은 docker 의 고급 기능을 사용할 수 있습니까? 더구나, 왜 Docker 를 통합하기 위해 열을 사용하지 않습니까?

A: 오픈 소스 소프트웨어인 nova-docker 를 사용하고 있습니다. Nova-docker 는 StackForge 의 오픈 소스 프로젝트입니다. 기존 libvirt 대신 nova 플러그인으로 Docker 의 RESTful 인터페이스를 호출하여 컨테이너의 시작 및 중지를 제어합니다.

Heat 또는 NOVA 를 사용하여 Docker 산업을 통합할지 여부는 항상 논란의 여지가 있습니다. 우리는 우리가 해결하고자 하는 문제에 더 관심이 있습니다. (존 F. 케네디, Northern Exposure (미국 TV 드라마), 도전명언) Heat 자체는 복잡한 관계에 의존하고 있지만 업계에서는 널리 사용되지 않습니다. 그렇지 않으면 커뮤니티도 Magnum 을 출시하지 않을 것입니다.

질문: 현재, DC 를 통과하거나 비슷한 방향을 통과하는 컨테이너가 있습니까?

A: 우리는 여러 개의 기계실에 여러 개의 클러스터를 배치했으며, 각 기계실에는 별도의 클러스터가 있습니다. 이를 바탕으로 Dell 은 여러 클러스터의 통합 관리를 가능하게 하는 자체 관리 플랫폼을 개발했습니다. 이와 함께 Docker 레지스트리 V 1 을 구축하고 Docker 레지스트리 V2 로 내부 업그레이드를 준비하여 Docker 미러링을 위한 DC 간 미러링 기능을 제공합니다.

Q: 저는 현재 Docker 의 지속적인 통합 및 클러스터 관리를 추진하고 있지만, 컨테이너의 유연한 관리 및 자원 모니터링과 같은 더 많은 컨테이너를 관리하는 것도 문제라는 것을 알게 되었습니다. Kubernetes 와 Mesos 중 어느 것이 좋을까요? 상업에 사용되는 경우 외부 도메인 이름은 호스트를 통해 통신하고 외부 IP 가 하나뿐이기 때문에 어떻게 확인합니까?

A: Kubernetes 와 Mesos 의 경우 아직 예비 연구 단계에 있습니다. 우리의 현재 P 계층 스케줄링은 스스로 개발한 것이다. Etcd 를 통해 인스턴스 상태, 포트 및 기타 정보를 유지 관리합니다. 계층 7 의 경우 Nginx 를 통해 해결할 수 있고, 계층 4 의 경우 이름 지정 서비스에 의존해야 합니다. 우리는 우리 자신의 이름 지정 서비스를 가지고 있기 때문에 이러한 문제를 해결할 수 있다. IP 는 하나뿐이지만 노출된 포트는 다릅니다.

Q: Hyper Hypernetes 사용을 고려해 본 적이 있습니까? 시작 속도를 유지하면서 컨테이너를 호스트 코어에서 격리합니까?

A: Hyper 우리는 계속 주시하고 있습니다. Hyper 는 아주 좋은 생각이고, 미래도 배제하지 않는다. 사실, 우리는 Hyper 가 핫 마이그레이션을 이루기를 가장 바라며, Docker 는 아직 할 수 없다.

Q: 호스트가 일반적으로 사용하는 구성은 무엇입니까? 독립 실행형 호스트 또는 클라우드 서버?

A: Dell 은 별도의 서버와 물리적 시스템을 사용하는 자체 기계실이 있습니다.

Q: 컨테이너에서 호스트 간 통신에 사용하는 솔루션은 무엇입니까?

A: 컨테이너가 호스트를 통과할 때 통신용으로 3 계층, 즉 IP 를 사용해야 합니다. 컨테이너에는 독립적인 IP 또는 호스트 IP+ 포트 매핑이 있을 수 있습니다. 현재는 독립 IP 로 관리하기가 더 좋다.

Q: 귀사의 Docker 사용이 가상 시스템과 더 비슷하다고 생각합니다. 컨테이너의 관점에서 직접 사용을 고려하지 않는 이유는 무엇입니까? 역사적인 이유인가요?

A: 우리가 가장 먼저 고려하는 것은 사용자의 수용도와 개조 비용입니다. 사용자의 관점에서 볼 때, 그는 비즈니스가 컨테이너에서 실행되는지 가상 시스템에서 실행되는지는 신경쓰지 않는다. 그는 응용 프로그램의 배포 효율성과 응용 프로그램 자체의 안정성과 성능에 미치는 영향에 더 관심이 있습니다. 컨테이너의 관점에서 볼 때, 업무 측의 기존 응용 프로그램 중 일부는 큰 개조가 필요할 수 있습니다. 로그 시스템, 전체 링크 모니터링 등 물론 가장 중요한 것은 기존 운영 및 유지 보수 시스템에 미치는 영향이 비교적 클 것이라는 것이다. 컨테이너 관리는 운비에게 도전이며, 운수의 수용에는 하나의 과정이 필요하다.

물론, Docker 를 컨테이너 패키징 어플리케이션으로 사용하여 PaaS 배포 및 동적 스케줄링을 실현하는 것이 우리의 목표입니다. 사실 우리도 이 방향으로 노력하고 있다. 또한 업무 측 분할 애플리케이션, 마이크로서비스 구현도 필요하며, 이를 위해서는 절차가 필요합니다.

Q: 사실 컨테이너도 가상 시스템으로 사용하고 싶습니다. 가상 시스템으로 어떤 미들웨어를 실행하십니까? 우리는 테스트 관건과 대량의 상대적 독립 환경인 WebLogic 사이의 갈등을 해결해야 합니까?

A: 프런트 엔드 마스터 웹 사이트에서 백 엔드 미들웨어 서비스에 이르기까지 많은 비즈니스를 운영합니다. Dell 의 미들웨어 서비스는 다른 팀에서 개발한 제품으로, 전면 백그라운드 비즈니스 로직을 분리했습니다.

Q: 귀사는 OpenStack 을 사용하여 Docker 와 KVM 을 모두 관리하고 있습니까? 자체 웹 구성 인터페이스를 개발하고 있습니까, 아니면 API 로만 관리합니까?

A: 우리는 자체 개발 네트워크 관리 플랫폼을 갖추고 있습니다. Dell 은 하나의 플랫폼을 통해 여러 클러스터를 관리하고 운영, 로그, 모니터링 등의 시스템을 연결하여 통합 API 인터페이스를 노출하기를 원합니다.

Q: 위에서 공유한 사례에서 2.6 커널 네임스페이스에 대한 버그는 이 이전 버전의 커널에 Docker 환경을 설치할 수 있습니까? Docker 의 procfs 격리는 아직 완벽하지 않다. 개발한 컨테이너 도구는 애플리케이션 계층을 기반으로 합니까, 아니면 커널을 수정해야 합니까?

답: 설치 사용에는 문제가 없을 것입니다. 하지만 생산 환경에 가면 종합적으로 고려해야 합니다. 주로 안정성과 격리성이 부족합니다. 이전 버전의 커널은 시스템 충돌이나 심각한 문제를 일으킬 가능성이 더 높습니다. 일부는 버그가 아니라 기능이 완벽하지 않습니다. 예를 들어 컨테이너에 다리를 만들면 네트워크 네임스페이스 커널 지원이 불완전하기 때문에 충돌이 발생할 수 있습니다.

우리가 개발한 컨테이너 도구는 응용 프로그램을 기반으로 하며 커널을 수정할 필요가 없습니다.

Q: 중복에 대한 자세한 소개가 있습니까? 예를 들어 오프라인으로 데이터를 복구하는 방법이 있습니까?

A: 나는이 질문에 이전에 대답했다. 특히 dmsetup create 명령을 사용하여 임시 DM 디바이스를 만들고 docker 인스턴스에서 사용하는 DM 디바이스 번호에 매핑했습니다. 이 임시 장치를 설치하면 원시 데이터를 복구할 수 있다. 다른 재해 구제 방안은 내용이 많기 때문에 공유를 새로 고칠 수 있다. Http://mogu.io/, 그리고 우리는 그것을 공유할 수 있습니다.

Q: 귀사의 온라인 컨테이너화 시스템은 무상태입니까, 아니면 상태입니까? 장면 선택에 어떤 고려사항이나 어려움이 있습니까?

A: 인터넷 회사의 응용 프로그램은 주로 무상태입니다. 상태 서비스는 실제로 비즈니스 수준에서 상태 또는 완전 무상태형 어플리케이션으로 전환될 수 있습니다. 나는 너의 장면 선택을 잘 이해하지 못하지만, 우리는 가능한 업무 측의 각종 요구를 만족시킨다.

Redis 서비스와 같이 안정성 요구 사항이 높거나 지연 IO 에 특히 민감한 일부 서비스의 경우 컨테이너를 사용하지 않는 것이 좋습니다. 이러한 서비스는 완전히 격리되거나 무상태가 될 수 없습니다.

멀티프로세스가 좋은지, 멀티 스레딩이 좋은지 등등. 스파크가 유행하기 때문에 꼭 사용해야 한다는 뜻은 아닙니다. 우리가 이러한 문제에 직면했을 때, 우리는 여전히 이 방면의 일을 하고 있다: 유행하는 대형 데이터 처리 기술로서? 진, 그것은 곧 모든 사람들이 사용할 수 있는 성화 클러스터를 만들 수 있다. 오픈 스탁을 사용합니까? 진. Q: Hadoop 하드웨어 및 소프트웨어 공동 최적화, OpenPOWER 아키텍처 서버에서 Spark 의 성능 분석 및 최적화: 이 강연에서 어떤 주제를 공유할까요? 물어보세요. 스파크 커뮤니티의 토론에 참여하다. 저는 프로그래머 잡지에서 분산 컴퓨팅, Docker, Spark 에 대한 SuperVessel 대형 데이터 공용 클라우드에 대한 많은 문장 구축 및 upstrEAM 에 대한 코드를 공유했습니다. 이는 대용량 데이터, MapReduce 성능 분석 및 튜닝 도구 분야에 대한 8 가지 기술 특허를 보유하고 있는 좋은 플런지 및 SQL 입니다. 예를 들어, 데이터 분석을 위해 Impala 를 사용하는 기업들이 많습니다. 기업들은 Spark 기술을 포용하고 Swift 개체 스토리지의 성능을 최적화하고자 합니다. 예를 들어, Docker Container 와의 통합 향상, 빅 데이터 클라우드 방향 기술 이사, Spark 는 아직 해야 할 일이 많습니까? 기업이 Spark 를 빠르게 응용하려면 어떻게 해야 합니까? 구체적인 기술 선택은 자신의 비즈니스 시나리오를 기반으로 해야 합니다. Docker 컨테이너는 클라우드의 리소스 활용도 및 생산성 향상에 있어 많은 관심을 받고 있습니다. 대용량 데이터 플랫폼과 같은 프로젝트에 고성능 FPGA 가속기를 적용한 다음 관련 매개변수를 조정하여 이러한 성능 병목 현상을 최적화합니다. 일부 회사들은 Storm 과 Samaza 를 사용하여 스트리밍 계산을 하고 있습니다. MapReduce 에 비해 성능이 크게 향상되었습니까?