Yêu cầu về phần cứng cho Open Stack: phần 2 thiết kế mạng

 Trong phần trước của bài viết, chúng ta đã thảo luận một số phương pháp để ước tính số lượng máy chủ và cấu hình (CPU, RAM) cho OpenStack. Trong phần này, sẽ tập trung vào các yêu cầu về kết nối mạng – cách ước tính số lượng NIC (card mạng) cho máy chủ của bạn và throughput(thông lượng) của chúng.

Như chúng ta đã lưu ý, OpenStack có mức tùy biến cao, có nhiều tùy chọn. Điều này cũng giống với cả thiết kế mạng khi triển khai OpenStack. Vì rất khó để bao trùm cho tất cả các kiểu triển khai của OpenStack, nên sẽ tập trung vào việc triển khai networking ở mức phổ biến nhất.

 

1. Logical networks

Một số mạng logic thường được sử dụng trong một cloud OpenStack bao gồm:
– Management network (mạng quản trị): tách biệt băng thông(traffic) quản trị với các băng thông truy cập khác, ví dụ như băng thông được tạo ra bởi các VM và storage.
– Private network(mạng riêng): cung cấp cho dải địa chỉ IP cố định cho VM và cung cấp kết nối giữa các VMs cho một người thuê.
– Public network(mạng dùng chung): cung cấp dải địa chỉ IP tĩnh cho VM và người dùng (công cộng) truy cập tới đám mây trên VM.
– Storage network(mạng lưu trữ): tách băng thông lưu trữ với các băng thông khác.
– Replication network: tách biệt băng thông replication, ví dụ như SWIFT hoặc CEPH với băng thông khác.
– Other network: như mạng tùy chọn riêng cho băng thông của RabbitMQ, hoặc một mạng riêng cho các dịch vụ hỗ trợ HA.
Những mạng logic này nhằm phân chia các loại traffic khác nhau cho khả năng quản lý, hiệu suất và bảo mật.
Điều quan trọng là lập kế hoạch các mạng logic và quá trình triển khai thực hiện, nó sẽ ánh xạ tới các mạng vật lý. Mặc dù có rất nhiều thông số cho quá trình lập kế hoạch mạng, các câu hỏi sau đây là quan trọng nhất:
– Các dịch vụ OpenStack được triển khai trong đám mây của bạn như thế nào?
– Mạng được thực hiện như thế nào trong đám mây OpenStack của bạn?

2. Triển khai mạng cho OpenStack

Có rất nhiều hướng triển khai mạng cho OpenStack nhưng những triển khai phổ biến nhất đều dựa trên Neutron. Neutron là một thành phần mạng lõi của OpenStack. Nó cho phép tạo ra các cấu hình mạng phức tạp và linh hoạt và hỗ trợ cả ảo hóa L2 và L3, cũng như quản lý địa chỉ IP. Ở đây sẽ thảo luận hai hướng triển khai Neutron: Neutron với phân đoạn VLAN (VLAN segmentation) và Neutron với phân đoạn đường hầm thông qua VXLAN hoặc GRE (tuneling segmentation via VXLAN/GRE).

– VLAN segmentation

Với tùy chọn triển khai này, một VLAN được gán cho mỗi người thuê (tenant); ở cách này đám mây OpenStack có thể quản lý đến 4K mạng ảo hoặc 4K tenant, giả sử rằng ứng với một mạng riêng cho mỗi tenant. Hạn chế cách này là phải cấu hình thiết bị mạng hỗ trợ VLAN.

– Tuneling segmentation via VXLAN/GRE

Cả VXLAN segmentation và GRE segmentation được hỗ trợ và băng thông của người thuê được cô lập bằng cách đóng gói(encapsulate) trong đường hầm (tunel). Vì vậy nó có thể xử lý nhiều tenant hơn VLAN segmentation. Ví dụ, VXLAN hỗ trợ lên đến 16M đường hầm. Các mạng con và các mạng con IP khác nhau có thể chồng chéo nhau.
Cấu hình thiết bị mạng đơn giản hơn so với VLAN segmenation. Hạn chế của GRE segmenation là có thêm việc đóng gói GRE nên ảnh hưởng tới cả băng thông và sử dụng CPU, do đó hiệu suất tổng thể của các GRE tunel không tốt bằng VXLAN và VLAN.

3. Triển khai các dịch vụ OpenStack

