Messages posted by: myquartz

Trừ khi đây là bài lập ra SEO trá hình. Đề nghị Admin xóa URL đến site kia là hết tác dụng SEO.

Còn bạn kinh doanh, không phải dân công nghệ, bạn đơn giản là thuê các đơn vị công nghệ chống tấn công hoặc làm dịch vụ cho bạn.

Cái của bạn link, là cài từ source, tự compile. Không theo cái đi kèm distro (mà apt quản lý). Cái này mới là phức tạp vì mỗi khi update lại phải làm lại.

Còn mình không hiểu là apt upgrade có gì phức tạp, trừ khi bạn có 1 module tự compile gắn vào cái kèm distro. Còn không thì:

apt-get update
apt-get upgrade
reboot (hoặc /etc/init.d/apache2 restart).

Thế là xong. Rất hiếm khi phải sửa chữa.

Mình thì hay dùng CentOS, với yum hơn, và nó đảm bảo sự tương thích với config/app khi ở cùng một phiên bản. Tuy là apache hơi cũ.

Dùng apt để cài đặt, cập nhật, gõ vài lệnh vậy mà kêu là khá phức tạp. Vậy config và make thì không?
Trong việc compile, make nó đòi hỏi tính tương thích về thư viện, phần mềm và việc này liên tục xảy ra mỗi khi có release mới. Vài vấn đề như bản cũ đang chạy (sau vài năm) thì không được vá lỗi nữa, còn nếu compile bản mới thì ứng dụng không chạy được do được thiết kế với bản cũ... chả nhẽ lúc đó không update?

Người ta nghĩ ra các công cụ apt và có đội ngũ vận hành compile make giúp bạn, chính là giải quyết sự phức tạp này cho system admin. Bạn có thể dùng một số bản phân phối khác.

Còn kiểu cài 1 lần và chạy mà không bao giờ update, không bao giờ thay đổi gì cả, đó là kiểu mà nhiều nhiều các bạn IT làm nghề quản trị ở VN đang làm và đây chính điểm để cho ngành bảo mật phải đau đầu, mã độc và khai thác lỗ hồng có đất sống khỏe.

connect to yahoo.com[206.190.36.45]:25: Connection timed out

=> máy chủ mail có kết nối được Internet không?

tuanksor wrote:

Cảm ơn myquartz đã tư vấn,
Về source code và tất cả content đều đặt tại 1 folder trên nfs mount, read lẫn write
1. Vì hiện nó đang vận hành, mô hình xuyên xuốt từ phía khách hàng đến cả phần quản lý, nên việc thay đổi như vậy mình thấy rất khó mặc dù là muốn thế
2,3. Đây là option mount nfs hiện tại đang sử dụng:
Code:
rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.0.x,mountvers=3,mountport=43882,mountproto=udp,local_lock=none,addr=10.0.0.x 0 0
trước có dùng option fsc và chạy cachefs nhưng mình bỏ do mình test đi test lại thấy vẫn như nhau k có tác dụng gì lắm.

bạn phải tuning/sửa lại ứng dụng PHP hoặc cách dùng module, sao cho phân rõ kiểu IO với từng module (read hay read/write) để dùng NFS cache được

mình k rõ ý này lắm, myquartz có thể tư vấn thêm ở cái đoạn này ko ?

Về mount options, không có gì nhiều để góp ý, trừ việc thay relatime thành noatime, nó sẽ giúp tiết kiệm 1 chút IO cho việc read-only.

Về ý mà bạn chưa rõ, thì nó đơn giản là phân rõ mục nào là read-only (ví dụ source code), mục nào lả read/write. Để có ứng phó và dùng các mount-point thích hợp cho từng dạng truy cập, không để chung code + static content + upload content vào chung 1 chỗ như cái nồi lẩu, sẽ rất khó. Một số dạng static content như ảnh, hay css ít bị thay đổi, thì nên read-only, nó sẽ tận dụng thế mạnh của nfs cache ở phía client.
Còn một số thư mục dành cho upload, thì việc tạo 1 thư mục chuyên cho upload (tạo riêng 1 mount point read-only để client tải từ web server cũng là nội dung upload đó) sẽ giúp tối ưu hóa IO hơn một chút.
Nếu content upload nhiều thì tốt nhất là quá trình upload sẽ write file vào 1 temp dir (ở local storage) rồi sau khi upload xong 100% content, thì làm lệnh move sang NFS, nó sẽ nhanh hơn nhiều là open và write trực tiếp file vào nfs share.

Việc sửa ứng dụng là mệt nhất. Nhưng nó sẽ mang lại hiệu quả tuyệt đối. Tóm lại tuân thủ nguyên tắc lập trình rõ ràng: file nào chỉ cần read thì open read-only trên mount point read-only. file nào cần write thì open write-only trên mount point read/write. Tránh tối đa mở file vừa read, vừa write, lẫn lộn.

