Messages posted by: bntix

trantien và bntix là hai người khác nhau.

trantien là mem trên arsenal.com.vn . Vì lo lắng cho security của arsenal.com.vn nên nhờ check giùm sau đó gửi email alert cho bntix. Bntix nghĩ chắc các bác bên HVA check giùm nên vào đây tìm topic này reply để cảm ơn.

@conmale + Jal
2. Chịu ! Cứ detect là block ngay.

@conmale + gamma95

5. 2.0.4 ---> Chắc ko update nữa. Chờ chuyển vBulletin dùng luôn. Ngày nào cũng có mail alert attack SQL Injection mà. Chắc tại may mắn nên chưa thấy bị dính. smilie

Cảm ơn Conmale đã check giúp.
1. Server này gần như dedicated vì hầu như chỉ có site này chạy.
2. Brute force dưới bất kì hình thức nào đều bị block IP.
3. DNS thì đang kiểm tra lại.
4. FTP đã fix manual
5. Forum dùng IBF 2.0.4 (chưa update bao giờ)
6. Site thường xuyên bị DoS. Tháng nào cũng bị bắn nên anh truy cập vào thấy chậm là phải.
7. Blind SQL injection ---> Pls check again smilie

Nếu số khách hàng (website) dự phỏng là 1,000,000 và số người viếng không thay đổi (100 / 1 ngay) thì số người viếng tổng cộng là: 100,000,000 mỗi ngày. Bởi thế lượng người truy cập mỗi lần (concurrent) xấp xỉ:
100,000,000 / (24 * 60 * 60) = 1,157 người truy cập mỗi giây.

Với mỗi trang là 100K thì tổng số băng thông sử dụng cho mỗi giây là:
1,157 x 100K = 115,740K # 115Mb

Trong khi đó, tổng số băng thông là 250Mbit / 1000 = 31.25Mb

Cho thấy: băng thông thiếu trầm trọng (băng thông có sẵn chỉ có thể đáp ứng 27.17% tổng số nhu cầu).

Chỗ này mình quên nói là 250Mbps cho mỗi cabinet. Và cơ sở hạ tầng hiện tại đặt tại level 3 để phục vụ cho nhu cầu của lượng khách hàng tại US/Ca và khu vực Bắc Mỹ nói chung. Và lượng khách hàng tại khu vực này là 250.000 khách hàng sau một năm. Một năm sau khi đã đạt tới con số khả kiến thì các cụm server sẽ được đặt thêm tại một số tiểu bang khác.

Ý bồ là các cụm máy chủ này được đặt đúng vị trí địa lý? Hay đặt trong dải IP được ấn định cho từng vị trí quốc gia để rút ngắn số hops (để truy cập nhanh hơn)? Tớ không hiểu rõ câu này cho lắm.

Ban đầu thì mình dự định là đặt tại đúng các vị trí địa lý này. Tuy nhiên sau này thì có cân nhắc giải pháp rút ngắn số hops để truy cập nhanh hơn. Lý do là mình lo lắng điều kiện cơ sở hạ tầng của các Data center ở các nơi này ko đáp ứng được và việc chia sẻ dữ liệu ở các data khắp nơi trên thế giới là khó khăn hơn việc tập trung và rút ngắn hops.

Riêng với câu "cấu trúc dữ liệu giống nhau", ý bồ là cấu trúc ở tier nào? layer nào? ở CSDL hay ở filesystem (trên SAN chẳng hạn)? Hay ý bồ là các website này sử dụng chung một cụm máy chủ database?

Cấu trúc dữ liệu giống nhau ở tất cả các tier. CSDL và Filesystem. Việc sử dụng cùng một cụm máy chủ đang còn được cân nhắc nhiều vì sợ khả năng đáp ứng của hệ thống máy chủ DB đó. Và grid computing, parallel computing là ở hệ thống máy chủ DB này.