Để ước lượng số mạng vật lý, số lượng thiết bị chuyển mạch mạng và số NIC cho mỗi máy chủ, sẽ phải xác định mode triển khai OpenStack. Với OpenStack, có nhiều cách để phân phối dịch vụ của mình để đạt được mục tiêu khác nhau. Các mục tiêu này có thể bao gồm các dịch vụ đáp ứng tính sẵn sàng cao và sử dụng tối ưu sử dụng tài nguyên phần cứng.
Nói chung quá trình triển khai được tách biệt giống như một dải phổ, ở một phía hội tụ này là dịch vụ OpenStack có thể chạy trên bất kỳ máy chủ, và mỗi máy chủ phục vụ công việc của người sử dụng và dịch vụ lưu trữ. Với cách tiếp cận như vậy, tất cả các máy chủ cho đám mây OpenStack đều có cùng thiết lập cấu hình (configuration); cụ thể nó cần phải có các NIC cho tất cả các mạng vật lý tồn tại trong đám mây.
Còn phía hội tụ kia, nơi tất cả các dịch vụ OpenStack kiểm soát chạy trên một dedicated node(máy chủ chuyên dụng)còn được gọi là controller node(nút điều khiển). Thông thường, nhiều node điều khiển trong đám mây luôn được thiết lập hướng tới tính sẵn sàng cao. Các loại máy chủ khác như node tính toán (phục vụ công việc của tenant) và các node lưu trữ. Với cách tiếp cận như vậy, các node điều khiển và tính toán phải được kết nối với mạng quản lý và mạng riêng. Các node điều khiển phải được kết nối với mạng công cộng. Các node tính toán và lưu trữ phải được kết nối với mạng lưu trữ.
Giữa hai đầu của dải phổ này, có nhiều sự kết hợp khác của hai phương pháp triển khai người thiết kế phải quyết định nơi đám mây OpenStack ưu tiên mục tiêu nào; cụ thể, làm thế nào phân phối các dịch vụ OpenStack đến các nút phần cứng. Các công cụ triển khai hiện có từ các nhà cung cấp OpenStack khác nhau có thể cung cấp mô hình triển khai tham chiếu đã được chứng minh. Tuy nhiên, ngay cả trong trường hợp này, cũng nên biết lựa chọn hoặc tùy biến, bao gồm:
– Một máy chủ cơ sở dữ liệu OpenStack riêng biệt (hoặc một vài máy chủ cho HA), nếu tổ chức có DBA chuyên nghiệp để chăm sóc nó. Trong trường hợp này, máy chủ cơ sở dữ liệu phải được kết nối với mạng quản lý.
– Nếu có thể muốn phục vụ công việc và dịch vụ lưu trữ của người dùng, ví dụ như Ceph OSD, trên cùng một máy chủ. Điều này sẽ cho phép sử dụng tốt hơn các tài nguyên máy chủ, nhưng đồng thời nó sẽ yêu cầu giới hạn tài nguyên CPU và RAM cho các dịch vụ lưu trữ, vì trong một số trường hợp các dịch vụ như vậy có thể bắt đầu tiêu tốn nhiều tài nguyên hơn mong đợi. Trong cấu hình này, một máy chủ như vậy vẫn nên được kết nối với storage network.
– Bạn có thể xem xét sử dụng một mạng vật lý riêng biệt cho việc theo dõi OpenStack và log. Dịch vụ OpenStack có thể tạo ra log và gửi chúng thông qua management network có thể làm gián đoạn việc quản trị. Ngoài ra, có CPU và RAM, có thể mang lại lợi ích cho điện toán đám mây.
Tùy chọn được đề xuất nhiều nhất cho các nút lưu trữ chuyên dụng (Ceph hoặc Swift) là 2 hoặc 3 NIC trên mỗi máy chủ: NIC đầu tiên dành cho management network, thứ hai là cho storage network. NIC thứ ba là dành cho replication network. Đó là tùy chọn, nhưng được đánh giá cao đối với các đám mây cấp độ cao. Đôi khi, liên kết NIC được sử dụng (xem bên dưới) cho cụm lưu trữ dành riêng để cải thiện thông lượng mạng hoặc tính sẵn sàng.

4. Thiết kế mạng vật lý