Làm việc với NFS thì có mấy cái chú ý vậy thôi. Mấy bài toán web cỡ lớn đòi hỏi nhiều đầu tư về kiến trúc, mô hình hoạt động và ứng dụng thay đổi nhiều, nó không phải cái app nhỏ cho vào cái máy lớn để chạy đâu.

tuanksor wrote:

- Source code đặt tại NFS (mount nfs v3)

tuanksor wrote:

2. Mình có test qua performance giữa apache, php, local storage(1) vs apache, php, nfs storage(2) thì thấy performance (1) > (2), sử dụng strace php-cgi để count syscall khi chạy trên nfs thì thấy các syscall access, open có % lớn hơn khi chạy local storage (ở local storage thì syscall munmap lớn). Sử dụng cachefs & nhưng cũng không ăn thua. Nên có nghĩ đến việc đổi mô hình, nhưng mắc phải vấn đề sync, dữ liệu hosting rất nhiều. với lại đang là mô hình production, thay đổi thì chắc rất cực.
Mình tập trung vấn đề load avg tại web server do chỉ có 1 con server ấy bị, các con khác còn lại chạy bình thường

Có vẻ như 2 phần bôi đậm kia, kết hợp thông tin NFS v3 là vấn đề của bạn.
Ứng dụng của bạn khi chạy local storage nó sử dụng IO kiểu mmap/munmap, một kiểu IO có tốc độ cao và trễ thấp.

Khi mount với NFS v3, thì mmap không được hỗ trợ, phải fail-back về kiểu open/read bình thường (nên syscall 2 cái này nhiều hơn). Có vài thảo luận về vấn đề NFS liên quan đến mmap này.

Kể cả khi dùng open/read thì cũng có vấn đề. Do NFS là 1 share file system nên yếu tố concurrency được đảm bảo, chính nó gây nhiều overhead xử lý các IO, nhất là trong trường hợp read+write IO. Đó chính là nguyên nhân dẫn tới IO wait cao hơn local storage.

Bạn không nói rõ ngoài source code ra thì còn content nào khác (ví dụ images, css...) phải lấy ra từ disk không, ứng dụng chỉ source code/content read only hay cả read/write.

Vì thế, giải pháp là
1. bạn phải từ bỏ NFS, phải dùng local storage + sync.
2. bạn phải tuning/sửa lại ứng dụng PHP hoặc cách dùng module, sao cho phân rõ kiểu IO với từng module (read hay read/write) để dùng NFS cache được, (kiểm tra lại ứng dụng mount NFS dạng read-only và tùy chọn nolock, bật cache nữa).
3. Ứng dụng phải sửa hoặc NFS mount option phải chỉnh lại để truy cập IO tối ưu cho open/read, tránh locking hoặc cache-sync giữa các node mount lên NFS server.

Ref: Google 1 lúc thì ra khá nhiều thông tin liên quan đến NFS mmap. Ví dụ có 1 thảo luận:
http://stackoverflow.com/questions/10367577/mmap-file-shared-via-nfs

levutech wrote:

myquartz wrote:

Hay nhưng làm thành dịch vụ thì ... khó sống. Vả lại quy mô VN quá nhỏ để cần 1 cái đó

Mình không định triển khai cái này thành một service hay tương tự thế. Chủ yếu dùng cho các khách hàng của công ty mà thôi. Cloudflare không có hạ tầng tại VN nên nhiều khách hàng dùng Cloudflare thì phải đi đường vòng, trong khi không phải ai cũng chịu bỏ tiền để dùng pro plan của Cloudflare. Hơn nữa xây dựng từng hệ thống riêng lẽ như Firewall hay IDPS thì mình thấy đơn giản, nhưng kết hợp lại với nhau thì còn nhiều cái phải bàn quá.

Vậy bạn chỉ cần làm 1 Web App Firewall (hoặc gọi chính xác là HTTP Reverse Proxy), là đủ cho 1 site khách hàng.
Quy mô mạng VN không cần 1 CDN cho phức tạp, trừ khi các dịch vụ của bạn là download file thì có thể xem xét đặt mirror server 2 nhà cung cấp ở 2 đầu VN thì ổn rồi (mirror đơn giản hơn CDN gấp nhiều lần), rồi link ghi: HN down tại đây, HCM down tại đây, là xong.

Mình không rõ khách hàng của bạn có site quy mô thế nào, đạt peak băng thông ra sao, có HTTPS không, nhưng 1 HTTP Reverse Proxy, chỉ cần 1 server ngix khéo 1 chút nó có thể gánh được từ 1000-3000 request/s, băng thông đạt 300Mbit/s.

levutech wrote:

Topic này hay mà sao thấy ít bạn quan tâm đến topic nhỉ. Mình đang rất mong nhận được sự góp ý và chia sẽ ý kiến của những người có kinh nghiệm như anh conmale hoặc là quanta. Chắc các bạn cũng từng xây dựng những system như thế này rồi.