Còn như commale nói, thì việc xử lý ở các app server cần 1 giải pháp vừa High Performance (Load Balancing) vừa High Avaibility (Redundancy). Mình đồng ý.

- việc tìm kiếm và chia sẻ dễ dàng và nhanh chóng phụ thuộc phần lớn vào ứng dụng trên application. Ngoài ra, tìm kiếm là tìm kiếm ở giới hạn nào? và chia sẻ là chia sẻ giữa... cái gì? Nhu cầu tìm kiếm nhanh tựu trung ở "seek time" và cốt lõi của vấn đề nằm ở I/O: input / output trên disk và input / output xuyên qua đường truyền là chính. Việc xác định CPU cho mục đích computation là bao nhiêu phụ thuộc vào đòi hỏi "tìm thế nào" và "chia sẻ thế nào". Tớ không thể nói sâu hơn ở điểm này vì thông tin bồ cho quá tổng quát.

Việc tìm kiếm này hoàn toàn trên 1 hệ thống máy chủ cơ sở dữ liệu. Ngoài việc tối ưu ứng dụng (trên app như commale nói) search engine, việc tối ưu hệ thống chính là nhằm đáp ứng cho tiêu chí seek-time. Mình nghĩ tới hệ thống có nhiều hơn một cụm máy chủ phục vụ database. Mỗi cụm máy chủ phục vụ này là một grid computing phục vụ cho việc tìm kiếm dữ liệu ngay trên nó. Ứng dụng đưa ra một interface giao tiếp với người dùng và request của người dùng sẽ được tìm kiếm trên các cụm máy chủ này.

- việc "không cho phép dịch vụ ngưng một phút nào" ấn định SLA (service level agreement) là 100% hay 99.99% hay 99.98% cho mỗi tháng? Nếu SLA này là 100%, grid computing không hẳn là giải pháp. Cái bồ cần là một hệ thống "fully redundant", "fully load-balanced"

Agreement của công ty đặt ra là 100% uptime. Nghe có vẻ hoang tưởng nhưng trên thực tế là Google đã thực hiện được việc đó.

Khi nói đến một hệ thống như thế này, bồ nói đến khả năng load-balanced và fail-over cho từng tier một trong trọn bộ cấu trúc của các máy chủ (hoặc cụm máy chủ). Ví dụ:
Internet --> border router --> reverse proxy tier --> web tier --> app tier --> data tier

Trọn bộ phần màu cam đi vào phải hoàn toàn load-balanced và fail-over. Bất cứ tier nào không đủ khả năng này, SLA 100% không thể thực hiện được.

Đồng ý! Rõ ràng là bất cứu tier nào gặp trục trặc đồng nghĩa với việc SLA 100% là không thể. Loại bỏ tier liên quan tới nhà cung cấp dịch vụ (Internet, Border Router) thì các tier còn lại chính là phần công việc cần phải được đáp ứng 100% uptime.

Với nhu cầu fully redundant, fully load balanced để thoả mãn "không được down bất cứ phút nào" thì kinh phí ở trên không cách gì đủ. Bồ phải tự lo UPS system luôn? tự lo router, tự lo firewall, tự lo SAN solution? Ở đây mình chưa bàn sâu hơn SAN sẽ được thiết kế thế nào để bảo đảm up-time, để thích hợp với chiến thuật backup và recovery (cái này đòi hỏi một phần rất lớn của kinh phí).

Mình không định build 1 datacenter. UPS system, router sẽ được nhà cung cấp dịch vụ triển khai khi đặt colocation. Tuy nhiên có thể mình sẽ phải tự trang bị để phù hợp với yêu cầu của hệ thống. Các vấn đề còn lại như firewall, SAN hoàn toàn là phải tự lo. Mình có tham khảo một HPC của Sun, giá không dưới $100,000.