Có một số nguyên tắc chung giúp chúng ta hiểu được làm thế nào để lập bản đồ các mạng lưới hợp lý với các mạng vật lý:
Tùy chọn được đề xuất cho mạng quản lý là có một NIC riêng cho từng máy chủ tương ứng và một bộ chuyển mạch mạng riêng biệt. Sự tách biệt như vậy ngăn cản lưu lượng quản trị, chẳng hạn như truy vấn cơ sở dữ liệu, các thông điệp RabbitMQ và các truy vấn quản trị viên đám mây khỏi bị gián đoạn bởi các lưu lượng truy cập khác.
Bởi vì mạng riêng sẽ xử lý tất cả lưu lượng truy cập giữa các máy ảo nên hợp lý khi có một NIC chuyên dụng cho mỗi máy chủ tương ứng và một bộ chuyển mạch mạng chuyên dụng.
Kịch bản sử dụng phổ biến nhất cho mạng công cộng là cung cấp địa chỉ IP công cộng cho một đám mây riêng, nơi có một số địa chỉ IP công cộng có giới hạn. Nếu mạng công cộng cung cấp địa chỉ IP thực, sau đó để bảo mật, mạng công cộng có thể có một NIC riêng cho từng máy chủ tương ứng và một bộ chuyển mạch mạng riêng biệt.
Lưu lượng lưu trữ yêu cầu NIC dành riêng cho nút lưu trữ và tính toán và chuyển đổi mạng riêng biệt.
Một mạng nhân rộng là không bắt buộc và có thể được kết hợp với mạng lưu trữ; tuy nhiên lưu lượng nhân rộng có thể rất rộng vì vậy nên có một NIC riêng cho mỗi nút lưu trữ.
Đối với triển khai nhiều khu vực, bạn có thể cần một mạng lưới quản lý nhiều khu vực riêng biệt ngoài mạng lưới quản lý vùng và một mạng riêng cho sao lưu lưu trữ nhiều khu vực.

5. Bond NIC

Bond NIC là một cách hiệu quả để tăng băng thông có sẵn. Cũng có thể sử dụng phần chuyển đổi dự phòng của NIC bonding để đạt được tính sẵn sàng cao cho mạng đám mây. Nếu bạn quyết định sử dụng bond NIC, sau đó nhân số NIC của 2. Như vậy đối với HA bạn sẽ cần hai lần số lượng các thiết bị chuyển mạch mạng.

6. Tóm lược

Đối với đám mây OpenStack cấp sản xuất, 1-2 NIC trên mỗi máy chủ có thể không đủ, vì bạn sẽ phải sử dụng cùng một mạng vật lý cho một số mạng logic. Quyết định như vậy sẽ có một tác động tiêu cực đến hiệu suất mạng và bảo mật đám mây. Một thỏa hiệp hợp lý là 3 NIC cho mỗi máy chủ cho một số triển khai OpenStack, nhưng nó không đủ linh hoạt về các lựa chọn triển khai có sẵn và khả năng mở rộng. Đối với hầu hết các trường hợp, cấu hình tối ưu là 4 hoặc nhiều hơn NIC trên mỗi máy chủ.
Đối với một số mạng 1Gb là đủ, nhưng 10Gb là tối ưu. 100Gb NIC có thể tốn kém. Fibre Channel cho mạng lưu trữ không nhất thiết là cần thiết nếu bạn sử dụng Ceph như một hệ thống lưu trữ phần mềm phân tán và một mạng 10Gb với liên kết NIC tùy chọn. Đối với kết nối NIC, bạn sẽ cần thêm NIC và thiết bị chuyển mạch mạng. 

Các yêu cầu về phần cứng OpenStack

 Phần 1: Máy chủ, CPU và RAM

Việc xác định yêu cầu phần cứng cho đám mây OpenStack không phải đơn giản; quá trình phức tạp này bởi khối lượng công việc (workload) và yêu cầu về tính sẵn sàng (availability requirements) của đám mây. Cùng thời điểm, nhiều chủng loại phần cứng sẵn có trên thị trường làm thậm chí còn đem lại nhiều thách thức để lựa chọn phù hợp với yêu cầu của đám mây theo tùy chọn cụ thể.
Trong phần đầu của bài này, sẽ xác định một số nguyên tắc cơ bản để cho phép xác định ưu tiên và xác định CPU, số lượng máy chủ và yêu cầu bộ nhớ cho đám mây build trên OpenStack. Trong phần thứ hai, sẽ tập trung vào các yêu cầu về lưu trữ phần cứng và mạng.

1. Các nút tính toán (Compute nodes)

Trong OpenStack, máy ảo (VM – virtual machine) của người dùng chạy trên các compute node (nút tính toán), các máy chủ hypervisor được quản lý bởi OpenStack. Để lựa chọn đúng số lượng và cấu hình của các nút đó, nói chung, cần chuyển các yêu cầu về khối lượng công việc tương ứng các công suất, về CPU, mạng bộ nhớ và lưu trữ.

1.1. Yêu cầu về CPU