Hay nhưng làm thành dịch vụ thì ... khó sống. Vả lại quy mô VN quá nhỏ để cần 1 cái đó.

CloudFlare nó là cả 2 thứ kết hơp lại: CDN và Web App Firewall. Làm được như họ là khả thi nhưng giá thì khó mà rẻ hơn, quy mô nhỏ lại càng khó, đi mua cho nhanh. Hơn nữa nó không chỉ là vấn đề kỹ thuật. CloudFlare họ có contract với 1 số tier-1 ISP trên thế giới (hoặc tương tự thế) nên về mặt đường truyền mạng, họ có lợi thế cực lớn và không sợ DDoS là vì vậy.

CDN thì ở VN có lẽ chỉ vài nhà dịch vụ cung cấp nội dung như game online, video clip mới cần đến, do mạng VN nhỏ, VNIX cũng khá tốt đủ băng thông liên ISP rồi. Một điểm nữa những nhà cung cấp nội dung lớn cần đến CDN thì lại trực thuộc một ISP, họ thích gia tăng giá trị mạng ISP của mình hơn là đặt CDN cho nhiều khách hàng ở ISP khác, dùng nội dung để tạo lợi thế so với ISP khác. Kinh doanh nội dung độc lập ở VN khó sống được lắm.

HVA cũng có vài bài liên quan đến CDN, search google cũng nhiều và việc thiết lập nó nếu bạn nắm trong tay cả dịch vụ và CDN thì rất dễ dàng (sync content giữa các bên chẳng hạn).

Còn cái Web App Firewall, HVA cũng nhiều bài viết về cái này. Đủ xài cho một dịch vụ nội bộ.

tmlinhkct wrote:

mình xin đính chính chút là nếu cột id đã là primary key rồi thì không cần dùng WHERE... nữa mà chiến luôn:
Code:
select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd from content order by id desc limit 0,10

Câu lệnh này đáp ứng được tiêu chí viết gọn, đẹp nhưng đôi khi nó không chạy như thiết kế và xui xẻo mà developer thay đổi 1 chút thành "order by dateadd" (liệt kê tin từ cũ tới mới chứ không cho mới lên đầu), hoặc primary key không chỉ là id mà thêm category_id thì lúc đó sẽ rất chậm, viết xấu với mệnh đề WHERE sẽ an toàn hơn và không ảnh hưởng nhiều vì câu order by.

Do cáp quang biển ở Vũng Tàu đứt, nên dùng Google DNS bây giờ là thất sách, rất là chậm, dù là truy cập trong nước.
Lý do là hầu hết các hoạt động truy cập của trình duyệt đều đụng đến cái DNS, bình thường Google DNS ping chỉ khoảng 50ms, nay tăng lên gấp 6 lần thì chậm là phải.

Data Link layer là đóng gói ở dưới IP layer. IP datagram sẽ được gắn thêm header nào tùy thuộc vào kiểu vật lý ở bên dưới mà IP sẽ gửi đi (cụ thể là interface nào sẽ gửi đi).
Trường hợp gửi qua Ethernet (IEEE 802, 803) thì nó sẽ thêm Ethernet Header (trong đó có MAC address) rồi gửi qua Ethernet card.
Trường hợp gửi qua 1 serial line (kênh truyền kiểu điểm-điểm), thì SLIP hoặc PPP (hoặc HDLC) được sử dụng để đóng gói cho IP, nó không có và không cần MAC Address vì nó là cái ống dữ liệu, cho dữ liệu vào đầu này sẽ chắc chắn ra ở đầu kia không cần địa chỉ.
Trường hợp gửi qua những cái khác, ví dụ đóng Tunnel GRE chẳng hạn, thì là thêm GRE...
Tóm lại nó linh hoạt và tùy thuộc cái interface bên dưới mà gói IP sẽ truyền qua.

SLIP nó có header nhỏ hơn PPP và ít các control hơn PPP (ví dụ PPP có bắt tay xác thực, IPCP, keep-alive...) nên PPP nó làm tăng kích thước ít hơn, nhưng cũng sẽ bị thua thiệt các tính năng khác so với PPP.

Nên dùng raid 10 cho cả OS và DB. OS thì cũng ít dùng thôi. Raid array chung sẽ chia sẻ được tải log và datafile, chứ không thì có thể bị dồn vào 1 array 2 disk. (DB Log ghi rất ít tuy có đòi hỏi sự đáp ứng nhanh).

Bạn vncybernet nói đúng đó. Đó là ước chừng theo kinh nghiệm. Nó cũng do test thử nữa. Chức năng developer tool của trình duyệt Chrome hoặc Firefox, trong tab Network sẽ phân tích thời gian xử lý xong request khi bạn truy cập 1 URL, bao nhiêu cho network, bao nhiêu chờ web server.

Mình thấy khá hiếm người như bạn, có ý định tính trước vấn đề tải trọng và phần cứng như vậy. Như thế bạn đang thực hiện công việc người ta gọi là sizing, một việc nói chung là khó và không có công thức chung.