Tớ hiện đang hình thành một DR (disaster recovery) solution cho một môi trường có nhu cầu thấp hơn, số lượng máy và người dùng ít hơn. Nó chỉ dùng để "warm standby" cho hệ thống live hiện tại nhưng cho đến nay, giá thành đã đi đến con số xấp xỉ 1 triệu đô Úc.

Con số $500,000 là một con số dự trù, kinh phí này có thể tăng lên (tối đa $800.000). Kinh phí là một lý do tại sao mình có ý định là đầu tư cho anh em tự nghiên cứu về Grid để giảm chi phí và làm chủ công nghệ (Mặc dù có rủi ro).

Nên nhớ rằng nhu cầu fully redundant, fully load balanced đồng nghĩa với "everything times 2" (at least) ).

He he he, chính xác. Theo kế hoạch mà mình đang dự trù thì dữ liệu sẽ được lưu trữ tập trung trên 1 hệ grid (đã đảm bảo việc redundancy) để đáp ứng nhu cầu tìm kiếm. Còn lại App + web tier sẽ đơn giản là các node (mỗi node 2) vừa load balancing vừa redundancy.

Một khi bồ dùng chữ "plug" các máy chủ vào thì nó tương đương với "thêm CPU". Trọn bộ thông tin bồ cung cấp ở trên xoay quanh I/O throughput. Tớ chưa thấy có cái gì đòi hỏi CPU thật sự để nghĩ đến grid computing cả.

Search Engine chính là một yêu cầu chính để mình nghĩ tới grid computing. Với yêu cầu xây dựng một search engine search toàn bộ trên một hệ CSDL (nhiều Database với cấu trúc giống nhau hoặc tương đối giống nhau).

- Nếu bồ quan ngại về khả năng plug-able của CPU, bồ nên tìm hiểu về các mid-range của IBM hoặc của SUN. Chúng cho phép LPAR(ing) các CPU partition để thêm và bớt khi cần.

Mình có tham khảo midrange của SUN, chưa tham khảo IBM. Tuy nhiên các solutions của SUN là có giới hạn. Sun Fire E6900 hỗ trợ 24 CPU UtraSPARC 64bit 1.8Ghz với 48 luồng. Hạn chế của nó là mình phụ thuộc hoàn toàn vào công nghệ của SUN. Từ OS, App, Hardware .....

- Nếu bồ quan ngại về storage, SAN solution nào cũng cho phép bồ plug thêm dung tích cả.

Plugin dung tích không đáng ngại bằng khả năng đáp ứng của SAN cho các node tìm kiếm trong hệ máy chủ tìm kiếm. Mình nghĩ giải pháp của SUN/IBM với 56TB là dư dả cho hệ thống.

- Với nhu cầu "đồng bộ", tớ không thể khai triển thêm ngay lúc này vì tớ muốn biết lý do tại sao phải đặt servers ở các vị trí địa lý khác nhau?

- Ban đầu dự định đặt tại nhiều nơi nhưng vì lí do cơ sở hạ tầng và yêu cầu chia sẻ, mình sẽ chọn giải pháp đặt tập trung tại Level 3.

Thân.

conmale wrote:

Chủ đề này rất lý thú. Tuy nhiên, bồ mới chỉ đưa ra nhu cầu mà chưa đưa ra mức kinh phí cho phép nên không thể khai triển được chủ đề. Ngay cả nhu cầu bồ đưa ra cũng chưa cụ thể mức "critical" của system là thế nào nên khó có thể hình thành giải pháp được.

Một giải pháp thích hợp phải thỏa mãn một nhu cầu cụ thể.

Thân mến.

Hi commale, nghe danh đã lâu, giờ mới hân hạnh được reply bài.

Mình định gợi vài điểm cơ bản trước xem mọi người phản ứng thế nào đã. Vì chủ đề này có lẽ là khó nuốt nên sẽ ít người để ý.