Hầu hết các CPU(trong bối cảnh bài viết này CPU tương ứng với khái niệm chip vật lý) hiện đại đều hỗ trợ ảo hóa phần cứng (công nghệ AMD-V cung cấp bởi AMD, công nghệ VT-x do Intel cung cấp). Kiến trúc CPU phổ biến nhất cho đám mây OpenStack là x86-64.
Tính năng Hyper-Threading (siêu phân luồng) của Intel cải thiện xử lý song song, ví dụ như một CPU 12 nhân với Hyper-Threading có hiệu năng giống như CPU lõi 15-24, tùy thuộc vào khối lượng công việc.
Để xác định số lượng máy chủ, số lượng socket(chip) trên mỗi máy chủ và số core trên mỗi chip, cần có các yêu cầu cho khối lượng công việc của đám mây. Thông thường, cần một số máy ảo, một số VCPU trên mỗi VM và hiệu suất trung bình dự kiến của mỗi VCPU. Ví dụ, có thể tính toán tổng số lõi CPU cần:
Cores = VMs / HT / CO
Trong đó:
Cores – tổng số lõi CPU cần
VMs – tổng số máy ảo cần chạy
HT – hệ số Hyper-Threading. HT bằng 1,3 nếu CPU hỗ trợ Hyper-Threading, và bằng 1 nếu không hỗ trợ.
CO – hệ số quá tải của CPU (1 cho không oversubscription)
Số lượng socket CPU:
Sockets = Cores / Cores_Per_Socket
Trong đó:
Sockets – số socket CPU cần
Cores – tổng socket CPU cần
Cores_Per_Socket – số lõi trên mỗi socket
Cuối cùng, số lượng server cần là:
Servers = Sockets / Sockets_Per_Server
Trong đó Sockets_Per_Server là số lượng Socket trên mỗi Server
Ví dụ:
– OpenStack sẽ cần ảo hóa 100 VM: VMs = 100
– Không sử dụng Hyper-Threading: HT = 1
– Với cách sử dụng CPU oversubscription bằng 2, có nghĩa là trung bình sử dụng một lõi CPU (ví dụ, 2.4GHz) cho 2 VCPUs: CO = 2
– Số lượng CPU Core cần là: Cores = 100/1/2 = 50
– Nếu dự định dùng các chip 8 core: Cores_Per_Socket = 8
– Số lượng chip cần dùng là (lấy phần nguyên trên): Sockets = 50/7 = 8
– Nếu máy chủ cần dùng chỉ cắm được tối đa 2 chip (mainboard chỉ có 2 cpu socket). Vậy số máy chủ cần dùng là: Servers = 8/2 = 4
Do đó, để chạy 100 máy ảo với 2 CPU ảo, không có Hyper-Threading và CPU oversubscription, sẽ cần 4 máy chủ cho các compute node. Mỗi máy chủ sẽ có 2 socket để cắm CPU và 8 lõi CPU 2.4GHz trên mỗi chip.
Chú ý:
Nếu đã có một số loại máy ảo, hãy tính toán tổng số core CPU mỗi loại, sau đó tổng hợp chúng.
Đối với các máy chủ có NUMA, cần cẩn thận về CPU và bộ nhớ để đảm bảo rằng mỗi VM tiêu tốn CPU và bộ nhớ từ cùng một nút NUMA, nếu không hiệu suất của VM sẽ bị giảm xuống.

1.2. Yêu cầu về RAM

Các công thức sau để tính toán bộ nhớ cần thiết cho compute node:
VMs_Per_Server = VMs / Servers
RAM = RAM_Per_VM * VMs_Per_Server / MO + OS_RAM
Trong đó:
VMs – tổng số máy ảo cần chạy
Servers – số máy chủ cần
VMs_Per_Server – số máy ảo được tính trên mỗi máy chủ
RAM_Per_VM – RAM cho mỗi VM
MO – hệ số oversubscription RAM (1 nếu không có oversubscription)
OS_RAM – RAM yêu cầu cho hệ điều hành và hypervisor
Lưu ý, rằng hypervisor cũng có thể sử dụng bộ nhớ hệ thống cho các caches ổ đĩa. Khối lượng RAM cần thiết để lưu trữ cho tất cả các máy ảo là khó ước tính: nó phụ thuộc vào số lượng VM trên máy chủ host, số lượng đĩa cho mỗi máy ảo và loại bộ nhớ cache cho mỗi đĩa.
Ví dụ:
– Cần ảo hóa 100 áy ảo: VMs = 100
– Mỗi máy ảo giả sử cần 4 GB RAM: RAM_Per_VM = 4
– Với ví dụ ở trên dùng 4 máy chủ: Servers = 4
– Số máy ảo được ảo hóa trên mỗi server là: VMs_Per_Server = 100/4 = 25
– RAM không oversubscription nên: MO = 1
– Giả sử đáp ứng mỗi máy chủ RAM cho hệ điều hành là 16 GB: OS_RAM = 16
– Vậy RAM trên mỗi máy chủ tối thiểu là: 4*25 + 16 = 116
Vì vậy, để chạy 100 máy ảo với mỗi ổ cứng 4GB, không có RAM quá tải và ổ đĩa, vậy sẽ cần đến 116GB RAM trên mỗi compute node.
Để giảm lượng RAM vật lý cần thiết để chạy các máy ảo, có thể sử dụng kỹ thuật de-deduplication. Ví dụ, Transparent Page Sharing (TPS) cho Xen và Kernel Samepage Merging (KSM) cho KVM (xem thêm KVM Hypervisor: Quản lý bộ nhớ quá mức cam kết).

