Là dân system chắc là các bạn cũng đã từng nghe nhắc nhiều đến cụm từ “Configuration Management” hoăc cứ google là ra hàng tá bài viết liên quan.
Vâng! Configuration Management (CM) có thể hiểu là công cụ hỗ trợ, cấu hình, cài đặt hệ thống một cách tự động. Có rất nhiều công cụ như Ansible, Chef, Puppet, Saltstack … Loạt bài viết này sẽ không tập trung vào việc so sánh các công cụ CM mà chỉ hướng dẫn bạn cách cài đặt và sử dụng Ansible.
1. Ansible là cái gì?
Ansible có thể hiểu nôm na là công cụ dùng để quản lý cài đặt, cấu hình hệ thống một cách tập trung và cho phép thực thi câu lệnh điều khiển.
2. Ansible có những tính năng gì hay ho ?
+ Dự phòng tài nguyên (provisioning)
+ Quản lý cấu hình (configuration management)
+ Triển khai ứng dụng (app deployment)
+ Giao hàng liên tục (continous delivery)
+ Bảo mật và tuân thủ (security and compliance)
+ Điều phối (orchestration).
3. Đặc điểm của Ansible
+ Không cần cài đặt phần mềm lên các agent, chỉ cần cài đặt tại master.
+ Không service, daemon, chỉ thực thi khi được gọi
+ Cú pháp dễ đọc, dễ học, dễ hiểu
4. Ansible playbook thì sao?
Ansible playbook giúp chúng ta tổ chức công việc của mình theo nhiều cách. Trong hình thức trực tiếp nhất, chúng ta có thể làm việc với các module của Ansible sử dụng công cụ dòng lệnh “ansible” và file inventory.
4.1. Inventory
File inventory giúp Ansible biết các server mà nó cần kết nối sử dụng SSH, thông tin kết nối nó yêu cầu, và tùy chọn các biến gắn liền với các server này. File inventory có định dạng là INI. Trong file inventory, chúng ta có thể chỉ định nhiều hơn một máy chủ và gom chúng thành nhiều nhóm.
Ex: file inventory hosts.ini như sau
[webservers]
192.168.175.129
192.168.175.130
4.2 Task (nhiệm vụ)
Một khái niệm quan trọng khác là các task. Mỗi task của Ansible chứa một tên, một module để gọi, các tham số của module, và tùy chọn các điều kiện trước và sau. Chúng cho phép chúng ta gọi các module Ansible và truyền thông tin tới các task kế tiếp.
4.3 Vars (Các biến)
Biến hữu dụng cho việc tái sử dụng thông tin chúng ta cung cấp hoặc tập hợp. Chúng ta có thể định nghĩa biến trong các file inventory, các file YAML hoặc trong các playbook.
4.4 Playbook
Ansible playbook được viết bằng cú pháp YAML. Nó có thể chứa nhiều hơn một play. Mỗi play chứa tên của các nhóm máy chủ để kết nối tới và các nhiệm vụ nó cần thực hiện. Nó cũng có thể chứa các biến/các role/các handler, nếu đã định nghĩa.
Ex: cấu trúc của một playbook
– hosts: dbservers
gather_facts: no
vars:
who: World
tasks:
– name: say hello
debug: msg=”Hello {{ who }}”
– name: retrieve the uptime
command: uptime
Trong playbook trên, chúng ta đã nói rằng Ansible sẽ thao tác trên các server đã được định nghĩa trong nhóm máy chủ “dbservers”. Chúng ta đã tạo một biến gọi là “who” và sau đó chúng ta định nghĩa các nhiệm vụ của chúng ta. Chú ý rằng trong nhiệm vụ đầu tiên nơi chúng ta in ra một thông điệp debug, chúng ta đã sử dụng biến “who” và Ansible in “Hello World” ra màn hình. Trong nhiệm vụ thứ 2, chúng ta nói với Ansible kết nối tới mỗi máy chủ và sau đó thực thi lệnh “uptime”.
5. Hướng dẫn cài đặt và tổ chức một ansible playbook
5.1 Cài đặt.
Việc cài đặt ansible khá là đơn giản:
Trên CentOS:
$ yum install epel-release
$ yum install ansible Trên Ubuntu:
Cấu hình PPA, cài đặt:
$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible
Trên các phiên bản Ubuntu cũ, gói software-properties-common có tên khác là python-software-properties
5.2 Viết một playbook cho việc triển khai các dịch vụ
Ở đây mình đã có viết một playbook cho việc deploy các dịch vụ như nginx, mongodb, redis, postgresql.
Mô hình deploy:
+ node master ( 192.168.75.128): cài đặt ansible tool
+ node deploy services (192.168.75.129 & 192.168.75.130): các dịch vụ như nginx, mongodb, redis, postgresql sẽ được deploy trên 2 node này
Các bạn có thể tham khảo playbook qua link github sau:
Đang trong kỳ nghỉ lễ quốc khánh 2/9 chắc là các bạn cũng có những trải nghiệm thú vị cùng bạn bè hoặc gia đình, riêng mình thì kỳ nghĩ lễ này cũng ko có plan đi đây đi đó nên rảnh rổi sinh nông nổi, ngồi viết vài câu chuyện tản mạn chia sẻ cùng các bạn, gọi là cho đỡ tẻ nhạt bớt trong kỳ nghỉ lễ này :v. Tiếp nối những seri linh ta linh tinh trước đó về chuyện đời chuyện nghề của 1 system admin, hôm này mình tiếp tục cùng bàn luận về topic nho nhỏ ” làm thế nào để biết mình đang đi đúng con đường ” theo cách nghĩ khách quan của bản thân mình thôi nha các bạn :-).
Ngược dòng xa xôi chút về những năm cuối cấp 3, thời điểm mà ai ai cũng có những lựa chọn riêng về ngành nghề vs ước mơ sẽ theo đuổi, có người thì đã định hướng từ trước, có người thì cũng chả biết nên theo ngành nghề nào cứ tham khảo ý kiến ai đó, bạn bè or người quen rồi chọn trường theo, kiểu như mông lung như một trò đùa =)).
Chặng đường tiếp theo sau đó có lẽ là cánh cổng ĐH nơi bước đầu hiện thực hóa những hoài bảo, một chương mới trên con đường sự nghiệp được mở ra, ở đó thứ cho bạn có lẽ là những hành trang về nghề nghiệp để bước vào đời từ kiến thức chuyên môn của từng ngành nghề, kiến thức xã hội, mối quan hệ….
Sau khi có được tấm bằng ĐH (cử nhân, kỹ sư…) ai cũng đi tìm cho mình một công việc theo đúng chuyên môn được đào tạo, nhưng cuộc sống mà đâu phải lúc nào cũng theo ý ta, có bạn thì làm đúng chuyên môn, còn có bạn thì lại rẽ theo hướng khác. Nói về mình thì định hướng trước đó là làm về quản trị mạng, hệ thống nên sau khi tốt nghiệp ra trường cũng rán tìm một công việc có liên quan, nhưng những ngày đầu vì kiến thức, kỹ năng, kinh nghiệm làm việc ko nhiều nên cũng ít công ty nào để ý tới, thời điểm đó cũng rải CV như phát tờ rơi :v miễn là có một công việc để làm.
Sau những tháng ngày ròng rã tìm kiếm cv, chạy đi PV như là chạy show :v cũng chỉ tìm được ở những vị trí lèn tèn như Monitor, Vận hành hệ thống, thoạt nghe thì có chút dính líu tới chuyên môn nhưng vào làm thì chẳng có gì nhiều đâu các bạn, thao tác chính chủ yếu là các phím Crl + C + V =)), Snipping Tool, theo dõi mấy cái biểu đồ màu mè hoa lá hẹ, các dòng log error đỏ lòm, có bất thường gì thì la lên cho các sếp mà thời đó đúng nghĩ là kiếp cầm ca (làm theo ca đó các bạn =)) ), dĩ nhiên là công việc khá chán rồi nhưng cũng gọi là có công việc để kiếm cơm qua ngày là zui zui gồi.
Một khoảng thời gian sau đó mình tìm được 1 vị trí system theo đúng chuyên môn mình mong đợi, công việc trước đó khá chán nhưn bù lại là có chút time rảnh nên mình cũng tự đào sâu kiến thức qua những bài LAB, hỏi han các bậc tiền bối đi trước mới có cơ may tìm được cv phù hợp sau này. Những chặng đường sau đó và cho đến bây giờ thì mình đều đảm nhận vị trí là 1 system admin, công việc hiện tại vẫn cho mình những niềm vui & lợi ích nhất định, đặc biệt vẫn còn đam mê với nghề cho nên cũng gọi là đang đi đúng con đường mà mình lựa chọn trước đó mặc dù cũng đã trải qua những tháng này đen tối trong sự nghiệp :v, đó là điều hiển nhiên ai cũng đã từng trải qua.
Vậy thì câu hỏi “Làm thế nào để biết mình đang đi đúng con đường”, con đường ở đây là con đường sự nghiệp( con đường lớn) nói chung và trong nghê IT nói riêng(con đường nhỏ),không ai dám chắc là mình chỉ làm một công việc đó suốt đời, có thể nghề này rồi lại nghề khác(hoàn cảnh đẩy đưa :v) nhưng nếu xét ở một phạm vi nào đó trong những ngành nghề chúng ta đã từng làm thì cái gọi là “đúng con đường” có thể hiểu là ở giai đoạn đó, nghề đó, công việc đó mang lại cho bản thân ta những niềm vui, sự thành công nhất định, một sự hưng phấn, bầu nhiệt huyết và cả sự đam mê trong công việc . IT cũng không ngoại lệ, một khi trải qua những khoảng thời gian trước đó cho đến thời điểm hiện tại trong cái nghề mà bạn đã chọn, nó không mang lại nhiều thành công cho bạn, không tạo được cho bạn hứng thú trong khi làm việc hay nói cách khác là cảm giác chán việc chán nghề thì bạn có thể cân nhắc cho mình những hướng đi, ngã rẽ mới , biết đâu được bạn lại gặt hái được nhiều thành công hơn ở những con đường mới đó thì sao.
Hãy phá vỡ mọi giới hạn của bản thân, hiện thực hóa những ý tưởng đang tồn tại trong đầu bạn, biến điều không thể thành có thể. Chúc các bạn thành công!
Tiếp tục câu chuyện ở part 1, trong bài viết này sẽ trình bày các thành phần tiếp theo của hệ thống Stack Overflow theo kiến trúc được cập nhật đến năm 2016.
Cache & Pub/Sub (Redis)
SO sử dụng Redis cho 2 việc là caching và pub/sub cho hệ thống, mặc dù chịu tải khoảng 160 tỷ câu lệnh trong vòng 1 tháng, những mỗi instance chỉ chạy khoảng 2% CPU, ở mức rất thấp. (Chắc chỉ tốn RAM).
SO sử dụng Redis làm caching 2 lớp L1/L2, L1 sử dụng cho HTTP Cache cho web server và bất kỳ ứng dụng nào đang chay, còn L2 dùng để lấy giá trị từ Redis, có thể hiểu là L1 dùng để write, còn L2 dùng để read. Giá trị của key trong Redis theo định dạng protobuf thông qua thư viện protobuf-dot-net của Marc Gravell. Thư viện sử dụng cho client là StackExchange.Redis là một opensource và tự phát triển. Khi mà web server bị miss ở cả 2 L1 và L2, chúng sẽ lấy dữ liệu từ database thông qua query hoặc gọi API…và ghi kết quả vào cache local và Redis, khi đó 1 web server khác muốn lấy giá trị nào đó, có thể miss ở L1 nhưng chắc chắn sẽ lấy được ở L2 hoặc database hoặc thông qua việc gọi API.
Các trang Q&A đều có caching theo dạng key prefix thì đặt ở L1 còn L2 thì chứa database ID.
Bên cạnh 2 server Redis chạy master/slave cho toàn bộ các site hiện có, thì SO còn có thêm 1 server slave machine learning sử dụng cho việc thể hiện các câu hỏi khuyến nghị, job matching …được gọi là Providence.
Server Redis chính thì có 256GB RAM (96GB đã sử dụng) và Providence thì có 384GB RAM (125GB đã sử dụng).
Và tất nhiên không chỉ dùng để caching, SO còn dùng Redis theo cơ chế pub/sub để public 1 message cho toàn bộ subcriber bao gồm đã downstream ở Redis slave, SO dùng cơ chế này để xóa 1 lưu trữ trên L1 của 1 web server khi 1 web server khác bị loại bỏ khỏi tính đồng bộ của hệ thống.
Redis isn’t just for cache though, it also has a publish & subscriber mechanism where one server can publish a message and all other subscribers receive it—including downstream clients on Redis slaves. We use this mechanism to clear L1 caches on other servers when one web server does a removal for consistency, but there’s another great use: websockets.
(Đoạn này hơi rắc rối, mình xin phép để nguyên văn)
NetGain WebSockets
SO sử dụng websocket để push real-time cập nhật của user ví dụ như các thông báo trên top bar, số lượng vote, hay câu hỏi hay câu trả lời mới và 1 vài thứ khác.
Và các server socket này sử dụng raw socket và chạy trên các web tier sử dụng thư viện StackExchange.NetGain, trong peak time( giờ cao điểm) ,số lượng kết nối đồng thời lên tới 500.000, và có những kết nối kéo dài 18 tháng, tác giả không chắc là người đó có tắt browser của mình hay có còn sống không nữa?
Search (Elasticsearch)
Nói chung là không có điều gì thú vị ở đây cả, SO sử dụng Elasticsearch 1.4 và thư viện StackExchange.Elastic cho client và sử dụng cho đường /search trên website, tính toán các câu hỏi có liên quan, và đề xuất khi đặt câu hỏi.
Mỗi cụm cluster ES đều có 3 node trên từng datacenter , và mỗi site đều đánh 1 index. Như site Careers thì có nhiều index hơn và được cấu hình theo 1 cách khác không theo dạng chuẩn, với 3 cụm cluster lớn hơn với SSD và 192 GB RAM và 2x10GBps cho card mạng.
Lý do chính để sử dụng ES là cho việc tìm kiếm full-text SQL một cách dễ dàng và ít chi phí hơn so với việc sử dụng database SQL. Vậy tại sao lại không dùng Solr thay thế cho ES? Việc này có thể xảy ra trong tương lai với version 2.x.
Databases (SQL Server)
SO sử dụng SQL Server là Single_source_of_truth , mọi dữ liệu trên Redis hay ES đều đến từ database và có 2 cụm cluster SQL Server được cài đặt, với mỗi cluster đều có 1 master và 1 replica ở New York, thêm vào đó là 1 replica ở Colorado, và tất cả các bản sao đều chạy bất đồng bộ.
Cụm đầu tiên bao gồm server Dell R720xd, mỗi con có 384GB Ram, 4TB PCIe SSD và 2×12 cores, chúng chứa Stack Overflow, Sites, PRIZM, và dữ liệu Mobile.
Cụm thứ 2 bao gồm server Dell R730xd, mỗi con có 768GB RAM, 6TB PCIe SSD và 2×8 core, chạy những thứ còn lại, bao gồm Talent, OpenID, Chat, Exception log và toàn bộ các trang Q&A ví dụ Super User, Server Fault
Mức sử dụng CPU hiện tại còn khá cao mặc dù đã được optimize, có thể thấy trong biểu đồ sau, với 04 là master, 01 và 03 là replica.
Thư viện
Dưới đây là toàn bộ các thư viện tự phát triển hoặc opensource được sử dụng cho SO.
Dapper (.Net Core) – High-performance Micro-ORM for ADO.Net
Sau một bài viết khá dài và chi tiết của tác giả Nick Craver, chúng ta có thể thấy được toàn bộ những gì phía sau của 1 hệ thống website vô cùng đồ sộ và đáp ứng được hàng triệu người dùng trên toàn thế giới. Bài viết của mình xin dừng ở đây và hi vọng sẽ trở lại với việc tìm hiểu những hệ thống lớn khác.
Không cần phải giới thiệu nhiều về Stack Overflow (SO), bởi vì nó quá nổi tiếng và phổ biến trong cộng đồng developer và có nguyên cụm từ “The full stackoverflow developer” để mô tả những developer sống không thể thiếu website này 😀 System Engineer cũng không ngoại lệ đâu nhé!
Vậy bạn có bao giờ tự hỏi Đằng sau SO là 1 hệ thống được xây dựng như thế nào chưa? Bài viết của Nick Craver, Architecture Lead, Developer, Site Reliability Engineer & DBA Stack Overflow viết năm 2016 trên website của ổng sẽ bật mí cho chúng ta biết phía sau cô gái ấy có gì. Trong bài viết này mình sẽ tóm tắt lại những ý chính trong bài viết trên, chi tiết thì các bạn có thể theo dõi trực tiếp theo link phía trên nhé.
SO là 1 hệ thống khổng lồ, phục vụ hàng triệu người dùng, được thể hiện qua các con số biết nói như sau, số liệu vào năm 2016:
209,420,973 HTTP requests tới gateway ( load balancer)
66,294,789 page loads
1,240,266,346,053 bytes (1.24 TB) HTTP traffic gửi đến
569,449,470,023 bytes (569 GB) tổng nhận
3,084,303,599,266 bytes (3.08 TB) tổng gửi
504,816,843 SQL Queries (từ HTTP requests)
5,831,683,114 Redis hits
17,158,874 Elastic searches
3,661,134 Tag Engine requests
607,073,066 ms (168 hours) xử lý SQL queries
10,396,073 ms (2.8 hours) xử lý Redis hits
147,018,571 ms (40.8 hours) xử lý Tag Engine requests
1,609,944,301 ms (447 hours) xử lý trong ASP.Net
22.71 ms trung bình (19.12 ms trong ASP.Net) cho 49,180,275 truy cập trang câu hỏi
11.80 ms trung bình (8.81 ms trong ASP.Net) cho 6,370,076 truy cập trang home
Thật đáng kinh ngạc, để đạt được những con số này, thật không đơn giản, chúng ta cùng xem nhé. Bắt đầu nào!!
Dưới đây là sơ đồ logic tổng quan của hệ thống SO. Bao gồm:
“Everything is redundant” mọi thứ đều dư thừa là tôn chỉ của SO trong xây dựng hệ thống, luôn luôn là vậy trong mọi cài đặt.
Tất cả các server hay thiết bị mạng đều có tối thiểu 2x 10 Gbps cho card mạng.
Tất cả các server đều có 2 nguồn cấp điện thông qua 2 hệ thống UPS được hỗ trợ bởi 2 hệ thống cấp điện và 2 nguồn tiện ích khác.
Tất cả các server đều có dự phòng giữa 2 rack A và B.
Tất cả các server và dịch vụ đều có dự phòng ở datacenter khác (Colorado backup cho New York).
Kết nối Internets
Mỗi request khi truy cập vào trang web, sẽ đến với DNS đầu tiên, ta có thể thấy là stackoverflow.com được trỏ tới 4 ip .69 (có vẻ như mấy ổng thích con số này), truy cập nhanh chóng phục vụ cho toàn bộ user trên toàn thế giới, sử dụng CloudFlare làm DNS, tuy nhiên thì vẫn có những server chạy DNS dự phòng cho trường hợp có sự cố xảy ra.
Sau đó request sẽ đi đến từ 1 trong 4 nhà cung cấp mạng và đi qua 1 trong 4 router tương ứng. SO sử dụng đường truyền thì được cung cấp bởi 4 nhà mạng ISP tại New York đó là Level 3, Zayo, Cogent, và Lightower và sử dụng giao thức BGP để định tuyến. Tiếp đó sử dụng 2 cặp router ASR-1001 và ASR-1001-X và mỗi cái thì gắn 2 nhà mạng dưới dạng active/active và băng thông của mỗi line là 10Gbps.
Tiếp đó, request sẽ được đón nhận tại load balancer.
Haproxy
Haproxy được dùng làm load balancer, đang chạy version 1.5.15 trên Centos 7 và sẽ sớm chuyển sang version 1.7 có hỗ trợ http/2. Tất cả các traffic TLS(SSL) đều được chặn và xử lý tại đây.
Khác với những server khác, sử dụng 2 interface 10 GBps chạy LACP, thì server LB này có 1 interface dành cho external và 1 dành cho DMZ, có thể giải thích là 1 card public, 1 card private. Với bộ nhớ từ 64GB trở lên để cache lại TLS và SSL.
Việc cài đặt haproxy tương đối đơn giản, chỉ cần bắt đúng Host header và route chúng tới backend dựa trên ip và domain từ DNS.
Web Tier (IIS 8.5, ASP.Net MVC 5.2.3, và .Net 4.6.1)
Load balancer sẽ đá các request xuống 9 web server primary chạy production và 2 server phụ dành cho môi trường dev/staging. Các site trên IIS cụ thể cho 2 môi trường như sau:
Các web server như sau:
Service Tier (IIS, ASP.Net MVC 5.2.3, .Net 4.6.1, and HTTP.SYS)
Phía dưới của các web tier đó chính là các service chạy dưới IIS 8.5 trên Windows 2012 R2. Các serivce này chỉ chạy và xử lý nội bộ và phục vụ cho web server. Có 2 dịch vụ lớn đó là “Stack server” chạy trên HTTP.SYS và Providence API chạy trên IIS.
Bài viết ở trên còn nhiều trúc trắc do khả năng đọc hiểu của mình còn chưa tốt, nên mong nhận được sự góp ý của mọi người để mình có thể viết tốt hơn. Thanks.
Streaming hay streaming media là một quá trình mà các định dạng truyền thông (như âm thanh, hình ảnh) được gửi tới người dùng và hiển thị ngay cả khi nó vẫn đang trong quá trình tải.
2. Live streaming là gì ?
+ Đây là một thuật ngữ nói về việc các nội dung, các dữ liệu media được thu lại, xử lý rồi truyền tải trực tiếp qua mạng Internet tới người nhận trong cùng một thời điểm.
+ Vì là một kỹ thuật được thực hiện theo thời gian thực, nên tùy vào từng trường hợp, từng hệ thống server mà khi nhận được dữ liệu, video chạy trên thiết bị của người dùng sẽ có độ trễ nhất định so với các tình huống thực tế đang xảy ra. 3. Streaming video hay video streaming nghĩa là gì?
Video streaming chính là một “dòng chảy” video. Các thông tin, dữ liệu của đoạn video này được luân chuyển liên tục, đều đặn từ nguồn gửi tới “đích” nào đó thông qua mạng Internet.
3.1 Streaming video các tác dụng gì?
Điểm nổi bật và rõ ràng nhất của Stream video chính là việc người dùng có thể xem các đoạn video clip, thậm chí là phim mà không cần phải download về máy, điều này tiết kiệm được rất nhiều thời gian so với trước đây.
3.2 Streaming video hoạt động thế nào?
Hình ảnh minh họa đơn giản các hoạt động của live stream
Có thể hiểu Streaming Video chính là việc chia nhỏ các file media thành từng frame, sau đó gửi những frame này vào bộ nhớ đệm của máy tính và hiển thị nội dung lần lượt của từng fame. Trong khi người dùng đang sử dụng dữ liệu của những tập tin này thì frame của những tập tin khác vẫn tiếp tục được tải về.
II. Kiến trúc tổng quan HTTP Live Streaming
Hình ảnh minh họa cho kiến trúc HTTP Streaming
1. Server component
Server sẽ yêu cầu một phương thức để mã hóa các dữ liệu media đầu vào ( audio/video), sau đó sẽ phân đoạn các dữ liệu đó thành các segment và lưu chúng dưới dạng file
Media Encoder
+ Bộ mã hóa dữ liệu media sẽ lấy các tin hiệu realtime từ thiết bị audio-video sau đó mã hóa, đóng gói và vận chuyển các data segment từ nguồn tới đích , chuẩn mã hóa phải hỗ trợ những định dạng dữ liệu từ các thiết bị phía client, ví dụ như chuẩn H.264 cho video & chuẩn HE-AAC /MP3cho audio.
+ Hiện tại đã hỗ trợ MPEG-2, một tiêu chuẩn mã hóa nén(thường được gọi tắt là chuẩn nén) trong bộ tiêu chuẩn MPEG dùng để mã hóa luồng dữ liệu hình có kết hợp với các thông tin về âm thanh. Phiên bản trước của MPEG-2 là MPEG-1. MPEG-1 được thiết kế để truyền và lưu trữ các nội dung phim ảnh có độ phân giải trung bình (576×724 điểm ảnh).
Stream Segmenter
+ Stream Segmenter là một luồng xử lý thông qua 1 stream server ( nginx hoặc third-party software), đọc các luồng stream từ mạng local và phân chia thành các tệp media có kích thước nhỏ hơn.
+ Stream Segmenter cũng tạo ra một tập tin chỉ mục có chứa tham chiếu tới các tệp tin media riêng lẻ. Mỗi lần phân đoạn hoàn thành một tệp phương tiện mới, tệp chỉ mục sẽ được cập nhật. Chỉ mục được sử dụng để theo dõi sự sẵn có và vị trí của các tệp phương tiện.
+ Các segment media được lưu dưới dạng tệp .ts (tệp luồng vận chuyển MPEG-2). Các tệp chỉ mục được lưu dưới định dạng .M3U8.
2. Distribution component
+ Distribution system có thể hiểu là một web server hoặc là một cụm web caching system (CDN) cung cấp các media files & index files cho client thông qua giao thức HTTP
3. Client Component
+ Các thiết bị phía client ( moblie/destop/browser) sẽ đọc các index files dựa trên các url được định danh bởi các stream, Index files sẽ chỉ định vị trí của các tệp media đã có sẵn. Đối với các stream được chọn , client sẽ tải xuống từng tệp media có sẵn, mỗi tệp chứa một phân đoạn liên tiếp của luồng dữ liệu. Khi đã có đủ số lượng dữ liệu đã tải về, client có thể xem nội dung hiển từ các dữ liệu đó.
III. Một số giao thức chính sử dụng trong streaming
TCP/IP
+ RTP (Real Time Transport Protocol)
Giao thức vận chuyển thời gian thực đặc tả một tiêu chuẩn định dạng gói tin dùng để truyền âm thanh và hình ảnh qua internet. Tiêu chuẩn này được khai báo trong RFC 1889. Nó được phát triển bởi nhóm Audio Video Transport Working và được ban hành lần đầu tiên vào năm 1996.
RTP và RTCP liên kết rất chặt chẽ với nhau – RTP truyền dữ liệu thực trong khi RTCP được dùng để nhận thông tin phản hồi về chất lượng dịch vụ.
+ RTSP (Real Time Streaming Protocol)
– RTSP là một giao thức ở tầng ứng dụng trong bộ các giao thức Internet (Internet Protocol Suite) để kiểm soát việc truyền dữ liệu theo thời gian thực. RTSP cung cấp một nền tảng mở rộng cho phép kiểm soát, truyền theo yêu cầu của dữ liệu thời gian thực, chẳng hạn như âm thanh và video.
– RTSP được sử dụng để thiết lập và quản lý các phiên làm việc giữa các điểm truyền, phát tin đa phương tiện.
+ RTMP (Real Time Messaging Protocol)
– RTMP (Real Time Messaging Protocol) là giao thức không công khai do Adobe phát triển và giữ bản quyền, được thiết kế cho ứng dụng thời gian thực, cho phép ứng dụng sử dùng video và âm thanh với tốc độ nhanh, hạn chế bị giật hình hoặc méo tiếng.
HTTP
+ Apple HLS – HTTP Live Streaming
– Là một chuẩn giao thức cho HTTP Live Streaming được phát triển bởi Apple dành cho các thiết bị iOS và Quick Time Player, hỗ trợ Android 3.0. HLS có thể triển khai trên hầu hết các máy chủ HTTP ( bao gồm cả Apache) hoặc một số máy chủ streaming thương mại như Adobe FMS và Wowza.
+ HDS – Adobe HTTP Dynamic Streaming
– HTTP Dynamic Streaming được phát triển bởi Adobe như một sự thay thế cho giao thức RTMP của họ. HDS cho phép truyền trực tiếp trên HTTP tới bất kỳ thiết bị nào tương thích với Adobe Flash hoặc Air.
+ Microsoft Smooth Streaming
– Là một giao thức được phát triển bởi Microsoft dựa trên HTTP và chuẩn định dạng file mp4, bằng việc sử dụng các tài nguyên lưu trữ hiện có thông qua HTTP Caching.
+ DASH – Dynamic Adaptive Streaming over HTTP
– Là một kỹ thuật streaming cho phép truyển tải các nội dung media chất lượng cao qua Internet. Tương tự như giải pháp HTTP Live Streaming (HLS) của Apple, MPEG-DASH hoạt động bằng cách chia nhỏ nội dung thành một chuỗi các phân đoạn tệp dựa trên HTTP, mỗi phân đoạn chứa một khoảng thời gian phát khác nhau
*Sự khác biệt giữa 2 giao thức HTTP và RTMP
Giao thức HTTP
Giao thức RTMP
Web server (Apache, Lighttpd, Nginx…)
Messaging server (Adobe Flash Media Server, Wowza Media Server, Red5…)
Sử dụng Web Browser
Sử dụng Flash player
Truyền văn bản thời gian ngắn (Phù hợp với web truyền thống)
Truyền dữ liệu thời gian thực/dài (Phù hợp với các file Media: Nhạc, Phim)
SOAP, XML
AMF
File .html, .js
File .swf, .as, .flv, .mp3
IV. Cài đặt & cấu hình một streaming server
1. Cài đặt Nginx và Nginx-RTMP
$ yum -y install gcc gcc-c++ make zlib-devel pcre-devel openssl-devel
chunk_size 4096;#Kích thước chunk tối đa để ghép kênh stream
#video on demand for flv files
application vod {
play /var/flvs;
}
# video on demand for mp4 files
application vod2 {
play /var/mp4s;
}
### Tạo một luồng HLS streaming là hls ###
application hls {
live on; # Bật luồng streaming “live”
record all;# Bật ghi hình video và audio streaming
record_path /streaming/rec; # Thư mục chứa các file ghi hình flv
record_suffix _recorded.flv;
record_unique on; # Khi bật chế độ này sẽ thêm thời gian vào tên các file ghi hình
meta copy; # gửi đúng bản sao dữ liệu từ nguồn tới đích
interleave on; # Chuyển đổi chế độ xen kẽ. Trong chế độ này dữ liệu âm thanh và video được truyền trên cùng một đoạn RTMP.
wait_key on; #Tạo một video stream với một khung chính
wait_video on; # Disable audio cho đến khi video frame đầu tiên được gửi đi
hls on; # Bật hls
hls_fragment_slicing aligned; # chế độ này nhằm tạo ra các fragment giống nhau trên các instance nginx khác nhau
hls_path /streaming/hls; #Thiết lập thư mục chứa HLS playlist và fragment
hls_nested on; # Bật chế độ nested. Ở chế độ này một thư mục con sẽ được tạo ra cho mỗi luồng stream. Các HLS playlist và fragment sẽ được tạo ra trong thư mục con đó
hls_fragment 10s; # Thiết lập chiều dài HLS fragment
hls_playlist_length 5m; #Thiết lập chiều dài HLS cho playlist
hls_sync 100ms; # Set ngưỡng đồng bộ hóa thời gian HLS , tính năng này giảm tình trạng nhiễu âm sau khi chuyển đổi từ độ phân giải thấp RTMP (1KHz) sang độ phân giải cao MPEG-TS (90KHz).
hls_continuous on;
hls_cleanup off; # cho phép giữ lại các segment file .ts và index file .m3u8
hls_variant _240 BANDWIDTH=220000;
hls_variant _360 BANDWIDTH=1500000;
hls_variant _480 BANDWIDTH=2110000;
hls_variant _720 BANDWIDTH=3110000;
}
#allows you to play your recordings of your live streams using a URL like “rtmp://my-ip:1935/vod/filename.flv”
–Sử dụng module FFmpeg để encoding các live stream video về định dạng .flv và lưu ở thư mục /streaming/rec. Ta có thể tùy chỉnh các thông số như bitrate video, bitrate audio và độ phân giải.
Định dạng như sau: rtmp://ip-server:port/application-name/stream-name
-i: địa chỉ ứng dụng streaming.
-b: v bitrate video
-c: v bộ mã hóa hình ảnh
-s: độ phân giải
-f: định dạng xuất
-bufsize: kích thước bộ đệm
–Thêm vào nội dung sau trong file nginx.conf mục application hls{} :
Trong phần trước mình đã đề cập đến 3 bước thực hiện và hoàn thành thành công 10% cho việc pass được vị trí SE tại VNG, trong phần này, mình sẽ tiếp tục nói về 70% còn lại, khi bạn đọc tiếp bài viết này, có nghĩa là bạn đã vượt qua được vòng review CV và có 1 cuộc hẹn với HR cùng với nhân sự thường là team leader, manager… của vị trí đó.
Tùy thuộc vào phân công công việc và đặc thù của mỗi team, nên sẽ có yêu cầu khác nhau cho cùng 1 title là SE của công việc, bạn có thể sẽ là người vận hành hệ thống bao gồm hệ thống game, dữ liệu, hệ thống tài khoản, đăng nhập… hoặc sẽ là người xây dựng hạ tầng ảo hóa và các dịch vụ liên quan cho nội bộ, bao gồm server và storage, hoặc sẽ là người vận hành, quản lý hệ thống mail, vpn, ERP…, hoặc sẽ làm công việc hỗ trợ khách hàng, technical support, hoặc sẽ làm người vận hành cho hệ thống cổng thanh toán cũng như các sản phẩm có liên quan khác. ( Chổ này hơi dài và lan man, có thể được trình bày thêm ở Làm system là làm cái gì?)
Để thành công trong Round 2 Technical Interview này, mình sẽ không đi sâu vào vấn đề technical của bạn, mà sẽ nói ra những điều các bạn cần tránh, để không phải gặp những sự cố đáng tiếc như mình và các cộng sự của mình 🙂
Những điều không nên làm khi đi phỏng vấn Technical
– Đi trễ vì bất cứ lý do gì mà không báo lại, nếu bạn bận hoặc không đến được tại thời điểm đó, hoàn toàn có thể liên lạc với HR và thông báo là sẽ đến trễ hoặc hẹn lại vào dịp khác, tuyệt đối không đến/ đến trễ mà không có thông tin cho HR.
– Không đi nhầm vào nhà vệ sinh nữ, trong lúc hồi hộp, bạn hoàn toàn có thể vào nhầm nhà vệ sinh và trở thành kẻ biến thái lúc nào không hay, nhìn kỹ tấm bảng trên cửa hay để ý xem có cái bồn tiểu nào ở trong đó nhé. Thiết kế văn phòng ở các lầu là tương đối giống nhau, nên bạn có thể tìm thấy nhà vệ sinh nam ở bên phía tay phải, và bên trái là dành cho trường hợp ngược lại nhé.
– Không nhậu xuyên đêm trước khi đi phỏng vấn, với khuôn mặt mệt mỏi, đôi mắt đỏ ngầu, cơ thể bốc mùi hay quần áo lôi thôi, bạn sẽ không có được cái nhìn thiện cảm từ nhà tuyển dụng, chưa nói đến vấn đề kỹ thuật, bạn đã được ghim ngay từ đầu.
– Thời gian phỏng vấn thường từ 30-45p, bạn không nên nghe điện thoại hay xin ra ngoài vệ sinh trong trường hợp này, cũng không nên bỏ về giữa chừng hay ngồi lỳ thêm 10-15p nữa chẳng hạn.
– Không nên chém gió về những kiến thức mình không biết hoặc nắm mơ hồ, vì bản chất người hỏi cũng chưa nắm thật rõ câu trả lời, nếu bạn chém gió về nó nhiều quá, thì lại làm cho người phỏng vấn cảm thấy không hài lòng với bản thân mình. 😛
– Không nên nhìn vào gầm bàn hay 1 khoảng không nào đó, thay vì vậy, hãy nhìn thẳng vào đối tượng để trả lời, nếu không trả lời được, hãy trung thực bỏ qua nó, đừng cố tỏ ra yếu đuối hay thiếu tự tin.
– Không nên trả lời quá thật lòng về công ty cũ, đồng nghiệp cũ và quan điểm của bạn về 1 vấn đề nào đó, hãy để những điều này như là bí mật riêng của bạn, không nhất thiết chia sẻ với người khác.
– Không nên ghi quá nhiều kỹ năng, có thể không liên quan hoặc hơi thừa cho yêu cầu công việc, bạn sẽ phải mệt mỏi với những câu hỏi liên quan tới những thứ bạn đã ghi, “bút sa gà chết”, hãy sống có trách nhiệm, và viết vô CV cũng như vậy
– Không nên đánh đố nhà tuyển dụng khi người ta hỏi mình có câu hỏi nào nữa không? Những câu hỏi tương tự như “Bao lâu em được lên làm sếp?”, “Anh có thấy công việc hiện tại nhàm chán không?” chỉ nên hỏi khi mình đã là 1 trong số họ rồi, đừng nên hỏi lúc đó nhé.
Không làm những điều đã kể trên, theo mình nghĩ, bạn đã hoàn thành tiếp tục được 50% chặng đường, có nghĩa là chỉ còn 20% nữa là bạn sẽ tới được mục đích ban đầu, pass được vị trí SE tại VNG. Nếu qua được vòng này, bạn sẽ nhận được letter của nhân sự sau khoảng từ 3-5 này làm việc, chuẩn bị mang đồ đẹp và enjoy vòng tiếp theo thôi nào.
Qua được vòng này, có nghĩa là bạn sẽ có cơ hội rất lớn, nhưng không hoàn toàn chắc chắn nhé, vì ngoài kỹ năng, năng lực “được đánh giá sau 30-45p” thì thái độ cũng là 1 yếu tố rất quan trọng, họ sẽ tìm người phù hợp, chứ không cần là người quá xuất sắc, vì sau 1 khoảng thời gian ngắn ngủn như vậy, họ chắc chắn sẽ không biết bạn giỏi tới đâu hay gà cỡ nào mà đánh giá đúng năng lực của bạn.
Trong phần sau mình sẽ nói thêm về phần 3, cách bày tỏ thái độ và deal lương như thế nào cho hiệu quả 🙂 Đón xem nhé!!!
Như các bạn đã biết, VNG là 1 trong những công ty lớn ở Việt Nam về lĩnh vực Internet và nội dung số, nên có được 1 hệ thống và hạ tầng mạng rất lớn cùng với đó là những sản phẩm có hàng triệu người dùng nên rất cần những vị trí kỹ sư phục vụ cho việc vận hành và phát triển hệ thống. Nhân dịp trên trang tuyển dụng của VNG có đăng tuyển job SE, mình xin được phép trình bày kinh nghiệm của mình về vấn đề này, do mình và bạn bè (writer của blog này) đều có dịp được thử sức với vòng interview ở đây (chủ yếu là rớt):).
Job detail bạn có thể xem chi tiết ở đây: https://career.vng.com.vn/co-hoi-nghe-nghiep/chi-tiet/55.1569-system-engineer-payment#list
Cũng như những công ty khác, phần phỏng vấn thì thường có 2 rounds, dĩ nhiên là round 1 là vòng phỏng vấn kỹ thuật, round 2 sẽ là phỏng vấn về kỹ năng mềm và thảo luận về lương, phúc lợi, chính sách của công ty …Trong bài viết này, mình sẽ chia sẻ về cả 3 rounds, (hồi nãy nói rõ ràng chỉ có 2???), đó là Viết CV/Resume, Phỏng vấn Technical và Phần thảo luận lương. Khi bạn đọc được bí kíp này, thì khoảng hơn 80% là bạn đã pass được vị trí SE rồi đó.
Vậy làm sao để đạt được con số 80% đó?
Bước 1: Bạn có thực sự phù hợp với yêu cầu công việc đó không?
Nếu bạn đã có từ 1-3 năm làm việc như 1 SE như ở bài viết này và có những đức tính sống còn của 1 SE thì bạn có thể hoàn toàn tự tin apply, tuy nhiên, nếu bạn có ít hơn 1 năm thì cũng không hề gì, hoàn toàn có thể nếu bạn đang ở trên level 0 ở bài viết này, còn nếu như bạn chưa hề có 1 tí kinh nghiệm gì về công việc SE thì hãy yên tâm, theo dõi hết blog này, bạn hoàn toàn có thể apply trong thời gian tới.
Bước 2: Làm sao để nhà tuyển dụng biết được là bạn phù hợp với công việc này?
Cách duy nhất thể hiện cho nhà tuyển dụng biết được bạn là ai, đó là thông qua profile của bạn, nếu như bạn nổi tiếng, có viết blog (nhiều người like), hay sở hữu những khả năng vượt trội, được các head-hunter săn đón thì lại là trường hợp khác, không cần bàn luận ở đây, tuy nhiên, nếu bạn là 1 người bình thường, các tip sau sẽ giúp bạn có 1 resume/CV có thể qua được vòng gửi xe.
– Resume/CV rõ ràng, rành mạch, đầy đủ thời gian làm việc được liệt kê theo thời gian gần nhất cho tới quá khứ, nếu bạn có quá nhiều công ty hay nơi làm việc, công việc đã từng làm, thì nên liệt kê từ 1-3 nơi thôi nhé, nhiều quá thì cũng không hay lắm.
– Nếu bạn là sinh viên mới ra trường, nếu có chứng chỉ, bằng cấp liên quan thì nên liệt kê, nếu điểm số cực cao thì nên ghi vào, còn thấp hoặc xếp loại thấp thì bỏ qua luôn. Ví dụ như Tốt nghiệp BK, điểm 9.6/10, còn Tốt nghiệp SPKT 6.66/10 hay KHTN bằng TB thì thôi, đừng ghi điểm số hay loại tốt nghiệp vào nhé.
– Số điện thoại hay email, skype của bạn phải sạch, có nghĩa là dùng số điện thoại đó search google không thấy bài share hàng trên đâu đó (bạn tự biết) hay là dính phốt giựt tiền, xù nợ, nói xấu công ty cũ… Nói chung là phải sạch, nếu không tìm ra được gì thì càng tốt.
Bước 3: Bạn apply như thế nào?
Bạn có thể apply trực tiếp trên trang tuyển dụng của công ty, hoặc các trang khác, nhưng cách mình khuyên đó là hãy apply qua 1 người quen đã từng hoặc đang làm ở trong VNG, vì nếu bạn pass phỏng vấn, đi làm thì người đó vừa có tiền bonus, bạn lại dễ dàng tiếp cận với người có nhu cầu tuyển dụng hơn, và có khi lại qua được vòng gửi CV.
Với 3 bước trên, 10% bạn đã thực hiện được rồi, còn 70% được thể hiện trong 3 bước nữa sẽ được trình bày trong phần tiếp theo. Nếu như bạn đã thực hiện các tip trên mà vẫn chưa được gọi đi phỏng vấn, đừng nản chí, chẳng qua là người ta chưa xứng đáng lọt vào mắt xanh của mình thôi 🙂 Còn bạn có 1 cuộc hẹn ở lầu 13 vào ngày thứ Hai thì thật tuyệt vời. Keep calm and enjoy the interview.
Tiếp tục ở phần 1, sau đây tôi sẽ hướng dẫn chi tiết cài đặt, cũng như cấu hình Anycast, OSPF, và Quagga để load balancing cho hệ thống. Chúng ta cùng xem lại mô hình:
Các máy chủ GW1 và GW2 đều chạy HDH Centos 7.2, dùng nginx làm Reverse proxy để load balancing cho các Web Server ở Backend. Phần cấu hình Reverse proxy và ở dưới Backend, tôi không đề cập trong bài viết này.
Cấu hình địa chỉ IP anycast + allow iptables trên GW1 và GW2
Config Anycast IP
Ta gán địa chỉ Anycast IPv4 cho card mạng, địa chỉ anycast có thể trùng subnet hoặc khác subnet với interface khác của server. Anycast thường được cấu hình trên interface loopbacks.
#ifconfig lo:2 172.30.27.219 netmask 255.255.255.255 up
#ifconfig
Cách cấu hình trên sẽ bị mất khi restart lại network, nếu muốn không bị mất, hãy vào /etc/sysconfig/network-script để tạo file cấu hình cho card lo:2.
Do chỉ sử dụng routing ospf, nên ta chỉ cần cấu hình zebra và ospfd, không quan tâm tới các daemon khác của quagga.
Tại GW1
Config Zebra
Khai báo các card mạng trong zebra.conf
#vi //usr/local/quaggaconf/zebra.conf
hostname GW1
log file /var/log/quagga/zebra.log
log stdout
log record-priority
!
interface eno16777984
ip address 172.30.27.47/32
!
interface lo
!
interface lo:2
ip address 172.30.27.219/32
!
ip forwarding
!
line vty
!
Config ospfd
Ospfd chỉ ra các trường của giao thức ospf. Ospfd cần phải lấy các thông tin trên zebra, vì vậy zebra phải chạy trước khi khởi động ospfd. Ngoài ra, nếu zebra khởi động lại, ospfd cũng phải vậy.
#vi /usr/local/quaggaconf/ospfd.conf
hostname GW1 log file /var/log/quagga/ospfd.log ! interface eno16777984 ip ospf hello-interval 1 ip ospf dead-interval 5 ! router ospf ospf router-id 172.30.27.47 redistribute connected network 172.30.27.0/24 area 172.30.27.0 !
Ở trên là các trường cơ bản để có thể routing ospf, các bạn có thể tìm hiểu thêm về giao thức ospf để cấu hình tuỳ theo nhu cầu của hệ thống, có thể thêm các tham số mã hoá MD5, cấu hình authentication, access-list…
[Service] Type=forking PIDFile=/var/run/quagga/ospfd.pid ExecStart=/usr/local/quagga/sbin/ospfd -d -A 127.0.0.1 -f /usr/local/quaggaconf/ospfd.conf Restart=on-abort
[Install] WantedBy=multi-user.target
Start zebra và ospfd
#systemctl daemon-reload
#systemctl enable zebra
#systemctl enable ospfd
#service zebra start
#service ospfd start
Thực hiện tương tự như vậy đối với GW2:
#vi /usr/local/quaggaconf/zebra.conf
hostname GW2
log file /var/log/quagga/zebra.log
log stdout
log record-priority
!
interface eno16777984
ip address 172.30.27.42/32
!
interface lo
!
interface lo:2
ip address 172.30.27.219/32
!
ip forwarding
!
line vty
!
#vi /usr/local/quaggaconf/ospfd.conf
hostname GW2 log file /var/log/quagga/ospfd.log ! interface eno16777984 ip ospf hello-interval 1 ip ospf dead-interval 5 ! router ospf ospf router-id 172.30.27.47 redistribute connected network 172.30.27.0/24 area 172.30.27.0 !
Tạo file systemd và start zebra, ospfd…
Cấu hình Router
router ospf 1
router-id 172.30.27.10
ip ospf hello-interval 1
ip ospf dead-interval 5
network 172.30.27.0 0.0.0.255 area 172.30.27.0
Sau đó vào GW1 và GW2 kiểm tra kết quả:
#/usr/local/quagga/bin/vtysh
#show ip ospf database
#show ip ospf neighbor
Các thông tin về ospf database và ospf neighbor đều hiện trên cả GW1 và GW2
Bây giờ, nếu có request gửi đến địa chỉ 172.30.27.219 hoặc một DNS name nào đó được trỏ tới IP trên, thì Router sẽ dựa trên ospf để tìm Server nào gần nhất, sau đó sẽ forward request đến đó.
Chú ý: Các giá trị hello-interval và dead-interval trên cả GW1, GW2 và Router phải bằng nhau. hello-interval là thời gian Server gửi gói tin hello OSPF cho Router và dead-interval là thời gian cập nhật lại bảng định tuyến của Router. Nếu không thấy bất kì gói hello nào được gửi tới nó trong thời gian dead trên, Router sẽ remove Server đó ra khỏi bảng định tuyên. Ngoài ra, các giá trị mtu của card mạng trên các thiết bị phải bằng nhau.
Nếu không thấy quá trình ospf thành công, có thể xem log file tại /var/log/quagga để biết rõ thêm hoặc comment bên dưới, tôi sẽ hỗ trợ các bạn.
Tôi tạm dừng phần 2 ở đây, trong phần tiếp theo, sẽ hướng dẫn các bạn monitor các daemon của quagga, cũng như control được quá trình quảng bá OSPF của quagga. Nếu các services (nginx…) ở GW bị lỗi mà quagga vẫn quảng bá ospf lên cho router, request vẫn được đẩy xuống GW thì không hợp lý chút nào đúng không? 😀
Đặt vấn đề: Cân bằng tải là một vấn đề muôn thuở đối với mọi hệ thống, đặc biệt là các hệt thống web server, api… Hiện nay, có nhiều cách để xây dựng một hệ thống cân bằng tải như HA proxy + Keepalived, Nginx + Keepalived.. Tuy nhiên, khi xây dựng các hệ thống trên, ta đều gặp một vấn đề chung là nếu sử dụng keepalived, một VIP được tạo ra, thì cùng lúc chỉ có 1 server Master chạy, server còn lại sẽ ở chế độ Standby -> Lãng phí tài nguyên.
Vậy, làm sao để cùng lúc các Server đều được sử dụng ?
Anycast’ing là một phương thức rất hay, kết hợp với OSPF và DNS giúp ta có thể giải quyết vấn đề ở trên.
Trước tiên, ta đi tìm hiểu các định nghĩa về anycast, ospf, và phần mềm định tuyến quagga.
Anycast: Là từ một nguồn có thể truyền tin tới một host gần nhất trong một nhóm các host được cấu hình cũng một địa chỉ IP. Sự khác nhau giữa anycast và multicast là thay vì chuyển tới tất cả các host trong nhóm, thì gói tin sẽ chỉ được chuyển tới host gần nhất trong bảng định tuyến. Đồng thời ở anycast, các host đều được cấu hình chung một địa chỉ Anycast giống nhau. Có thể hiểu thông qua mô hình sau:
Anycast được sử dụng để quảng bá một địa chỉ IP từ nhiều node khác nhau trong hệ thống mạng, với sự linh hoạt của giao thức dynamic routing, các gói tin sẽ được gửi tới node gần nhất.
Có thể ứng dụng Anycast trong một trường hợp cụ thể như sau: Một địa chỉ Anycast duy nhất sẽ được gán cùng lúc cho nhiều máy chủ cung cấp dịch vụ, các bộ định tuyến sẽ thực hiện công việc chọn đích đến tốt nhất và gần nhất, sau đó forward gói tin tới server đích đó.
IP Anycast thường được sử dụng hơn, nó được sử dụng cho dịch vụ DNS. DNS là một giao thức phản hồi duy nhất, không quan trọng response từ máy chủ. Vì DNS sử dụg UDP, không cần phải xác thực việc kết nối như TCP.
Anycast không được thiết kế để loadbalancing, mục đích chính của nó là giảm độ trễ và dư thừa khi định tuyến. Tuy nhiên phụ thuộc vào cách cấu hình, anycast có thể loadbalancing nhẹ.
Thêm một IP anycast của một domain vào hệ thống khai báo DNS, sau đó có thể sử dụng các giao thức định tuyến như RIP, OSPF hoặc BGP.
Cần có các phần mềm định tuyến hỗ trợ việc cấu hình các giao thức trên dưới Server như Quagga Routing.
Giao thức OSPF
OSPF – Open Shortest Path First là một giao thức định tuyến link-state. Mỗi khi router chạy giao thức sẽ gửi các trạng thái đường link của nó cho tất cả các router trong vùng (area). Các gói tin LSA (Link State Advertisement) được quảng bá cho các Router khác. Sau một thời gian trao đổi, các router sẽ đồng nhất bảng trạng thái đường link (Link State Database – LSDB) với nhau, mỗi router sẽ có bản đồ mạng của cả vùng. Từ đó chạy giải thuật Dijkstra tính toán ra đường đi ngắn nhất.
OSPF cos AD = 110
Metric (cost) được tính theo bandwith trên cổng chạy OSPF
Chạy trên nền IP, protocol number = 89
Các bước hoạt động OSPF:
Bầu chọn Router – id.
Thiết lập quan hệ láng giềng (neighbor).
Trao đổi LSDB.
Tính toán xây dựng bảng định tuyến
Quagga Routing
Quagga là một phần mềm routing mà nguồn mở, cung cấp cách hỗ trợ triển khai OSPFv2, OSPFv3, RIP và BGP-4 trên các nền tảng Unix như FreeBSD, Linux, Solaris and NetBSD.
Kiến trúc của Quagga gồm một core daemon, gọi là zebra. Zebra có nhiệm vụ giả lập như một router, thực hiện quản lý, update các giao thức định tuyến và truyền thông định tuyến. Ngoài ra còn có các daemon khác quản lý giao thức định tuyến được liệt kê như trên ospfd, ripd, bgpd…
Quagga được cấu hình thông qua một giao diện dòng lệnh CLI (gọi là ‘vty’). Ngoài ra có thêm công cụ ‘vtysh’, giúp quản lý tập trung các hoạt động của Quagga daemon.
Sau đây là mô hình thực tế của hệ thống loadbalancer của chúng ta như sau:
Ở phần hai, tôi sẽ hướng dẫn chi tiết về việc cấu hình Anycast, OSPF, và Quagga để load balancing cho hệ thống.
+ Kafka: hệ thống hàng đợi dữ liệu (message queue) phục vụ chức năng thu thập dữ liệu đầu vào (stream ingestion system).
+ Kafka là một hệ thống xử lý hàng đợi theo cơ chế publish-subscribe; Kafka còn hỗ trợ triển khai hệ thống thu thập log theo mô hình phân tán (distribute), phân chia (partition), và đồng bộ (replicate). Mã nguồn Kafka được thiết kế cho việc xử lý dữ liệu lớn khi đọc/ghi dữ liệu, giảm độ trễ trong quá trình truyền tải dữ liệu.
+ Kafka có thể hiểu là một hệ thống logging, nhằm lưu lại các trạng thái của hệ thống, nhằm phòng tránh mất thông tin.
2. Kiến trúc tổng quan về Apache Kafka
Kafka lưu, phân loại message theo topics
Kafka sử dụng producers để publish message vào các topics ở trên
Kafka sử dụng consumers để subscribe vào topics, sau đó xử lý các message lấy được theo một logic nào đó
Kafka thường được chạy dưới dạng cluster, khi đó mỗi server trong đó sẽ được gọi là broker.
Topic
Topic có thể hiểu là một ngôn ngữ chung giữa producer (người nói) và consumer (người nghe, sử dụng).
Với mỗi topic, kafka sẽ duy trì thông qua partitioned log như dưới đây:
+ Kafka cluster sẽ lưu lại mọi message đã được published, cho dù message đó đã được/chưa được sử dụng (consume). Thời gian lưu message có thể tuỳ chỉnh được thông qua log retention.
Một điểm thú vị là Consumer sẽ điều khiển những gì mình muốn đọc thông qua offset của message, hay thậm chí là thứ tự đọc. Consumer có thể reset lại vị trí của offset để re-process lại một vài message nào đó.
Producer
Như đã nói ở trên, producer nhằm mục đích chính là ném message vào topic. Cụ thể hơn là producer có nhiệm vụ là chọn message nào, để ném vào partition nào trong topic. Nhiệm vụ này rất quan trọng, giúp cho kafka có khả năng “scale” tốt.
Consumer
Thông thường thì một hệ thống messaging sẽ có 2 loại
Queue: Một message sẽ được xử lý bởi một consumer
Pub/Sub: Một message sẽ được xử lý bởi một vài consumer thích hợp, tuỳ theo topic
Ở kafka chúng ta có một khái niệm gọi là consumer group giúp chúng ta có thể làm được đồng thời cả 2 loại trên, rất thú vị. Việc subscribe một topic sẽ được thực hiện bởi consumer group. Mỗi một message sẽ được gửi cho duy nhất một consumer instance trong một consumer group. Việc này dấn đến điều gì?
Nếu nhiều instance consumer có cùng group: chúng ta sẽ có một hệ thống queue
Nếu mỗi instance là một group, chúng ta sẽ có một hệ thống pub/sub
Kafka đảm bảo
Message được gửi bởi producer đến một topic partition nào đó sẽ được đảm bảo thứ tự , thông qua offset
Consumer instance sẽ nhìn thấy message theo đúng thứ tự trong log
3. So sánh apache kafka với rabbitMQ
RabbitMQ
What it is?
RabbitMQ is a solid, mature, general purpose message broker that supports several standardized protocols such as AMQP
Apache Kafka is a message bus optimized for high-ingress data streams and replay
Primary use
High-throughput and reliable background jobs, communication and integration within, and between applications.
Build applications that process and re-process streamed data on disk
License
Open Source: Mozilla Public License
Open Source: Apache License 2.0
Written in
Erlang
Scala (JVM)
Client libraries
Many mature libraries, including: Ruby, Python, Node.js, Clojure, Go, Java and C
Many, including: Ruby, Python, Node.js and Java
Support for HA
Yes
Yes
Federated queues
Yes
No
Complex routing scenarios
Yes
No
Scaling strategies
Mostly vertical
Built from the ground up with horizontal scaling in mind
