[OpenCPS-BKT] OpenCPS v2

[Ta Tuan Anh]

Hi Hiếu và các bạn,

Vì hiện nay OpenCPS đang đề xuất nội dung để làm trong 18 tháng nên về 
mặt nguyên tắc mọi chi tiết quyết định làm theo hướng nào sẽ phải đưa ra 
trong qúa trình thực hiện. Tại thời điểm này chúng ta chỉ phải vạch ra 
những phương án kĩ thuật có thể quan tâm để thực hiện. Do vậy các đề 
xuất phương án khác nhau của Hiếu cứ viết đầy đủ vào mà chưa cần quyết 
định vội.

Quan trọng vẫn là đưa ra được các tiêu chí kĩ thuật cần đạt được khi kết 
thúc nhiệm vụ. Tuy nhiên các tiêu chí chỉ nên đặt ở mức trung bình, vì 
nếu cao qúa thì có thể gặp khó khăn mà ta không thể thực hiện. Kể cả các 
tiêu chí về SLA cũng là do chúng ta tự đặt ra, ví dụ như về thời gian 
downtime, số CCU,...

Hiện nay các hệ thống DVC trên thị trường chưa có tiêu chuẩn cụ thể nào, 
nên việc chỉ cần đưa ra được một tiêu chí định lượng cụ thể SLA cho hệ 
thống đã là thành công của dự án rồi. Qua đây nếu có thể anh em share 
một cái mẫu về tiêu chí kĩ thuật cần đáp ứng đối với một hệ thống đã 
chạy trên thực tế thì qúa tốt. Chỉ cần cho một hệ thống nhỏ vài trăm 
người dùng thôi cũng được.

Ngoài ra OpenCPS v2 cũng sẽ được nâng cấp hoàn toàn lên Liferay 7 với 
kiến trúc OSGi. Do vậy sẽ phù hợp hơn với khả năng mô đun hóa, kiểm tra 
tự động các thành phần.

Tuấn Anh