Tuy nhiên có vài nguyên tắc chung thế này:

- Để tính đường mạng, người ta dựa vào băng thông và kích thước trung bình của mỗi request (như web) hoặc mỗi người sử dụng. Cái này chắc không cần nói bạn cũng biết, ví dụ vào 1 web tốn mỗi lần khoảng 100KByte, đường truyền 160Mbps ~ 16MByte/s (đã trừ phụ phí) => 16000K/100K = 160 request/s. Như thế ra công suất mạng chịu được.

- Tính RAM: thường mỗi connection (session) kết nối và chạy sẽ tốn bao nhiều MB RAM (cái này monitor hoặc đo đạc các web process là ra, ví dụ ta được con số là 4MB/session chẳng hạn. Mỗi request (tốn 1 session) sẽ xử lý trung bình trong vòng 3s, vị chi là mỗi giây máy 32GB RAM của bạn, trừ đi OS và các thứ linh tinh, ví dụ là 4GB, còn ra 28GB = 28000MB/4MB RAM = 7000 session đồng thời, chia cho 3s => 7000/3 = 2300request/s. Vậy là ra số cho RAM, nhưng cái này phải chú ý cái thời gian xử lý, thời gian đợi client... cả 7000 session cùng lúc có thể xử lý không phải là 3s mà là 10s thì số request/s giảm đi rất nhiều.
- Tính tải CPU: Cái này khó nhất. Người ta thường phải dùng cái gọi là stress test để thử tải. Cách làm là dùng công cụ giả như client, kết nối đến server và tạo thật nhiều request với số lượng session tăng dần tới ngưỡng đã tính với RAM ở trên, kết hợp với công cụ monitor tải (CPU/RAM/IO) của server ngay tại lúc đó. Nếu tất cả các core của CPU đạt 100% ở 1 số lượng session nào đó, không tăng hơn được, hoặc đạt ngưỡng session rồi mà CPU cũng chưa hết 100% (nhưng tăng nữa session thì hết RAM), hoặc vấn đề có khi lại ở HDD, IO chạy busy 100% rồi mà RAM/CPU vẫn còn dư. Thường công cụ này làm test trong mạng LAN nhanh, để giảm ảnh hưởng của mạng (chắc là cần nhanh hơn 160Mb/s, 1Gbit ok rồi), dùng nhiều client cùng chạy (tập trung chục cái PC vào cùng chạy chắc dư sức đạt 7000 session), chạy khi không có ai khác sử dụng server để chính xác hơn. => đo và đây là giá trị cuối cùng.
Giá trị này nó tùy thuộc rất nhiều vào ứng dụng, database, đĩa, CPU, nhiều yếu tố khác... Ví dụ bạn đo và đạt được 1000req/s với 7000 session cùng lúc chẳng hạn.

Khi xong, đó gần như là con số cuối mà server của bạn chịu được. Từ đó bạn thiết lập rào cản limit... để không cho vượt quá ngưỡng đã test đó. Mạng có thể nghẽn trước, hoặc server có thể quá tải trước, tùy nhưng nói chung ta biết ngưỡng của cả 2 thứ để liệu. Nếu mạng phù hợp (160request/s hơi thấp so với 1000 của server), bạn có thể tăng đường mạng lên hoặc giảm tải dữ liệu, nén dữ liệu khi truyền... (100K xuống 50K thì số request sẽ gấp 2). Rồi lại test lại.... Xong.

Nhìn cái email không muốn gửi CV luôn.
Ngân hàng gì mà bộ phận tuyển dụng hoặc người tiếp nhận lại phải dùng Yahoo thế.

Do IO bị quá tải. 12.1 wa = 12.1% IO wait.
Xem hình dưới thì thấy tuy read/write KB chỉ là 1.5/1MBps thôi, nhưng tps là khoảng 70tps - 2 sda và sdb giống nhau có thể disk tripe với md2 - tps như thế khá cao nếu là ổ SATA thông thường => chứng tỏ random IO rất nhiều.

Tiếp là kiểm tra cái gì gây random IO nhiều như thế, phải xem các process. Nếu chạy mysql database có thể chính là cái này. Tập trung tiếp vào đó để giải quyết.

Nếu có thể ngưng sử dụng máy vài ngày, thì cài cái memtest (có trong centos). Sau đó khởi động lên chọn nó trong danh sách boot.
Cho nó chạy vài ngày hoặc có khi vài giờ là sẽ ra thôi, bad chỗ nào nó sẽ chỉ.

Có vẻ như ram server của bạn lỗi. Nó báo phải correct rrast nhiều. Ram kém tin cậy là 1 trong những nguyên nhân phổ biến khiến server hay bị panic.

Như cái hình header thì là ok. Kiên nhẫn bạn à. Một thời gian sẽ tự hết. Google spam filter nó dựa vào nội dung là chính để phân loại spam chứ phần SPF hay DKIM chỉ một phần. Nếu nhiều user gmail nhận mà đánh dấu "not spam" riết là nó sẽ điều chỉnh.

Giờ vẫn còn xài telnet + http để quản trị từ xa thì đúng là bó tay, nhất là với con FW. Đổi sang ssh và https đi mới tạm đủ an toàn.
Việc bị "mò" mật khẩu thế này, cách đơn giản nhất là hạn chế source IP hoặc Interface được phép remote vào (= với việc kêt nối). Trong Netscreen có chỗ trong Interface là tùy chọn Management, chỉ bật với các Interface chỉ định. Phần service cũng thế, chỉ define những Allow Source Subnet mà được phép kết nối tới.
Thế là xong.

henryhuy wrote:

Xin gừi bác cấu trúc table của mình như sau :
1 id int(250)
2 content_id varchar(250)
3 content_category_id varchar(255)
4 title text
5 sub_title text
6 detail longtext
7 image varchar(250)
8 idlang varchar(250)
9 show_content int(2)
10 dateadd datetime

Câu lệnh SELECT mỗi lần lấy tin mới nhất của mình thế này : "select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd from content order by id desc limit 0,10"

Nếu muốn tạo INDEX thì mình làm thế nào, sorry mình hỏi hơi kỹ vì chưa làm INDEX lần nào cả

Mình có đọc 1 số tut trên mạng thì hướng dẫn là ALTER TABLE content ADD INDEX idx_id(id); nhưng mình không rõ là khi nào nên ALTER TABLE cả, có phải là mỗi lần select 10 tin mới ra chăng ?

Cảm ơn các bác nhiều.

Ợ. Vậy là bạn học lập trình SQL mà không học về ... index của CSDL, một thứ quan trọng sống còn của nó (mặc dù hệ thống vẫn chạy khi không có nó), có thể đây là sự thiếu sót không chỉ mỗi bạn mắc phải đâu.
Cột ID của bạn có phải là primary key? nếu là primary key rồi thì không cần index nữa vì nó đã được index rồi (primary key là 1 dạng index, với thuộc tính unique). Việc tạo index chỉ 1 lần kèm với tạo bảng, và thi thoảng thì phải bảo dưỡng nó thôi (analyze table), alter table là nhóm DDL như create table...

Nếu cột ID của bạn là số tăng dần, mỗi bài tin là tăng 1 đơn vị, bạn lấy 10 tin mới nhất thì sửa 1 chút thế này:

select id, content_id, content_category_id, title, sub_title, image, idlang, show_content, dateadd from content where id >= (select max(id)-10 from content) order by id desc limit 0,10

Nếu lo ngại có sự delete trong content, gây lỗ thủng id, thiếu, thì max(id) - 10 thay bằng - 20, - 30... thậm chí 100 vẫn là rất tốt cho bảng. nó đảm bảo rằng dù bảng có tăng kích thước lên thì tốc độ vẫn không thay đổi nhiều.

henryhuy wrote:

Cảm ơn bác đã phản hồi, mình muốn hỏi thêm là nếu 1 table có 1000 record và 1 table 10000 record thì tốc độ load dữ liệu có khác nhau không nếu mình có limit và order ?

Khác nhau 10 lần, nói chung đa số trường hợp nếu câu chỉ có limit và order thôi thì sẽ không sử dụng đến index (kể cả order trên cột đã index).

MySQL luôn order trước (tức nó lấy hết 1000 hay 1 vạn, 1 triệu ra sort), rồi limit. Phép toán sort là phép toán đắt tiền nên sẽ chậm.

Chỉ cần nhớ đến 1 điều này: index chỉ được đụng đến khi cột nó trong where và tên cột được index đó đứng duy nhất một mình bên vế so sánh (=, <, > hoặc between), không có hàm hoặc bất cứ công thức nào, cũng không có cột nào ở vế còn lại.
Ví dụ id=xx hoặc id<=xx sẽ dùng index, nhưng left(id,5) = xx thì không (do id không đứng một mình ở vế đó).
Hoặc id (là số), ta viết thế này: id >= 5 (cái này có) thì khác hoàn toàn với id - 5 >= 0 (cái này không dùng index).
Thế này cũng không index: id >= max_id - 5 (trong đó 2 cột id và max_id cùng 1 bảng, nếu max_id ở bảng khác thì phải có điều kiện where với bảng đó nữa).

Bạn có thể dựa vào một số chuẩn bảo mật, ví dụ như mình biết thì mấy phần cơ bản của PCI DSS là khá ổn.
Còn lại dựa vào các guide hoặc recommend có nhiều trên internet, làm đúng và tuân thủ đúng sẽ đủ tốt cho hệ thông. Mình có thể đưa ra ví dụ:
- hệ thống có chính sách mật khẩu không? Có sử dụng user, mật khẩu mặc định như nhà sản xuất đặt không? Quyền cấp cho user hoặc apps có quá thừa so với cần thiết không? Có dùng chung user có quyền quản trị, root, super giữa người này người kia không?
- firewall có được thiết lập đúng các service, pỏt và address cung cấp ko? Có rule nào dạng any ip to any port ko?
- remote admin có giới hạn không? Có đăng nhập trực tiếp hay được giới hạn? Có root login trực tiếp?
- các OS có thực hiện theo một mẫu security hảdenning cụ thể ko?
- các db, web app có được hardenning ko? Có bật hoặc cài thừa các phần mềm không cần thiết đối với máy hoặc dịch vụ chỉ ra không?
- thông tin nhạy cảm có được mã hoá khi truyền hay lưu không? Ví dụ password là thông tin nhạy cảm.
- quá trình hoạt động dịch vụ và OS có được ghi log sao cho không xoá được không? Có được đồng bộ thời gian theo một mốc chuẩn không? Ghi log không xoá được có thể là tập trung log tại một server riêng chỉ làm việc lưu log, các server khác gửi về đây, ko gửi lệnh xoá được.
- appp viết có trả qua quá trình review code không? Có security test qua theo một tiêu chuẩn ví dụ owasp không?
- các dịch vụ và app có được thực hiện pen test định kỳ hoặc trước khi release không?
- tất cả software, firrmware có được security update, patch theo khuyến cáo nhà sản xuẩt phần mềm và không cũ quá 7 ngày khi patch release không?
- phần cứng có được đảm bảo an toàn vật lý, có khoá hoặc phòng giới hạn người vào không?
- có ai chuyên trách ngồi đọc log phán tích bất thường ko? Có đội phản ứng nhanh security ko?

Nếu một trong những cái trên trả lời không tức không thoả mãn. Check list này làm lặp đi lặp lại định kỳ hoặc khi có thành tố mới, được update. Bạn áp dụng owasp là đúng và nó áp dụng cho web apps ở khâu pen test, security code review và test.

invalid-password wrote:

Nếu bạn không phải là người nghiên cứu về các lỗ hổng mà chỉ là người quản trị, đảm bảo an toàn mạng thì bạn chỉ cần biết rằng hiện nay đang có một cái lỗ hổng gọi là HeartBleed, nó ảnh hưởng tới những cái gì-hệ thống nào, và cần làm gì (patch, update) để khắc phục nó, hết.

Mình thì mình không nghiên cứu về các lỗ hổng, đọc thì nhức đầu, mà cũng không dùng làm gì cả, lại mau trôi qua và chìm vào quên lãng, nên mình không đọc Mình cũng làm về sờ-cu rờ-ti (security) nè, việc của mình chỉ đơn giản là cài patch, sau đó lãnh lương. Nghề bảo mật thật là đơn giản !

Ủng hộ bạn này. Nghề bảo mật thật ra là: 95% nhân sự chỉ cần làm đúng những quy tắc được 5% còn lại đề ra, phải làm và làm một cách nghiêm túc, dù nó lặp đi lặp lại nhàm chán và vô vị...
Thời gian rảnh còn lại là để đọc báo, trăm thứ bà rằn từ chân dài, cổ dài hay chính trị, quân sự, tán tỉnh, lừa đảo cướp giết hiếp, hoặc cả viết văn hay làm thơ, kể chuyện kiếm tiền dễ thế nào qua email...
Tuy vớ vẩn nhưng nó là ... công việc. Một ngày đẹp trời đọc báo CAND thấy vụ cướp giật laptop của một chân dài làm rách hết áo quần trên đường CMT8 :-D, thế là hôm sau công ty ban hành chính sách mã hóa laptop, rồi lụi cụi đi đến từng em và ... năn nỉ cho lấy laptop để làm mã hóa.

Về cơ chế MMU thực sự (tức là sự triển khai), các bạn có thể ngâm cứu cách Linux kernel quản lý, hoặc đơn giản hơn là lấy source hệ điều hành đơn giản FreeDOS về ngâm cứu về khái niệm. Nó là sự triển khai của ý tưởng mình đã mô tả mà thôi.

Còn về xử lý song song, nếu là đa lõi hoặc đa bộ xử lý, thì nó song song thực sự giữa các CPU/core với nhau, và vẫn "giả" song song với 1 core. Ví dụ nếu máy bạn có 4 core, mà có 4 chương trình cùng chạy, thì lý thuyết là OS sẽ phân đều cho 4 core, và thực sự 4 chương trình này chạy song song nhau (không chia chác gì). Nếu có nhiều hơn, ví dụ 8 chương trình, thì từng cặp 2 cái một sẽ là giả song song trên 4 core (phải chia slot mỗi core cho 2 cái), và 4 core vẫn là song song nhau. Việc này tăng sức mạnh tính toán lên rất nhiều, nên CPU nhiều core mới thay thế loại cũ 1 core. Tất nhiên nếu chỉ 1 chương trình chạy thì cũng chỉ 1 core chạy, 3 core kia ngồi chơi.

Việc xử lý song song thật sự nó cũng có cái giá của nó, một chương trình không chỉ chạy các lệnh, mà còn truy cập tài nguyên khác, việc chạy song song kéo theo là việc xử lý xung đột tài nguyên (bộ nhớ, đĩa vào ra, cổng vào ra...) khi cả 2 cùng dùng đến 1 cái chung nhau. Có hẳn một chương dài về cái này (tiếng Anh nó là process synchronization in operating system), phải đọc thì mới hiểu rõ hơn.

Xử lý song song không chỉ thời 64bit mới có, mà thời 32bit máy chủ với nhiều bộ xử lý (dạng SMP) đã có và hoạt động. Và OS phải hỗ trợ mới tận dụng được không thì chỉ thấy 1 CPU thôi (Windows NT, 2000 hoặc Linux, tất nhiên UNIX thì có từ lâu lâu rồi).

select ra gồm những tình huống nào? và điều kiện dự định là gì? Thì tổ chức bảng tin theo cách đó và đánh index như thế.
Ví dụ:
1. đọc 1 tin bài cụ thể, thì điều kiện where là id của tin/bài đó.
2. liệt kê 10 tin mới nhất, nghĩa là order theo thời gian và limit 10 cái. Nhưng order là phép toán khá chậm nếu không cẩn thận, do đó bạn nên thêm điều kiện >= time nào đó tính ra được, gần đúng thôi, hoặc id > = max_id - 10 chẳng hạn => là 10 tin cuối cùng (giả sử id là số thứ tự tin tăng dần).

eyestv wrote:

Chào bác, con server kế toán cơ quan em (windows server 2003 enterprise) sau bao năm chạy chẳng vấn đề gì, một ngày đẹp trời nó bị MS phát hiện và locked.

Hiện tại khởi động là nó bắt phải nhập product key. Giờ chỉ còn cách nhập key xịn vào và chờ MS confirm.

Em có đề đạt nguyện vọng xin tiền mua key, nhưng sếp ở VN thì các bác biết rồi đó: "Đây là nhiệm vụ của IT các anh, tôi trả lương cho các anh là để đảm bảo hệ thống mạng chạy ổn định, có cái việc bé xíu thế này mà không giải quyết được à?"

Chắc đành phải bỏ tiền túi ra thôi. Bác chủ thớt có kinh nghiệm thì tư vấn giúp em với.

Bỏ việc đi bạn. Gặp sếp thiếu hiểu biết thế thì ko nên làm nữa và nếu lương cũng không có gì cao. Bỏ 800$-2000$ mua bản quyền Win2003 Std/Ent (mà giờ không chắc mua được) chắc là bạn sẽ không làm nổi đâu. Mua key lậu không chắc chắn đâu á.

Vả lại tiên trách kỷ hậu trách nhân, ngay từ đầu các bạn IT nói cho sếp biết tổng chi phí phải trả để sở hữu phần mềm kế toán đó (ngoài phần mềm kế toàn, máy chủ thì gồm cả phí bản quyền Windows và SQL Server... - nếu sử dụng - để chạy cho PMKT đó), thì đâu đến nỗi. Mình làm thuê cho doanh nghiệp. mua key phần mềm cho doanh nghiệp, chứ có phải là mua cho cá nhân mình đâu, tiền thì doanh nghiệp phải trả chứ không phải mình.

Nhiều IT Manager (và đáng buồn đa số là CIO, hoặc Chief IT rất cao, rất quan trọng) không ý thức được rủi ro này, không nói từ đầu để sếp CEO cũng hiểu rủi ro đó, nay thì sếp chửi bạn là quá đúng rồi.
Nếu lúc đó nói trước, ông ấy tặc lưỡi, quyết cho dùng key lậu thì nay có làm sao ông ấy chịu, không phải bạn. Rủi ro nó không xảy đến ngay mà nhiều năm sau mới bị, khi sự nghiệp của bạn ở công ty đã ổn định và vị trí cao, thế mới đau.

Với ngừoi sử dụng thì không có gì để làm nhiều.
Nhưng với admin thì cũng kha khá, nhất là việc ... hủy và cấp lại SSL Cert cho đảm bảo. Chưa kể là việc đổi pass. Ai không có SSL thì có thể bỏ qua việc này.
Các bản RH/CentOS/OracleLinux đã cung cấp bản vá rồi, yum update là xong.

Câu hỏi này thú vị và mình nghĩ trả lời nó sẽ giúp nhiều người.
1. Dựa vào đâu biết tốc độ (đang kết nối) của NIC: xem mục status của nó trên Win, Linux thì là lệnh ethtool <tên interface>, hoặc nhìn đèn của switch và theo tài liệu kỹ thuật/help của switch để biết. Đa số các switch có đèn thể hiện trạng thái kết nối 10, 100 hay 1000.

2. nguyên tắc của switch là store and forward, tức là nhận rồi gửi tới nơi cần nhận (nếu nơi nhận có thể), còn nhận mà không kịp thì nó ... bỏ đi. Còn nhận nhanh hơn gửi thì nó ngồi chờ (và chơi - idle) Với các switch Cisco hiện tại, loại 24 port, thường thì khả năng của nó rất kinh khủng (ở chế độ L2 switching), người ta nói đôi khi là đạt wire speed luôn. Tức là, ở một số tình huống, như cả 24 máy PC nói chuyện từng cặp truyền nhận 1G/s,thì tổng có thể đạt 24Gbit/s*2 (luồng truyền và luồng nhận) ~ 48GBit, tối đa khả năng truyền của switch. Kiểu như A <-> B, C <-> D,... 12 cặp thì cặp A-B sẽ không ảnh hưởng tới 11 cặp còn lại và switch vẫn đủ khả năng truyền 12 cặp đó riêng lẻ với tốc độ tối đa. Dĩ nhiên còn 1 số cái thông số nữa ảnh hưởng tốc độ nhưng đại để là như thế.

Bạn cứ tưởng tượng như mỗi cổng các chiều vào, ra là 2 cái ống nước một chiều, bơm vào switch (từ PC) tới switch sẽ đạt tối đa 1G, bơm vào bao nhiêu thì đầu nhận là các PC (hoặc 1 PC) sẽ nhận bấy nhiêu nếu có thể, từ switch đến PC có bấy nhiêu.

Tuy nhiên vấn đề chính là hướng của luồng dữ liệu truyền, không bao giờ lý tưởng thế cả.
Thực tế thì hiếm khi gigabit switch chạy tối đa tốc độ, bởi 23 or 24 PC không bao giờ nói chuyện với nhau riêng lẻ từng cặp một (chả có ứng dụng nào kiểu như thế), mà thường cả 23 PC nhằm đến 1 cái chung (server, hoặc trường hợp của bạn là 1 router). Mà cổng tới router max là 1Gb, như cái ống nước data, tất cả 23 cái còn lại đổ data tới bao nhiêu đi nữa thì nó cũng chỉ nhận được có bấy nhiêu (1Gb), và từ nó đi (max = 1Gb) cũng tới 23 cái còn lại tổng chỉ là 1Gbit.
Dĩ nhiên lúc này, 1Gb sẽ chia cho 23, nhiều PC nữa thì còn chia nhiều nữa.
Dù 1Gb/23 ~ 40mbit cũng là con số kha khá lớn nhưng sẽ là chậm nếu ... có cái nặng đô.
Chỗ chung giữa các PC đó đó gọi là cổ chai. Vấn đề nghẽn cổ chai đó vì chỉ 1Gbit, nên người ta mới làm 1 số kỹ thuật tăng cái chỗ bé đó lên tương xứng. Ví dụ hiện có switch có 24 port là 1Gbit, và có 2 port là 10Gbit. Hoặc switch 24 port 100Mbit, 2 port 1Gbit. 2 port tốc độ cao đó người ta dùng để nối cho cổ chai, hoặc nối 2 switch với nhau (1 bên có cổ chai bên kia thì truyền sang bên này).

Mặt khác, PC và server, router hiện tại về kỹ thuật để tạo ra/hoặc đủ data để thành 1 traffic 1Gbit/s lấp đầy kênh 1Gbit LAN không phải là chuyện đơn giản (nhưng ta cứ giả sử có thể đi).

4. Trong trường hợp của bạn, nếu chỉ xài Internet, kênh 35Mbit, thì cái switch 24 port 1Gbit là ... quá thừa, dòng nước data 35Mbit mà đi tới con sông 1Gbit (rộng gấp 25 lần) thì quá thoải mái. Cái cổ chai lúc này không còn là từ LAN --> router nữa mà là từ router -> Internet. Chỉ cần 1 cái, thậm chí 2 cái switch 24port 100, nếu 2 port 1Gbit (nối khéo 2 sw cái bằng các port 1Gbit), cũng quá thừa vì chả bao giờ chạy hết tốc độ cho phép được cả.

Các ứng dụng cần đến gigabit switch đa số là đụng đến server, đặc biệt là file server. Bạn tưởng tượng file film 4GBytes nếu tải trên kênh 1Gbit sẽ mất bao lâu? chỉ khoảng 40 giây thôi (mỗi giây được ~ 100MByte). Và nếu file này cả 23 máy cùng tải file đó, thì kênh 1Gbit sẽ không đủ (bởi sẽ phải chia cho 23, thời gian chậm 23 lần), lúc này file server cần nhiều 1Gbit hợp lại nối với nó, hoặc 1 kênh 10Gbit (đủ cho 10G/23PC, chậm hơn 2.3 lần thôi).

Không!
Tracert, trong cái tên là Trace Route. Đã là route tức là liên mạng mới đụng đến.
MAC chỉ có tác dụng nội mạng (LAN), không tồn tại khái niệm route đó.