2. Các node khác

Một khi các yêu cầu cho các compute node được xác định, đã đến lúc suy nghĩ về các máy chủ cho các dịch vụ OpenStack và có node khác có thể cần cho đám mây OpenStack, chẳng hạn như các node lưu trữ riêng biệt. Nói chung, có hai tham số cho các dịch vụ OpenStack có liên quan đến việc lập kế hoạch phần cứng:
– Có bao nhiêu dịch vụ sẽ được triển khai dự phòng (dự phòng dịch vụ)
– Các dịch vụ sẽ được triển khai ở đâu(deployment mode)

3. Dịch vụ dự phòng

Đối với dấu chân đám mây lớn, sẽ cần nhiều trường hợp dịch vụ và cũng để cân bằng tải cho các dịch vụ. Ngoài ra nên cần nhiều hơn một hệ thống dự phòng cho mỗi dịch vụ để bảo đảm tính sẵn sàng cao.

4. Mode triển khai

Segregated services mode: giả sử rằng có các node vật lý cho các dịch vụ OpenStack và mỗi node chứa tất cả các dịch vụ được yêu cầu. Chế độ này là đơn giản nhất để triển khai và quản trị. Tuy nhiên như vậy có thể không được tối ưu.
Converged services mode: giả sử rằng các dịch vụ OpenStack được triển khai trên các nút hiện có. Có thể, như là một trường hợp cực đoan, mỗi nút trong đám mây có thể chứa tất cả các dịch vụ OpenStack yêu cầu ngoài khối lượng công việc đang chạy. Chế độ này không cần thiết phải có máy chủ riêng, nhưng các nút đám mây nên có thêm tài nguyên CPU và RAM để chạy các dịch vụ OpenStack. Các nguồn lực cho khối lượng công việc và cho các dịch vụ kiểm soát phải được cách ly một cách hợp lý để tránh tình trạng xuống cấp. Không cần phải nói, chế độ này khó triển khai và quản trị hơn segregate service mode
Tài nguyên phần cứng bắt buộc cho các dịch vụ riêng biệt phụ thuộc vào nhiều tham số, bao gồm:
– Số lượng các thể hiện dịch vụ đang chạy trong đám mây và trên nút cụ thể
– Các dịch vụ khác đang chạy trên cùng một nút
– Số nút tính toán
– Làm thế nào các đám mây sẽ được sử dụng
Ở đây, chúng tôi sẽ đưa ra các khuyến cáo phổ biến cho các dịch vụ cụ thể.
Hệ điều hành
Số lượng bộ nhớ, không gian đĩa và các tài nguyên cần thiết đều phụ thuộc vào hệ điều hành và dịch vụ hệ thống đang chạy trên node. Nói chung, nên sử dụng ít nhất 2 lõi CPU và 16 GB RAM cho hệ điều hành, dịch vụ hệ thống và tập tin lưu trữ.
RabbitMQ
RabbitMQ yêu cầu ít nhất 128MB bộ nhớ RAM và theo mặc định sẽ sử dụng tối đa 40% RAM có sẵn (available RAM). Với chế độ Segregated services mode, cần phải xác định bao nhiêu bộ nhớ sẽ dành cho RabbitMQ. Theo mặc định, RabbitMQ yêu cầu 50MB không gian đĩa trống (free disk space) mọi thời điểm và nên sử dụng ít nhất 2GB dung lượng đĩa trống. Càng nhiều consumer và queue càng cần hỗ trợ thêm bộ nhớ và không gian đĩa để dự trữ cho RabbitMQ.
MySQL với Galera
Mỗi node Galera cần ít nhất 1GHz CPU và 512MB RAM. Đối với các đám mây cấp độ chuyên dụng, sẽ cần ít nhất 2 lõi CPU và RAM 4-8 GB.
Các dịch vụ OpenStack
Tùy thuộc vào dịch vụ, có thể cần 0.5-2 core CPU và RAM 2-4GB cho mỗi dịch vụ.
Để tính đơn giản, hãy sử dụng segregated services mode. Trong trường hợp này, nên sử dụng cấu hình sau:
– Một số lẻ (ít nhất 3) các máy chủ phần cứng vật lý (dedicated server).
– Mỗi máy chủ phải có ít nhất 2 socket CPU với 6 lõi CPU (x86-64) cho mỗi socket
– Mỗi máy chủ phải có ít nhất 64GB RAM
Cấu hình này cho phép một đám mây OpenStack với hơn 1000 máy ảo. Lưu ý rằng, có thể thêm các compute node mới khi đám mây phát triển. Ngoài ra, với kiến trúc HA, có thể bắt đầu với một controller node nhỏ (2 lõi CPU, 2-4 GB RAM), nó không sẵn sàng cao, nhưng tất cả các dịch vụ đều có chứa “HA-ready”, cho phép thêm các controller node mà không có thời gian chết (downtime).

