Tối ưu hiệu năng đáp ứng các yêu cầu của hệ thống 4G core
•Transferir como PPTX, PDF•
0 gostou•750 visualizações
Tối ưu hiệu năng đáp ứng các yêu cầu của hệ thống 4G core
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Tối ưu hiệu năng đáp ứng các yêu cầu của hệ thống 4G core
Semelhante a Tối ưu hiệu năng đáp ứng các yêu cầu của hệ thống 4G core (20)
Mais de Vietnam Open Infrastructure User Group
Mais de Vietnam Open Infrastructure User Group (20)
Último
Último (20)
Tối ưu hiệu năng đáp ứng các yêu cầu của hệ thống 4G core
- 1. Cloud for 4G Core 4G Core Introduction1 Performance Problems2 Next Plan3
- 3. 4G Core Network & NFV
- 4. OCS Requirement Average Latency < 2ms 200.000 Request per seconds 80M customers Hardware cost < 0.1$ /sub Uptime 99.999%
- 5. EPC Requirement Avarage Latency < 2ms >100k Request per seconds 1-2M customers Throughput: 300Gbs Offline tracing
- 6. Objective Cloud design Optimization & Simulation • VM design. • VN network Design • Compute. • Network. • Storage. • Software INPUT Bare metal design Requirements OUTPUT Number VM VM flavor & configuration VN configuration
- 7. Openstack for 4g core • Openstack: Queens • Hypervisor: KVM • Network: OpenvSwitch • Storage: CEPH • Hardware: x86_64 • OS: Redhat
- 8. 2.Performance Issues • Compute processing - CPU - Memory • Packet processing - Throughtput - Latency
- 9. Compute resources • High rate cpu usage - High cpu by workload(VM > Host 15%) • Competing for cpu resources - CPU Steal Time (%st)
- 10. Solution • CPU pinning: VM pinned to dedicated CPU cores - Numa - Hyperthreads - Hugepages
- 11. NUMA • NUMA awareness Scheduling - Non-Uniform Memory Access - Each CPU has it own memory(fast) - Other memory can accessed indirectly(slower)
- 12. HyperThreads • Hyper Threading • CPU Caching
- 13. Hugepages • Hugepages: - Allocate by NUMA - No swapping
- 14. Conclusion • Result: ~ 95% physical • Advantages: - Isolate VM resources - Optimal using resources% • Disadvantages: - Expensive - Inflexiable
- 15. Network Issues • Latency - Controller plane apps • Throughput - Data plane apps • Quality - Packet loss
- 16. OpenvSwitch • Multilayer virtual switch • Feature: VLAN, STP, LACP, Mirroring, Flow, Tunnel, QoS
- 17. OpenvSwitch Datapath • Datapath is the forwarding plane of OVS. - System datapath(default) - Userspace datapath(netdev-dpdk)
- 18. DPDK(Data Plane Development Kit) • DPDK: accelerate packet processing workloads running on a wide variety of CPU architectures EAL: Environment Abstraction Managing Queues: rte_ring Memory Management: rte_mempool Buffer Management: rte_mbuf Other Libraries
- 19. OVS-DPDK • Benefit: - Bypass kernel - Batch packets handling - …
- 20. OVS-DPDK • Additional: - Vhostuser - PMD Driver - PMD Thread - …
- 21. PMD Thread performance • PMD Threads: - Multi PMD threads - CPU pinning (Poll mode) - Use vhostuser multi queue Packet size 64 Physical NIC 10GB PMDs 4 Physical 15Mpps VM(Linux socket) 200Kpps Latency https://software.intel.com/content/www/us/en/develop/articles/configure-vhost-user-multiqueue-for-ovs-with- dpdk.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ISNMain+%28Intel+Developer+Zone+Articles+Feed%29
- 22. Packet loss • Issue: - Packets loss while PMD threads low usage rate - VM process packet not fast enough • Solutions: - Increase tx/rx queues size - Using DPDK app in VM
- 23. Dataplane throughput • EPC throughput: 36Gbs/VM • OVS-DPDK: - Throughput not enough - Too many resources for OVS • Solution: - PCI Passthrough ??? - SR-IOV
- 24. SRIOV for Data plane • Physical Function • Virtual Function: - “lightweight” PCI Advantages: - Optimal resources - Minimize overhead, bottlenecks - DMA to VM memory http://www.intel.com/content/dam/doc/application-note/pci-sig-sr-iov-primer-sr-iov-technology-paper.pdf
- 25. PCI Locality Mapping • PCI map to NUMA • VM map to NUMA PCI and VM in same NUMA is better
- 26. 3. Plan OVS-DPDK Offload Smart NIC. SDN. Cloud for 5G. Container.
- 27. Thankyou!
Notas do Editor
- Hiệu năng của hệ thống bị ảnh hưởng bới: Compute Network Storage
- Tỉ lệ sử dụng cpu cao: Với cùng ứng dụng và workload, ứng dụng chạy trên VM sử dụng nhiều cpu hơn so với trên vật lí (Khoảng 15 %) Chia sẻ tài nguyên: Steal Time: là phần trăm thời gian CPU ảo chờ CPU thực trong khi bộ ảo hóa đang phục vụ bộ xử lý ảo khác. Khi có nhiều VM cùng chạy trên 1 host steal time tang cao Mức quan trọng của ứng dụng + tồn queue chất lượng dịch vụ (Ví dụ media) Mặc định KVM gom cpu trên server về vCPU Pool tranh chấp cpu + Không tối ưu cpu cache do quá trình lập lịch trên CPU pool
- Cô lập các CPU vật lý cho một máy ảo cụ thể. Mỗi máy ảo sẽ được chỉ định một danh sách các CPU vật lý khác nhau -> tránh tranh chấp tài nguyên trong quá trình xử lý. Ứng dụng trên các máy ảo sẽ không phải tương tranh vCPU của các máy ảo khác, thời gian xử lý bản tin sẽ được rút ngắn. Bố trí các CPU vật lý + Memory cho máy ảo dựa vào kiến trúc NUMA của hệ thống.
- NUMA (Truy cập bộ nhớ không đồng nhất) chia bộ nhớ thành nhiều ô bộ nhớ, là "cục bộ" cho một hoặc nhiều CPU. Các nút NUMA được kết nối với nhau, vì vậy tất cả các CPU vẫn có thể truy cập tất cả bộ nhớ nhưng CPU truy cập bộ nhớ cục bộ nhanh hơn. Do đó, khi thiết kế máy ảo, cần thiết phải sử dụng CPU và RAM cùng 1 NUMA cho 1 máy ảo để đảm bảo hiệu năng cao nhất.
- Hyper Threading chia Core vật lí thành các luồng xử lý khác nhau. Một CPU vật lý khi hoạt động trên hệ điều hành được hiểu như là hai CPU(Threads). Nếu 2 thread nằm trên 2 VM khác nhau --> ảnh hưởng lẫn nhau 2 thread khoảng 140% 2 threads thuộc cùng 1 VM Ứng dụng hoạt động với hyper thread như với trên Host
- Hugepage làm tăng khả năng truy xuất cache TLB do giảm đáng kể dữ liệu bảng TLB. Mỗi máy ảo được cấp một số lượng hugepage cụ thể, và không bị tương tranh giữa các máy ảo sẽ làm tăng tốc quá trình truy xuất bộ nhớ của ứng dụng, giúp ứng dụng xử lý nhanh hơn. Hugepage được cấp phát cùng NUMA với cpu của VM nên đạt được tốc độ truy xuất nhanh hơn Sử dụng Hugepage cũng làm điều kiện tích hợp với giải pháp network về sau
- Kết quả: Các VM được đặt trên các NUMA với tài nguyên độc lập Ưu điểm: Tránh được tranh chấp giữa các VM (CPU, Memory) Tối ưu được tốc độ Nhược điểm: Tốn kém(Không sử dụng đc over commit) Thiếu linh hoạt (yêu cầu phần cứng, os hỗ trợ; Live migrate) NOTE: Chia ứng dụng theo VM, cấu hình theo VM. Bám vào design vócs Ke
- Latency: Các hệ thống controlle plane yêu cầu latency thấp. Vd trên OCS < 3 ms network yêu cầu < 1ms Throughput: Dataplan yêu cầu hàng chục Gbs cho mỗi VM Tỉ lệ loss phải rất thấp. Success > 99.99%
- OpenvSwitch (OVS) là một opensource về chuyển mạch ảo đa lớp (multilayer). mã nguồn mở hỗ trợ giao thức OpenFlow Mục đích chính của OpenvSwitch là cung cấp lớp chuyển mạch cho môi trường ảo hóa phần cứng, hỗ trợ nhiều giao thức và tiêu chuẩn được sử dụng trong hệ thống chuyển mạch thông thường. OpenvSwitch hỗ trợ nhiều công nghệ ảo hóa dựa trên nền tảng Linux như Xen/XenServer, KVM, và VirtualBox.
- System datapath: Datapath mặc định của ovs, sử dụng linux network stack Với kernel datapath: VD1: Quá trình forwarding phải đi qua đầy đủ các bước của linux network như Switch context, netfileter, … VD2: Gửi bản tin từ userspace qua kernel space sủ dụng Interrupt của OS dẫn đến luôn có trễ Để giải quyết bài toán trên, sử dụng Userspace datapath: Quá trình xử lí và chuyển tiếp bản tin thực hiện trong userspace. Giải pháp phổ biến là sử dụng DPDK
- Trong một số trường hợp, hiệu năng network của Linux Network stack là không đủ đáp ứng, kể cả khi sử dụng các card 10G. Vì các botlecknet xuất hiện trong chính Kernel của Linux. DPDK là tập hợp các thư viện với mục đích tăng tốc độ xử lí gói tin trên các nền tảng CPU khác nhau. Khi một card mạng lần đầu tiên nhận được một gói -> hàng đợi nhận (RX) -> sao chép vào bộ nhớ chính thông qua cơ chế DMA (Truy cập bộ nhớ trực tiếp).-> Linux tạo ngắt -> CPU chuyển gói đến userspace. - > Càng nhiều gói càng ảnh hưởng hiệu năng Cơ chế mới: Ngắt kết hợp pull (Ngắt vs bản tin đầu, poll đến khi hết buffer) DPDK: tx --PMD--> Ring buffer --> App Đa phần các ứng dụng dataplan đang sử dụng DPDK
- DPDK vhost-user: là interface với vNIC. Có thể coi vNIC gồm 2 phần backend và frontend, trong đó vhost-user chính là backend, còn virtio trên VM là frontend. DPDK PMD driver: là interface với pNIC. PMD: là các worker thực hiện switching. PMD sử dụng các API do DPDK cung cấp để điều khiển vhost-user và PMD driver. PMD sử dụng các lớp cache (EMC, megaflow) để improve hiệu năng switching.
- Để nâng cao năng lực xử lí của PMD thread: Multi thread: Tối thiểu 1 thread cho 1 numa. Tăng thread khi số port tang Mỗi thread 1 cpu chạy poll mode. Hiệu năng tốt nhất khi các cpu thuộc các core khác nhau, ko sibling Sử dụng hugepage cho vm và vswitch Mặc định, vhostuser sử dụng 1 queue txrx bottleneck, sử dụng multiqueue có thể giải quyết vấn đề này
- Với 250kpps, PMD < 5% cpu Khi tắt App đi, tốc độ xử lí tăng lên Queue size mặc định là 256, hỗ trợ max 1024. Queue size tăng thì throughtput tăng, latency tang và ngược lại. Dequeue zerocopy là tính năng thử nghiệm
- Dataplane yêu cầu throughput xử lý rất lớn, ovs-dpdk ko đáp ứng được hoặc phải sử dụng nhiều tài nguyên Giải pháp: PCI Passthrough: Tốn kém, thiếu linh hoạt SR-IOV: Linh hoạt, hỗ trợ sẵn trong Openstack
- SR-IOV là kỹ thuật mà cho phép một thiết bị PCI chia thành nhiều thiết bị riêng biệt gồm có Physical Function (PF) và một hoặc nhiều Virtual Function (VF). Các VF chỉ tập tập trung vào việc truyển tải dữ liệu. Cần lưu ý là tổng bandwidth sẵn có với PF được chia sẻ cho tất cả các VF. SR-IOV yêu cầu sự hỗ trợ từ BIOS , OS hay Hypervisor và phần cứng. Danh sách OS hỗ trợ: Windows Server 2008 and later, Linux* 2.6.30 kernel or later, Red Hat Enterprise Linux 6.0* and later, SUSE Linux Enterprise Server 11* SP1 and later Danh sách Hypervisor hỗ trợ: Microsoft Hyper-V*, VMware Sphere* 5.1, Xen Hypervisor*, KVM* Lý thuyết max 256 VF. Hiện tại 64 VFs được xem là giới hạn cho hầu hết các PCIe device.