Xem như chưa đề cập gì tới HPC, grid, parallel hay load balancing để mọi người không đi vào lối mòn đã vạch sẵn. Mình chỉ tập trung nhìn nhận lại yêu cầu đề bài một cách chi tiết và đầy đủ hơn để mọi người dễ hình dung.

idoDream (một công ty tưởng tượng) là một công ty truyền thông có trụ sở đặt tại San Francisco. Công ty có một lượng khách hàng lớn trên toàn thế giới. Số lượng khách hàng hiện tại là 25.000 khách hàng. Và lượng khách hàng này tiếp tục tăng và dự kiến sẽ đạt con số 1 triệu khách hàng sau 1 năm.

Các web site khách hàng của idoDream có lượng truy cập trung bình 100 visitor/day. Mỗi visitor request 10 page. Mỗi page trung bình có size là 100KB. Các web site này có cấu trúc dữ liệu giống nhau.

IdoDream đã thuê 10 cabinet (1 cage) tại Level 3 Network mỗi cabinet là 40U, connection type là OC3 = 250Mbps.

Khi cung cấp cho thị trường ở Châu Âu, Châu Á mà đặc biệt là Trung Quốc, thì các cụm máy chủ sẽ được đặt rải rác tại khắp nơi trên thế giới (Châu Âu = Đức, Châu Á = Nhật, Trung Quốc = Trung Quốc).

Công ty mong muốn dữ liệu của tất cả các web site tại các cụm máy chủ có thể tìm kiếm, chia sẻ dễ dàng và nhanh chóng. Do tính chất dịch vụ nên yêu cầu tối cần thiết là dịch vụ không được phép ngừng một phút nào.

Về kinh phí ban đầu khi setup tại Level 3, mức đầu tư cho cơ sở hạ tầng của hệ thống là $500,000 ( không tính phí setup, monthly fee của co-location ...). Và chi phí này chỉ tập trung vào hệ thống máy tính (hardware, license software, midleware, solutions, research ....).

Hệ thống được thiết kế phải đảm bảo dễ dàng plug-in các máy chủ vào khi hệ thống không chịu tải được lượng khách hàng tăng thêm. Dữ liệu từ Châu Âu, Châu Á, China và tại US (Level 3) là đồng bộ. Do đó hệ thống tại Level 3 phải được thiết kế sao cho khi triển khai ra ngoài US, các cụm máy chủ có thể chia sẻ dữ liệu dễ dàng. Đây là yêu cầu quan trọng thứ 3.

Như vậy tạm thời chúng ta đã có requirements sơ bộ của hệ thống ở Level 3. Mời các bạn tiếp tục mổ xẻ vấn đề.

@commale : thanks commale . Tưởng không ai mò vào! Giờ mời commale tiếp tục chỉ giáo. Mình xin được nghe.

Xin chào các bạn. Hiện tại bên mình đang có 1 dự án yêu cầu High Performance Computing.

Yêu cầu dữ liệu lưu trữ tập trung (NAS/SAN)để đáp ứng việc tìm kiếm tối ưu nhất về thời gian và chia sẻ cho các cụm máy chủ (tạm thời gọi vậy) ở trên toàn thế giới. Dự kiến mỗi cụm máy chủ sẽ đáp ứng cho khoảng 300.000 web site. Mỗi cụm sẽ có nhiều node tham gia.

Mô hình về lý thuyết mình định hướng sử dụng là grid computing, collaborative và parallel computing. Tuy nhiên có rất nhiều vướng mắc về midleware, về độ rủi ro ....(nếu tự nghiên cứu).

Nếu dùng một HPC của Sun, IBM hay Dell thì chi phí từ 85.000$ ---> 140.000$ và phụ thuộc hoàn toàn vào platform pre-installed trên các hệ thống của nhà cung cấp. Và việc thêm các node vào hệ thống là có giới hạn về performance, về cost .....

Theo các bạn thì có một giải pháp nào khả dĩ cho trường hợp của mình không?