5. Các node khác có thể bổ sung

Xem xét rằng bổ sung các node sau đây trong một số trường hợp đối:
– Tùy chọn node director / master để lưu trữ master configuration
– Tùy chọn tách các node Database (3 cho HA configuration)
– Tùy chọn tách các node monitoring (3 cho HA configuration)
– Tùy chọn tách các node lưu trữ log tập trung (3 cho cấu hình HA)

Trích từ https://inseclab.uit.edu.vn/

Nguồn dịch: https://www.stratoscale.com/blog/openstack/openstack-hardware-requirements-and-capacity-planning-servers-cpu-and-ram-part-1/

Thông tin về bảo vệ sức khỏe lãnh đạo Đảng, nhà nước là bí mật

✅ Thông tin về bảo vệ sức khỏe lãnh đạo Đảng, nhà nước là bí mật

Ngoài các thông tin để phục vụ quốc phòng, an ninh thì thông tin bảo vệ sức khỏe lãnh đạo cấp cao của Đảng, nhà nước cũng thuộc diện phạm vi bí mật nhà nước theo Luật Bảo vệ bí mật nhà nước được QH thông qua chiều 15-11.

Chiều 15-11, với 91,55% đại biểu (ĐB) có mặt biểu quyết tán thành, Quốc hội (QH) đã thông qua Luật Bảo vệ bí mật nhà nước với 5 chương, 28 điều, và có hiệu lực từ 1-7-2020. Theo đó, phạm vi bí mật nhà nước là giới hạn thông tin quan trọng trong các lĩnh vực chưa công khai; nếu bị lộ, bị mất có thể gây nguy hại đến lợi ích quốc gia, dân tộc.

✅ Sức khỏe lãnh đạo Đảng, nhà nước là bí mật

Căn cứ tính chất quan trọng của nội dung thông tin, mức độ nguy hại nếu bị lộ, bị mất, bí mật nhà nước được phân loại thành 3 độ mật: Tuyệt mật, tối mật và mật. Luật quy định các thông tin thuộc phạm vi bí mật nhà nước như: Thông tin về chủ trương, chính sách của Đảng và nhà nước về đối nội, đối ngoại; hoạt động của Ban Chấp hành Trung ương, Bộ Chính trị, Ban Bí thư và lãnh đạo Đảng, nhà nước. Ngoài ra, chiến lược, kế hoạch, đề án phát triển báo chí, xuất bản, in, phát hành, bưu chính, viễn thông và internet, tần số vô tuyến điện, công nghệ thông tin, an toàn thông tin mạng… để phục vụ quốc phòng, an ninh cũng thuộc diện bí mật. Luật cũng quy định thông tin bảo vệ sức khỏe lãnh đạo cấp cao của Đảng, nhà nước thuộc diện phạm vi bí mật nhà nước.

✅ Luật Bảo vệ bí mật nhà nước

Luật Bảo vệ bí mật nhà nước cấm hành vi làm lộ, chiếm đoạt, mua, bán bí mật nhà nước; làm sai lệch, hư hỏng, mất tài liệu, vật chứa bí mật nhà nước; mang tài liệu, vật chứa bí mật nhà nước ra khỏi nơi lưu giữ trái pháp luật; truyền đưa bí mật nhà nước trên phương tiện thông tin, viễn thông trái với quy định của pháp luật về cơ yếu; đăng tải, phát tán bí mật nhà nước trên phương tiện thông tin đại chúng, mạng internet, mạng máy tính và mạng viễn thông...