On 03/27/2017 02:18 PM, Hieu LE wrote:
> Hi anh Tuấn Anh và các anh trong BKT OpenCPS,
> (em không chắc mail em có gửi tới BKT được không vì em nhớ là em không 
> nằm trong ML của BKT)
>
> Được anh Tuấn Anh chỉ đích danh nên trước khi thảo được 1 file tài 
> liệu (A4) về phương pháp tiếp cận và kỹ thuật, em xin nêu ý kiến draft 
> và một số câu hỏi của em ở đây trước, mong các anh giải đáp giúp để có 
> thể clear hơn về định hướng.
>
> Các phần em để trong ngoặc đơn là nói về kỹ thuật, có thể bỏ qua để 
> nắm về hướng tổng quan tốt hơn ạ.
>
> 2017-03-27 10:27 GMT+07:00 Ta Tuan Anh <anhtt at fds.vn 
> <mailto:anhtt at fds.vn>>:
>
>     <snipped>
>
>     a) Kiểm thử tự động, tích hợp đóng gói phần mềm CI/CD
>
>
> Có 2 cách tiếp cận đối với mục CI/CD, một là sử dụng các dịch vụ 
> online (như TravisCI hoặc CircleCI, trả thêm tiền để có hiệu năng chạy 
> CI ổn định và tốt hơn); cách thứ 2 là tự xây dựng một cụm CI của riêng 
> OpenCPS (dùng Jenkin hoặc Zuul).
>
> Ưu điểm của cách 1 là tiết kiệm về chi phí và đã có PoC rồi (em, anh 
> Khoa và Tú đã thử nghiệm với OpenCPS 1.8 chạy trên Travis), nhược điểm 
> là sẽ khó customize và làm chủ hơn đối với các cách thức CI/CD phức 
> tạp hơn về sau này.
>
> Ưu điểm của cách 2 là mình hoàn toàn làm chủ về hạ tầng, kỹ thuật, 
> nhược điểm là chi phí về mặt con người và vận hành sẽ tốn kém hơn.
>
> Về kỹ thuật sâu hơn bên dưới, hiện tại mình đã ứng dụng Docker - đây 
> là ở mức unit với service là OpenCPS, đối với OpenCPS v2.0 nên nâng 
> lên một cấp về orchestration - có thể dùng kubernetes hoặc swarm để 
> phục vụ cho các nhu cầu ở mục 2, 3, 4 bên dưới (update/upgrade, 
> SLA...). Điều này cần OpenCPS v2.0 cần có một thiết kế về mặt kiến 
> trúc hệ thống và mặt dịch vụ chi tiết và hợp lý hơn. Em recommend là 
> chuyển dịch thiết kế hiện tại (SOA) về thiết kế micro-service.
>
>
>     b) Đảm bảo an toàn an ninh thông tin hệ thống
>
>
> Phần này em không chuyên sâu, xin nhường cho các chuyên gia từ NetNam 
> cũng như các thành viên khác.
>
>
>     c) Đảm bảo hiệu năng, mức độ sẵn sàng cao hệ thống
>
>
> Để đảm bảo hiệu năng thì phụ thuộc vào mặt ... con người là chính. Cần 
> Open thiết kế kiến trúc và từng thành phần để có thể chứng minh rằng 
> thiết kế của OpenCPS là tối ưu, đảm bảo hiệu năng. Cần có thêm cơ chế 
> review code để giảm thiểu rủi ro về ảnh hướng tới hiệu năng.
>
> Để đảm bảo mức độ sẵn sàng cao, về mặt kiến trúc, OpenCPS v2.0 phải 
> đảm bảo có thể kiểm soát được các race-condition; có nghĩa là nếu đồng 
> thời có 2 request từ 2 user khác nhau cùng tương tác với 1 tài nguyên 
> của hệ thống sẽ không gây ra tình trạng conflict. Đảm bảo được yêu cầu 
> này thì OpenCPS v2.0 có thể triển khai thành phần HA/LB ở mode 
> Active-Active.
>
> Câu hỏi: chỉ tiêu đánh giá hiệu năng, mức độ sẵn sàng cao của hệ thống 
> là bao nhiêu và như thế nào? Ví dụ về chỉ tiêu: hệ thống OpenCPS v2.0 
> triển khai trên hạ tầng cấu hình X (hardware, network..) bảo đảm chịu 
> được tải tối thiểu Y CCU, để nâng lên mức Y^Y CCU cần theo công thức 
> như sau. Ví dụ về mức độ sẵn sàng cao: nếu hệ thống gặp sự cố downtime 
> do các service của OpenCPS gây nên thì số lượng 
> connection/request/packet lost là X%.
>
>
>     d) Giám sát đảm bảo vận hành chất lượng dịch vụ theo SLA
>
>
> OpenCPS v2.0 cần phải có thiết kế và tài liệu về mặt giám sát 
> (monitoring/logging) và cảnh báo. Ngoài ra, ý d này hoàn toàn phụ 
> thuộc vào ý c ở mặt SLA.
>
> Về mặt kỹ thuật, thông thường monitoring các bên có thể sử dụng các 
> giải pháp như Nagios, Cacti, Icinga, Zabbix.. nhưng phụ thuộc vào 
> quyết định của mình ở ý a có thể sẽ là các giải pháp monitoring và 
> cảnh báo khác như Prometheus (chuyên phục vụ cho container). Cảnh báo 
> nên tối thiểu là có cảnh báo qua SMS, email và trung tâm điều hành 
> chung của OpenCPS.
>
>
>     Vì thời gian để chuẩn bị viết thuyết minh không nhiều, nên rất
>     mong các chuyên gia trợ giúp gửi các thông tin cần thiết trong
>     tuần này.
>
>     Cám ơn mọi người,
>
>     Tuấn Anh
>
>
> Em xin hết.
>
> -- 
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GCS/CM/IT/M/MU d-@? s+(++):+(++) !a C++++(++++)$ ULC++++(++)$ P 
> L++(+++)$ E !W N* o+ K w O- M V- PS+ PE++ Y+ PGP+ t 5 X R tv+ 
> b+(++)>+++ DI- D+ G e++(+++) h-- r(++)>+++ y-
> ------END GEEK CODE BLOCK------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencps.vn/pipermail/opencps-bkt/attachments/20170327/127b3c28/attachment.html>