Mớ HR của nơi này khoái bày vẽ, sáng hôm rồi gửi tôi 1 cái mail với nội dung kiểm tra độ gắn kết giữa bạn và cty. Nghe có vẻ đợm mùi khảo sát khảo cổ nhưng vẫn tồn tại gì đó mang tính phô trương vẽ vời. Sau đây là các câu hỏi và câu trả lời. Tôi nghĩ đọc xong thể nào cũng có giải thưởng người điên nhất cho mình
Continue reading
Saler vốn dĩ là những kẻ ngu dốt và có tầm nhìn kiệt quệ
Thật không tin được thứ căn bản nhất mình đã bỏ qua trong 2 tháng trời làm việc với mớ hàng khủng này. Kết quả nguyên nhân thì đã rõ ràng, khắc phục thì cũng xong. Vậy mà chẳng ai khen mình hay khích lệ gì cả. Hiển nhiên như tất cả những điều đó bản thân mình phải làm cho bằng được. Mình ngồi mình khóc đất trời đổ mưa.
2 con server này nhìn vào thì không thấy có gì chậm so với yêu cầu tối thiểu ứng dụng oracle bên mình đang chạy. Tuy nhiên khi mới cài đặt và chạy thử thì hệ thống ì ạch đến không tưởng, mọi thao tác truy xuất, chuyển đổi di rời gần như treo sau vài chục phút chạy.Bản thân mình làm việc với dòng IBM x này chưa lâu, cũng không có những khái niệm ban đầu căn bản, tuy nhiên mình vẫn nghĩ khi 1 hệ thống làm việc chậm 2 yếu tố dẫn dắt đầu tiên là software + hardware. Điểm lại 1 số điều như sau
Hệ thống chạy raid 5 – ram 18gb – cpu 16 core. Nếu có vấn đề gì liên quan đến phần cứng thì ắt hẳn phải nằm ở 3 điểm này. Vốn dĩ các thiết bị khác đều onboard trên main. Hiển nhiên việc có lỗi từ nhà sản xuất đã bị mình khai quật trên màn hình console. Nhưng vấn đề ở đây là hệ thống êm ru không trả ra bất kì 1 lỗi gì trong quá trình nhanh chậm bất thường.
Phần mềm trên hệ thống được clone từ bản UAT (user accessing tester) của khách hàng. Rõ ràng bản này không thể lỗi, vì nếu lỗi khách hàng đã gầm lên chứ đâu để mình được yên. Nghi vấn tiếp theo được dồn cho platform Oracle Enterprise Linux 5.4 đang cài. Hàng loạt các nghi vấn như huges page – kernel don’t assign core cpu v.v.. được mình đưa lên như cố đánh quả trước khi chết
Mọi thứ gần như vô vọng trong hàng loạt các suy diễn. Mình nghĩ đến hướng giải quyết nhờ giúp đỡ của những người mang tiếng chuyên gia. Nhưng có 1 vấn đề ở đây mà bản thân mình áy náy, đó là cho dù có nhờ ai đi nữa thì bản thân mình vẫn phải tìm ra được nguyên nhân, nếu nguyên nhân mình còn chưa thấy thì biết báo cáo làm sao. Chẳng nhẽ họp đội dự án mình là bô bô “do lỗi không xác định được lỗi nên em phải nhờ chuyên gia à”.
Thử nghiệm lại từ đầu mình tiến hành như sau, việc tiến hành này mình đi sâu vào kiểm tra hoạt động của ổ đĩa. Vì mình chỉ nghĩ đơn giản hơi mất căn bản là : Việc đọc ghi – truy xuất dữ liệu chậm thì cứ nắm lấy ổ cứng mà xem xét
Các bước như sau
Thực hiện việc tar – copy trên nền background
Phóng htop để xem ram – cpu , song song đó quăng thử iostat lên console
Wow :. Cpu 97% – Ram ăn hết 17 gb cho 2 cái lệnh tar + gzip. Ấy vậy mà IO load chỉ tầm vài nghìn. Con số này chênh lệch quá. Rõ ràng với 1 hệ thống ổn định, việc truy xuất ram + cpu khi thực hiện các tác vụ này không chiếm nhiều performance đến vậy nhưng io vẫn làm việc trơn tru. Điều này có nghĩa là IO của hệ thống mình đang có điều gì đó bất ổn. Nói cách khác nó là minh chứng rõ nhất cho việc ổ cứng + raid của mình đang liêu điêu
Vấn đề tiếp theo là làm sao giải quyết nó
Mình mò mẫm 1 hồi từ hàng đống các link tham khảo trên mạng và hỏi ý kiến người thân tìm được thằng DSA. DSA là 1 công cụ chuẩn đoán phân cứng của IBM. Điều này không hề mới mẻ với tụi hãng, nhưng chắc lạ lẫm tinh khôi với mình.Sử dụng nó mình thu thập được 1 ít thông tin thế này
Chà chà nhìn xem. Mấy cái firmware của thiết bị raid – sas – uefi hết hạn cả. Bảo sao nó không ì ạch. Tiến hành download 1 số firmware của thiết bị trên giành cho dòng Ibm system mình đang dùng, có lẽ sẽ khả quan hơn.
Mình định bắt tay vào làm ngay, tuy nhiên nếu làm ngay mình không chắc nhưng có thể sẽ có lỗi xảy ra. Lỗi này có thể phát sinh từ các thiết bị phần cứng khi được cập nhật firmware mới sẽ không phù hợp hoặc mất giá trị với hệ thống Production khách hàng đang chạy. Thử nghĩ xem sẽ có bao nhiêu mail chửi rủa nhiếc móc thậm chí yêu cầu mình nghỉ việc. Những rủi ro như mất dữ liệu – 1 vài lỗi hỏng hóc không thể sửa đang nằm chờ mình àv.v…
Có 1 điều khi làm system administrator hoặc dba đều giống nhau là người ta chỉ mong cho mọi thứ chạy được ở 1 mức căn bản. Dạng setup one run forever. Nhưng thật ra không phải thế, mỗi hệ thống cho dù có đắt tiền tới đâu, cấu hình tốt thế nào, cài đặt chuẩn ra sao cũng sẽ có lúc hệ thống bị crash. Đơn giản vì trong quá trình chạy, mọi lỗi từ cứng hoặc mềm đều có thể xảy ra, mà không phải bất kì cũng control hết được. Chính vì lí do này nên từ khi khai sinh ra máy điện toán, con người đã cho thêm vào từ điển động từ backup. Trở lại với vấn đề hiện tại chúng ta thấy được nếu có sự backup sẽ đỡ vất vả rất nhiều.
Bỏ công chuyển hết data & application của khách hàng sang 1 con server backup. Xong xuôi quay ngược về tiến hành Update firmware từ các file .bin đã download.
Nhìn mớ log update successful mà mát lòng mát dạ. Mình tiến hành chuyển lại database về chỗ cũ. Không quên test performance lần cuối xem đã ổn chưa. Kết quả thỏa mãn hơn thế, lượng Ram + Cpu đều đặn, tốc độ đọc IO cao ngất phù hợp với những gì lượng tính toán trả về của các thiết bị khác. Check lại DSA log sau khi cập nhật, mọi thứ đã vàng chói mà không đỏ loa đỏ kè như trước nữa
top - 10:41:51 up 10:44, 4 users, load average: 1.87, 1.47, 1.13
Tasks: 385 total, 2 running, 383 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 6.3%sy, 0.0%ni, 93.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 18483616k total, 18458932k used, 24684k free, 47364k buffers
iostat sda9 53.51 1220.90 8797.31 47197188 340085208
Có 1 điểm chắc mọi người sẽ thắc mắc, vì tại sao lại phải update firmware / driver cho linux. Nghe chừng điều này vô nghĩa và không có lí lắm. Trước giờ đối với *nix người ta thường cho rằng việc các driver tự nhận là điểu hiển nhiên. Bởi bản thân Linux tích hợp sẵn khả năng viết driver cho các thiết bị phần cứng dù là cũ hay mới. Nhưng chuyện viết driver cho các thiết bị chạy được nhận được khác với việc viết 1 driver để các thiết bị có thể tối ưu hóa hết khả năng mà bản thân chúng có. Điều này lí giải được nguyên do vì sao 1 số hãng phát triển phần cứng khi phát hành các dòng thiết bị mới của mình đều khuyến cáo người dùng nên cài đặt driver mới nhất đi kèm dù là trên windows hay linux. Bản thân mình cũng gặp nhiều trường hợp về chuyện này, nhưng thật tình chưa bao giờ chú tâm đến việc cài driver cho các os linux. Mong sao sau chuyện này sẽ thêm kinh nghiệm cho mấy cái tweak & optimzie
Xong 1 case, lòng vui phơi phới. Hệ thống dần dần đi vào quĩ đạo mà ban đầu đã phác lược trên nó. Nhận được 1 cái mail đầy hứa hẹn. Mặc dù biết chắc năm nay lương thưởng coi như bèo bọt hơn lông gấu chạy mưa. Thế mới nói phần thường của người làm bảo mật không đến từ những giá trị vật chất là vậy.
Cám ơn cho tất cả
Tôi viết bài này khi vừa hoàn thành 1 hệ thống ERP oracle cho khách hàng. Vấn đề cài đặt ERP oracle tôi sẽ không đề cập ở đây vì nó vừa khô khan khó nuốt, 1 phần vì tài liệu tham khảo về nó khá nhiều ở các site oracle training. Vấn đề tôi muốn nói ở đây là lỗi Out of memory (oom killer) khi cài đặt các ứng dụng trên hệ thống Linux 32bit hoặc x86_64bit
Nói chung khi bị lỗi Out of memory xảy ra thì các tiến trình sẽ bị tắt (kill) hoặc ngừng hoạt động. Nếu các ứng dụng đang chạy lường trước được sự quá tải của bộ nhớ thì thường sẽ có 2 lựa chọn khi điều này xảy ra. 1 là Retry 2 là Abort. Tất nhiên 2 điều này đều nhằm chờ đợi sự thay đổi thông số memory từ phía kernel. Bản thân người dùng linux thường bỏ quên việc tổng quan hệ thống như memory đang hết bao nhiêu, cpu ra sao, các disk hoạt động thế nào. Điều này là 1 thói quen không tốt bởi thực ra việc monitor các tiến trình (proccess) này là điều khá đơn giản thông qua
cat /proc/version
cat /proc/cpuinfo
cat /proc/meminfo
Trở lại với việc out of memory tôi gặp là khi đang setup Oracle EBS R12.1.1 trên nền linux64. Nếu ai đã từng đụng qua thử mấy món này sẽ biết các file cài đặt dung lượng tầm 50 – 60gb. Đặc biệt nó đòi hỏi khá nhiều physically memory & swap cache khi khởi chạy. Tuy nhiên lúc đầu tôi không quan tâm lắm đến việc requirement khi cài đặt nó, bởi tôi tự tin với cấu hình Server của mình có thể phà phà trên tầng cây số.
Trong nhiều trường hợp tôi để ý thấy với các hệ thống máy chủ có nhiều hơn 6gb ram, người sử dụng thường phó mặc tất cả việc quản lí chúng cho kernel của hệ thống thực hiện. Điều này không sai, tuy nhiên đôi khi với cấu hình kernel mặc định, bạn sẽ gặp phải 1 vài thông số như kernel.msgmax hoặc kernel.shmmax cản lọc việc tối đa hóa hiệu năng và tài nguyên của memory.
Để khắc phụ điều này cần chú ý kĩ những điều sau
Nhân(kernel) sử dụng bộ nhớ thấp nhất có thể để theo dõi và cấp phát tài nguyên (resource) cho 1 hệ thống. Thế nên một hệ thống 16gb ram sẽ phải sử dụng nhiều bộ nhớ cấp phát hơn là 1 hệ thống 2gb ram. Chính điều này gây áp lực cho bản thân kernel trong quá trình cấp phát, bởi mặc định Linux không giống Windows. Windows nếu bạn cài 32bit thì số lượng bộ nhớ tối đa nhận là 3,2gb thế nên bạn có gắn cao hơn thì cũng chưa chắc nhận được. Ở Linux 32bit hay 64bit đều có thể nhận số lượng memory mà bạn cấp cho chúng nhưng phải kèm theo 1 cấu hình chuẩn để giải tỏa & thỏa mãn số lượng này
Bạn có thể kiểm tra độ cao thấp của bộ nhớ thông qua.
# egrep 'High|Low' /proc/meminfo
HighTotal: 5111780 kB
HighFree: 1172 kB
LowTotal: 795688 kB
LowFree: 16788 kB
hoặc
# free -lm
total used free shared buffers cached
Mem: 5769 5751 17 0 8 5267
Low: 777 760 16 0 0 0
High: 4991 4990 1 0 0 0
-/+ buffers/cache: 475 5293
Swap: 4773 0 4773
Đối với hệ thống 32bit việc đồng bộ hóa kernel phân giải cho memory là điều không khó khăn, cộng thêm việc tắt chức năng out of memory có thể sẽ mang lại kết quả khả quan hơn cho bạn
Tôi thử nghiệm trên hệ thống linux của mình với version kernel là 2.6.x cách cấu hình lại như sau
# cat /proc/sys/vm/lower_zone_protection
# echo "250" > /proc/sys/vm/lower_zone_protection
# echo "vm.lower_zone_protection = 250" > /etc/sysctl.conf
Tắt oom killer bằng cách
# echo "0" > /proc/sys/vm/oom-kill (tắt)
# echo "1" > /proc/sys/vm/oom-kill (mở)
# echo “vm.oom-kill = 0″ > /etc/sysctl.conf
Sau mỗi tinh chỉnh nên reboot lại hệ thống và biên tập lại nhân thông qua sysctl -p
Đối với hệ thống đang gặp phải quá trình OOM như trên bạn có thể xác định nó chính xác bằng cách
tail /var/log/messages:
Out of Memory: Killed process [PID] [process name].
và tất nhiên sau khi đã tinh chỉnh
tail /var/log/messages:
"Would have oom-killed but /proc/sys/vm/oom-kill is disabled"
Sáng : Họ thay đồ tươm tất, diện thật ngọt những tấm váy áo được là lượt phẳng phiu, những đôi giày sáng bóng không tì vết. Tựu chung họ chắp vá kết nối để thành 1 cái họ trong 8 tiếng làm việc.
Trưa : Họ tề tựu từng bầy đàn nườp nượp nối đuôi nhau kiếm chỗ cơm văn phòng. Họ bận nhìn ngó, đắn đo, lựa chọn món nào cho đỡ ngán. Họ tất bật tìm chỗ không chỉ cho mình mà còn cho bầy đàn của mình. Bất giác họ dừng hẳn tiếng nói cười để móc vội phần tiền mình cần tính.
Chiều : Họ xông xênh áo quần, gửi vội những báo cáo, nhận vội những lời khen, quên nhanh những lời chê. Tầng hầm rút xe , phóng vội. Bỏ qua những họat động ngòai lề
—
Em làm gì mà các trưởng phòng nói về em như sao lạ vậy
Ơ em có làm gì đâu, anh nghĩ em chơi trội à ?
Không phải nhưng họ khen lính anh quá, làm anh thấy tủi ! Anh thấy những thứ em đề cập và triển khai như 1 cơn gió lạ đối với cấp trên. Phần thưởng của em ở chúng ?
Phần thường của em không phải tiền bạc. Mà là sự vừa lòng từ anh , từ mọi người trong phòng , từ sếp của mọi người và từ sếp của anh. Anh có hiểu về cung đạo không ?
Có nghe qua, nhưng chưa bao giờ tìm hiểu
Cung đạo là nghệ thuật bắn cung của Nhật (kyudo) còn gọi là xạ nghệ. Cung đạo mang một ý nghĩa triết lý sâu xa. Do vậy mục đích chính của người bắn cung không phải là bắn trúng đích mà là nắm vững cái nghệ thuật bắn cung. Khi cung thủ nắm vững đến mức hoàn thiện từng động tác của mình – thoát ra khỏi cái ý muốn thường ám ảnh là muốn tên phải bắn trúng đích – thì mũi tên sẽ tự lao đến đích. Em muốn rằng mọi điều em làm không phải hướng về những giá trị cụ thể mà tự nó sẽ lao về điều ấy thông qua những đánh giá và cảm giác chuẩn xác của mọi người.
Ghê nha ghê nha cung thủ. Anh phải sớm học nghệ thuật bắn cung thôi
—
Này lão, lão khai timesheet chưa ?
Mới khai
Tôi không hiểu khai để làm gì trong khi ngày nào cả họ chúng nó cũng ngồi đối mặt và xoay lưng lại với nhau. Nhìn nhau, thấy những việc nhau làm chưa chán hay sao mà còn phải khai thành từng bản cung.
Để họ thấy được trách nhiệm của chúng ta trong mỗi công việc mà ta đang thực hiện
Trách nhiệm của chúng ta không đến từ mấy cái ô excell hay table được kẻ tay trong word đó đâu. Lão biết anh Trung bên phòng sales không ?
Có nghe, sao thế lão
Thứ 7, anh ấy phải đi triển khai lại cáp ngầm cho khách hàng. Đứng dưới mưa từ 2h chiều đến 8h tối. Bọn thi công còn mè nheo đéo thèm làm, anh ấy tự rút tiền túi lóp pi cho thằng sếp 2triệu. Thế theo lão anh ấy làm vì điều gì ?
Ùh vì trách nhiệm.
Thế cái trách nhiệm đó có được nêu trong timesheet không ?
Continue reading
Tôi định viết về điều này nhiều lần rồi nhưng mãi vẫn chưa có bài nào cho hợp tình hợp lí đúng thời điểm. Hôm nay, sau những ngày tháng dài đánh vật với nhu cầu và mục đích an toàn thông tin cho khách hàng tôi lại có dịp hí hoáy viết lại vài dòng. Coi như 1 sự lưu giữ kỉ niệm và kinh nghiệm cho bản thân
Khách hàng của tôi là 1 cậu chủ nhỏ đang quản lí 1 hệ thống hàng trăm website. Từ các doanh nghiệp vừa và nhỏ đến các trung tâm, dịch vụ và thậm chí là cả trường THPT, đại học. Cậu chủ này sở hữu 1 server chính và 2 VPS. Hầu hết các site được xây dựng trên nền tảng Joomla (Open Source) Platform : Linux CentOS x86_64. Cài đặt đầy đủ các dịch vụ WebServer + MailServer + DNS + FTP. Tình hình tệ hại xảy ra liên tục trong những tháng đầu năm. Các Website của cậu ta liên tục gặp các vấn đề error database, deface, v.v… Nói chung cảm giác đầu khi bước vào nó như một ngôi nhà hoang không khóa với nhiều ô cửa sổ to và rộng. Tôi nhận nhiệm vụ hạn chế triệt để vấn đề nhà không cửa, cửa không khóa này trong 1 ngày không nắng không mưa, không chất xúc tác.
Nó đã diễn ra như 1 giấc mơ, có đôi lúc là ác mộng, lắm khi là 1 cảm giác ngon ngọt tươi mát. Nhưng tất cả qua đi thật chậm và chính xác theo lối vô định
Những ngày đầu tôi bỏ rất nhiều thời gian và công sức để rà soát các website trên hệ thống. Tựu trung chúng đều có chứa ít nhiều vài con shell của các bạn trẻ ham nghịch phá, vài lỗ hổng khởi nguồn từ SQL Injection. Tất cả thông tin tôi thu thập được đều đưa vào notepad. Từ những điều đó tôi hình thành những căn nguyên khởi sự của vấn đề và tìm cách giải quyết từng điều một. Trong trường hợp này không thể mang tính chất “đánh nhanh thắng nhanh” vào đó. Tin tưởng chậm mà chắc tỉ lệ thành công vẫn cao hơn
Continue reading