Tạo bản máy Android trên EVE-NG

Để tạo được máy tính hệ điều hành Android trên EVE-NG làm theo các bước sau:
1. Tải bản ảnh Android đã cài đặt từ địa chỉ https://www.osboxes.org/android-x86/
2. Convert từ định dạng vmdk hoặc vdi sang qcow2 theo lệnh:


3. Tạo thư mục tương ứng với máy ảo trong thư mục /opt/unetlab/addons/qemu, ví dụ /opt/unetlab/addons/qemu/android-4.2R2

4. Tạo file template vào địa chỉ theo mẫu file tải tại địa chỉ https://drive.google.com/open?id=123aiq-r-l3gdFZYNU2AEX89WaclzkAJI

EVE-NG Toolkit – Script Tuyệt Vời Cho EVE-NG

Các tính năng

Ps: chức năng p. Eve-ng Pro evaluation* là kích hoạt EVE-NG Pro miễn phí

Cách cài đặt

• • Download Files nén bên dưới về giải nén ra
  • Dùng WinSCP,… copy files vào /usr/share/eve-ng-toolkit của EVE-NG
  • Sau đó vào chạy lần lượt các lệnh sau

    cd /usr/share/eve-ng-toolkit/
    

    Lệnh này chuyển đến thư mục eve-ng-toolkit
  • Chạy tiếp lệnh

    chmod +x eve-ng-toolkit

•         Lệnh trên cấp quyền execute (thực thi cho files bash)
• Sau đó các bạn có thể chạy bash script bằng lệnh

  ./eve-ng-toolkit

  hoặc

  sh eve-ng-toolkit

• Sau đó menu sẽ hiện lên và tuỳ chọn chức năng cần thiết

Link Download

https://drive.google.com/file/d/1x9SvqZo5jYg7awE6nYQYo2k-_pgbXTqL/view?usp=sharing

Cài đặt cacti 1.2.11 và Spine 1.2.11 trên Ubuntu 18.04

Cài đặt các gói cần thiết

Update Ubuntu

sudo apt update

Cài đặt Apache & MariaDB

sudo apt install -y apache2 mariadb-server mariadb-client php-mysql libapache2-mod-php

Cài đặt PHP Extensions

sudo apt install -y php-xml php-ldap php-mbstring php-gd php-gmp

Cài đặt SNMP và RRDtool

sudo apt install -y snmp php-snmp rrdtool librrds-perl

Chỉnh sửa cấu hình cơ sở dữ liệu

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

Thêm và chỉnh sửa những cài đăt sau vào khu vực [mysqld]

collation-server = utf8mb4_unicode_ci
max_heap_table_size = 240M
tmp_table_size = 128M
join_buffer_size = 128M
innodb_file_format = Barracuda
innodb_large_prefix = 1
innodb_buffer_pool_size = 1000M
innodb_flush_log_at_timeout = 3
innodb_read_io_threads = 32
innodb_write_io_threads = 16
innodb_io_capacity = 5000
innodb_io_capacity_max = 10000

Cài đặt múi giờ

Múi giờ hệ thống

sudo dpkg-reconfigure tzdata

Múi giờ trong PHP

sudo nano /etc/php/7.2/apache2/php.ini

Tìm đến dòng ;date.timezone =   (dòng 936)

Bỏ dấu ;   và thêm giá trị timezone :

date.timezone = Asia/Ho_Chi_Minh 

Tìm đến 2 dòng và thay đổi giá trị thành 

max_execution_time = 300   (dòng 380)

memory_limit = 500M          (dòng 401)

sudo nano /etc/php/7.2/cli/php.ini

Tìm đến dòng ;date.timezone =   (dòng 936)

Bỏ dấu   ;   và thêm giá trị timezone :

date.timezone = Asia/Ho_Chi_Minh

Khởi động lại dịch vụ MariaDB

sudo systemctl restart mariadb

Tạo cơ sở dữ liệu

sudo mysql -u root -p

create database cacti;

GRANT ALL ON cacti.* TO cactiuser@localhost IDENTIFIED BY 'cacti';
flush privileges;
exit

sudo mysql -u root -p mysql < /usr/share/mysql/mysql_test_data_timezone.sql

sudo mysql -u root -p

GRANT SELECT ON mysql.time_zone_name TO cactiuser@localhost;
flush privileges;
exit

Cài đặt Cacti 

Tải xuống phiên bản mới nhất

wget https://www.cacti.net/downloads/cacti-latest.tar.gz

Giải nén và chuyển vào thư mục /opt

tar -zxvf cacti-latest.tar.gz

sudo mv cacti-1* /opt/cacti

Nhập dữ liệu cơ sở dữ liệu Cacti mặc định vào cơ sở dữ liệu Cacti

sudo mysql -u root -p cacti < /opt/cacti/cacti.sql

Chỉnh sửa tệp cấu hình Cacti

sudo nano /opt/cacti/include/config.php

Thực hiện các thay đổi cho phù hợp

/* make sure these values reflect your actual database/host/user/password */
$database_type = "mysql";
$database_default = "cacti";
$database_hostname = "localhost";
$database_username = "cactiuser";
$database_password = "cacti";
$database_port = "3306";
$database_ssl = false;

Sửa lỗi Login trong phiên bản Cacti 1.2.11

Coment dòng $cacti_cookie_domain = 'cacti'; 

=> //$cacti_cookie_domain = 'cacti.net'; 

Chỉnh sửa tập tin crontab

sudo nano /etc/crontab

Thêm mục sau vào crontab để Cacti có thể thăm dò cứ sau 1 phút.

*/1 * * * * www-data php /opt/cacti/poller.php > /dev/null 2>&1

Chỉnh sửa tệp cấu hình Apache

sudo nano /etc/apache2/sites-available/cacti.conf

Sử dụng cấu hình sau

Alias /cacti /opt/cacti

  <Directory /opt/cacti>
      Options +FollowSymLinks
      AllowOverride None
      <IfVersion >= 2.3>
      Require all granted
      </IfVersion>
      <IfVersion < 2.3>
      Order Allow,Deny
      Allow from all
      </IfVersion>

   AddType application/x-httpd-php .php

<IfModule mod_php.c>
      php_flag magic_quotes_gpc Off
      php_flag short_open_tag On
      php_flag register_globals Off
      php_flag register_argc_argv On
      php_flag track_vars On
      # this setting is necessary for some locales
      php_value mbstring.func_overload 0
      php_value include_path .
 </IfModule>

  DirectoryIndex index.php
</Directory>

Đồng thời thêm cấu hình trên vào file cấu hình apache2

sudo nano /etc/apache2/apache2.conf

Kích hoạt máy chủ ảo đã tạo.

sudo a2ensite cacti

Restart Apache services.

sudo systemctl restart apache2

Tạo một tệp nhật ký và cho phép người dùng Apache (dữ liệu www) ghi dữ liệu vào thư mục Cacti.

sudo touch /opt/cacti/log/cacti.log 

sudo chown -R www-data:www-data /opt/cacti/

Cài đặt Spine

Cài đặt các gói cần thiết

sudo apt install -y build-essential dos2unix dh-autoreconf help2man libssl-dev libmysql++-dev  librrds-perl libsnmp-dev libmysqlclient-dev libmysqld-dev

Tải về Spine phiên bản mới nhất 

sudo wget http://www.cacti.net/downloads/spine/cacti-spine-latest.tar.gz

Giải nén file vừa tải và truy cập vào thư mục đã giả nén

sudo tar -xvf cacti-spine-latest.tar.gz

ver=$(tar -tf cacti-spine-latest.tar.gz | head -n1 | tr -d /)

cd /$ver/

Thực hiện cài đặt spine

./bootstrap 
./configure 
sudo make
sudo make install

sudo chown root:root /usr/local/spine/bin/spine 
sudo chmod +s /usr/local/spine/bin/spine

Chỉnh sửa file cấu hình spine

sudo nano /usr/local/spine/etc/spine.conf.dist

Chỉ sửa theo nội dung sau

DB_Host localhost
DB_Database cactidb
DB_User cactiuser
DB_Pass cacti
DB_Port 3306

Cài đặt Cacti trên Web interface

Truy cập http: //your.ip.add.ress/cacti  (vd : http: //192.168.1.10/cacti)

Đăng nhập vào Cacti để thiết lập cài đặt Cacti.

Tên đăng nhập: admin

Mật khẩu: admin

Sau khi quá trình hoàn tất vào configuration>settings>paths

Thêm /usr/local/spine/etc/spine.conf.dist vào Spine Config File Path  và lưu lại

vào configuration>settings>poller chỉ sửa Poller Type thành spine và lưu lại

Quá trình cài đặt hoàn tất !