3.1.2. Mơ hình vật lý hệ thống quản lý, vận hành các CSDL ngành Thuế DB Server DB Server Agent Port 1521,1831 Cấp Tổng cục Port 4889 MR Server DB Server MS Server Agent Browser Ethernet Ethernet Browser DB Server Agent Port 1521,1831 Port 1159 Port 1159 Po rt 15 21 ,1 83 1 Browser Port 1159 Cấp Cục Thuế Cấp Chi Cục Thuế Port 4889 Po rt 48 89 Hình 3.2 Mơ hình vật lý Cấp tổng cục Thuế
– Tại tổng cục thuế sẽ đặt 2 máy chủ, một máy chủ cài đặt và cấu hình Ứng dụng
dịch vụ quản lý, một máy cài đặt và cấu hình Nơi lƣu trữ dữ liệu quản trị.
– Máy chủ Ứng dụng dịch vụ quản lý có nhiệm vụ giao tiếp với các máy chủ cơ
sở dữ liệu cần quản trị tại 3 cấp, thông qua các Tác tử và đƣa các thông tin quản trị sang máy chủ Nơi lƣu trữ dữ liệu quản trị.
– Máy chủ Nơi lƣu trữ dữ liệu quản trị là một Database lƣu dữ liệu đƣợc tập hợp
từ Tác tử .
– Các máy chủ cơ sở dữ liệu tại Tổng cục sẽ cài đặt Tác tử nhằm trao đổi thông
tin với Ứng dụng quản lý dịch vụ.
Cấp cục Thuế
– Tại cục Thuế sẽ cài đặt Tác tử lên các máy chủ CSDL (Server 3, Server 5,
Server 10) nhằm trao đổi thông tin với Ứng dụng dịch vụ quản lý cài đặt tại Tổng cục.
– Với các Chi cục Thuế mơ hình 1 sẽ cài đặt Tác tử trên máy chủ đang chạy cơ sở dữ liệu QLAC phân tán.
– Với các Chi cục Thuế mơ hình 2 sẽ cài đặt Tác tử trên máy chủ đang chạy cơ sở
dữ liệu QLAC phân tán (nếu có) và máy chủ cơ sở dữ liệu QLTCC.
3.2. Theo dõi, giám sát hoạt động các CSDL
3.2.1. Luồng xử lý trong việc theo dõi, giám sát hoạt động các CSDL
Quá trình theo dõi, giám sát, trao đổi thông tin giữa Tác tử , Ứng dụng dịch vụ quản lý và Nơi lƣu trữ dữ liệu quản trị bao gồm ba giai đoạn:
Tác tử định kỳ thu thập thông tin về tình hình hoạt động của máy chủ cài đặt tác tử
và các đối tƣợng trên máy chủ đó. Mỗi đầu mục thơng tin đƣợc thu thập thông qua các metric, tần suất thu thập của các metric này do hệ thống quy định.
Các thông tin thu thập từ máy chủ cài đặt tác tử đƣợc lƣu dƣới dạng file XML và
đƣợc upload định kỳ tới ứng dụng quản lý dịch vụ, tần suất upload đƣợc quy định bởi tham số cấu hình của tác tử .
Trên Ứng dụng dịch vụ quản lý sẽ có Thread Loader chịu trách nhiệm chuyển nội
dung các file XML nhận từ Tác tử vào nơi lƣu trữ dữ liệu quản trị. Số lƣợng Loader và tần suất chuyển nội dung quy định bởi tham số cấu hình trên ứng dụng quản lý dịch vụ
Thông tin do Tác tử thu thập đƣợc chia thành 03 loại, có cách thức xử lý khác nhau:
Metadata: nêu định nghĩa về đối tƣợng và cách thức giám sát đối tƣợng.
State: tình trạng của các đối tƣợng và trạng thái của các metric.
Metric data: nội dung các metric.
Metadata và State đƣợc upload theo phƣơng thức synchronous nhằm đảm bảo khả năng theo dõi, giám sát hoạt động của các CSDL. Metric data đƣợc upload theo phƣơng thức asynchronous, ln ln có độ ƣu tiên thấp hơn so với metadata và state. Danh sách các metric đƣợc sử dụng cho hệ thống ở phụ lục 1 phần PHỤ LỤC.
3.2.2. Phƣơng thức cảnh báo
Hệ thống quản lý, vận hành tập trung các CSDL ngành Thuế hỗ trợ các hình thức chính cảnh báo trạng thái tới ngƣời quản trị gồm:
Thông qua giao diện theo dõi trực quan.
Thông qua email.
Thông qua câu lệnh OS hoặc PL/SQL.
Đối với giao diện theo dõi trực quan sẽ tổ chức nhƣ ở phần Giao diện theo dõi trạng thái. Tồn bộ thơng tin về tình hình hoạt động các CSDL, thông tin về các cảnh báo sẽ đƣợc hiển thị trên giao diện theo dõi trực quan.
Đối với hình thức cảnh báo qua email sẽ thiết kế để hệ thống quản lý, vận hành các CSDL ngành Thuế giao tiếp với hệ thống email của Tổng cục Thuế. Các cảnh báo khẩn liên quan tới khả năng ngừng phục vụ của CSDL sẽ đƣợc thông báo qua email tới ngƣời quản trị CSDL.
Với hình thức cảnh báo sử dụng PL/SQL, giải pháp thiết kế sẵn một kênh giao tiếp để kết nối tới hệ thống tin nhắn của Tổng cục Thuế để gửi tin nhắn tới điện thoại di động của cán bộ quản trị khi hệ thống tin nhắn đi vào hoạt động. Kênh giao tiếp này sẽ cung cấp thông tin về cảnh báo nhƣ: thời gian xuất hiện, địa điểm, đối tƣợng, phân loại thông tin, mức độ quan trọng, thông báo chi tiết về vấn đề phát sinh. Đồng thời chuẩn bị sẵn bảng chứa thông tin về cán bộ quản trị CSDL các cấp nhƣ: Tên, email, số điện thoại, cơ quan thuế để hệ thống quản lý, vận hành tập trung các CSDL ngành Thuế có tính độc lập tƣơng đối với hệ thống tin nhắn. Các cảnh báo khẩn liên quan tới việc ngừng phục vụ của CSDL sẽ đƣợc gửi tới ngƣời quản trị CSDL thông qua tin nhắn.
3.3. Cấu hình cây thƣ mục Tác tử
Thƣ mục AGENT_HOME\bin chứa các file thực thi nhằm điểu khiển hoạt động
của Tác tử.
Thƣ mục AGENT_HOME\sysman\admin chứa các file định nghĩa đối tƣợng, các
configuration script.
Thƣ mục AGENT_HOME\config chứa file cấu hình liên quan tới hoạt động của
Tác tử.
Thƣ mục AGENT_HOME\sysman\log chứa các log file phát sinh trong quá trình
hoạt động của Tác tử.
Cấu hình log và trace file của Tác tử nhƣ sau (file \sysman\config\emd.properties)
– log4j.rootCategory=WARN, emagentlogAppender, emagenttrcAppender
– log4j.appender.emagentlogAppender.MaxFileSize=5000000
– log4j.appender.emagentlogAppender.MaxBackupIndex=4
– log4j.appender.emagenttrcAppender.MaxFileSize=5000000
3.4. Cấu hình cây thƣ mục Dịch vụ quản lý
Thƣ mục MS_HOME\bin chứa các file thực thi nhằm điểu khiển hoạt động các
thành phần của Oracle Application Server J2EE và Webcache.
Thƣ mục MS_HOME\sysman chứa các file liên quan tới cấu hình, hoạt động của
Application Server.
Thƣ mục MS_HOME\opmn chứa các file thực thi nhằm điểu khiển hoạt động của
Oracle Process Manager và Notification Server.
Thƣ mục MS_HOME\j2ee chứa các file liên quan tới cấu hình, hoạt động của
thành phần OC4J bên trong Application Server.
Cấu hình log và trace file của MS nhƣ sau (file
\sysman\config\emomslogging.properties):
– log4j.rootCategory=WARN, emlogAppender, emtrcAppender
– log4j.appender.emlogAppender.MaxFileSize=5000000
– log4j.appender.emlogAppender.MaxBackupIndex=4
– log4j.appender.emtrcAppender.MaxFileSize=5000000
3.5. Thiết kế, chuẩn hóa các quy trình quản lý, vận hành các CSDL ngành Thuế CSDL ngành Thuế
Quy trình quản lý, vận hành các CSDL đƣợc thiết kế, chuẩn hóa theo hƣớng cơng nghệ ITIL nhƣng có sự tùy biến, đơn giản hố với đặc thù, hiện trạng ngành Thuế để đạt tính chính xác, kịp thời rất cao. Dƣới đây trình bày chi tiết 1 số quy trình chính trong việc quản lý, vận hành các CSDL ngành Thuế.
3.3.1. Quy trình giám sát định kỳ
3.3.1.1. Giám sát định kỳ hàng ngày
Đảm bảo các database instance ở trạng thái Open
– Kiểm tra trạng thái của các cơ sở dữ liệu thuộc phạm vi quản lý trực tiếp.
– Thời gian kiểm tra từ 07h30 tới 16h30 với tần suất 15 phút/lần đối với các cơ sở
dữ liệu hoạt động theo giờ hành chính, kiểm tra 24/24 đối với các cơ sở dữ liệu hoạt động 24*7 với tần suất 15 phút/lần (ngoại trừ thời gian thực hiện offline backup).
Theo dõi các alert log
– Kiểm tra nội dung alert log file của các cơ sở dữ liệu thuộc phạm vi quản lý
trực tiếp.
– Thực hiện kiểm tra 02 lần/ngày vào cuối các buổi làm việc.
– Ghi nhận các lỗi ORA – NNNNN phát sinh vào nhật ký công việc.
Theo dõi kết quả của việc backup
– Theo dõi kết quả backup offline
o Xác định q trình backup có thực hiện đúng kế hoạch.
o Xác định chất lƣợng của bản backup.
o Xác định việc sao lƣu bản backup có đƣợc thực hiện.
o Thời điểm kiểm tra diễn ra sau lần backup gần nhất.
– Theo dõi kết quả backup online
o Kiểm tra không gian đĩa dành cho việc tạo file archived log
o Kiểm tra file arc có đƣợc apply tới standby database.
o Kiểm tra kết quả backup level 0, level 1 và sao lƣu archivelog file.
o Thời gian kiểm tra 8h sáng hàng ngày.
– Kiểm tra trạng thái các đối tƣợng: Rollback segment, Undo tablespace, Temporary tablespace.
– Thực hiện kiểm tra 02 lần/ngày, vào thời điểm đầu của mỗi buổi làm việc.
– Thu thập thông tin chung về hoạt động của database các Cục thuế lớn, 2
lần/ngày: thông tin về đọc/ghi đĩa, thông tin về wait…
3.3.1.2. Giám sát định kỳ hàng tuần
Kiểm tra, so sánh cấu hình của các database object với cấu hình chuẩn:
– Kiểm tra cấu trúc logic và vật lý của database (danh sách bảng, danh sách
trƣờng…)
– Kiểm tra ghi nhận dung lƣợng vật lý và logic, xác định các object có mức độ
tăng trƣởng đột biến.
– Kiểm tra không gian trống của mỗi tablespace.
– Thời gian thực hiện vào ngày làm việc cuối cùng của mỗi tuần.
Kiểm tra cấu hình security của các database: Số User, Password, Roles, System
privileges, Object privileges.
Tổng hợp thơng tin và đánh giá tình hình của database
– Thực hiện tổng hợp các thơng tin về tình hình hoạt động của database tại các
Cục thuế lớn
– Đánh giá tình hình hoạt động của các database; xác định các vấn đề, nguyên
nhân và tìm giải pháp xử lý
Trao đổi trong nhóm về các vấn đề đã xử lý trong tuần
– Các thành viên trong nhóm tổng hợp lại các vấn đề đã gặp và xử lý trong tuần
– Tổ chức trao đổi trong nhóm về các vấn đề đã xử lý, cập nhật những thông tin
mới vào kho kiến thức về xử lý sự cố.
Báo cáo về tình hình hoạt động của các database: Thực hiện tổng hợp thơng tin về
tình hình hoạt động của các database trong phạm vi quản lý và báo cáo với cán bộ quản lý.
3.3.1.3. Giám sát định kỳ hàng tháng
Đánh giá các tham số thiết lập trong initialization parameter file của các database
và đề xuất các thay đổi cần thiết nhằm tăng hiệu quả hoạt động của database
Sao lƣu alert log và listener log file
Kiểm tra mức độ phân mảnh dữ liệu.
Tổng hợp tình hình xử lý lỗi, đề xuất giải pháp giải quyết triệt để sự cố và thực hiện những giải pháp đƣợc chấp nhận.
3.3.2. Quy trình xử lý sự cố
Hình 3.4 Sơ đồ quy trình xử lý sự cố
Các thành phần tham gia trong quy trình
– Ngƣời sử dụng,
– Cán bộ hỗ trợ (nhóm Hỗ trợ ứng dụng ứng dụng địa phƣơng)
– Cán bộ tiếp nhận yêu cầu (nhóm quản trị cơ sở dữ liệu
– Cán bộ xử lý yêu cầu (nhóm quản trị cơ sở dữ liệu).
3.3.2.2. Bước 1: Tiếp nhận yêu cầu xử lý
Khi có lỗi phát sinh trong ứng dụng, ngƣời sử dụng ghi nhận các thơng tin có liên quan theo mẫu yêu cầu xử lý lỗi sau đó gửi tới nhóm Hỗ trợ ứng dụng địa phƣơng. Nhóm Hỗ trợ có trách nhiệm xác định nguồn gốc gây ra lỗi. Nếu lỗi phát sinh do CSDL sẽ chuyển yêu cầu xử lý lỗi tới nhóm Quản trị CSDL.
Cán bộ tiếp nhận yêu cầu nhận yêu cầu xử lý lỗi từ cán bộ hỗ trợ ứng dụng thông qua trao đổi trực tiếp, điện thoại, email hoặc các phƣơng tiện khác. Nội dung yêu cầu sẽ dựa trên mẫu Yêu cầu xử lý lỗi.
Cán bộ tiếp nhận sẽ phân công xử lý lỗi cho cán bộ quản trị CSDL, thông báo tới cán bộ hỗ trợ về việc phân công xử lý và ghi nhật ký nhận yêu cầu xử lý lỗi.
3.3.2.3. Bước 2: Xác định sự tồn tại của lỗi và thu thập thêm thông tin
Cán bộ xử lý lỗi thực hiện các biện pháp nhằm khẳng định sự tồn tại của lỗi và thu thập các thông tin cần thiết, ghi nhật ký lỗi cần xử lý.
Nếu lỗi phát sinh do các nguyên nhân không liên quan đến cơ sở dữ liệu hoặc không tồn tại trên thực tế, cán bộ xử lý chuyển trả yêu cầu xử lý sự cố cho cán bộ tiếp nhận nhằm thông báo kết quả tới nhóm Hỗ trợ ứng dụng.
3.3.2.4. Bước 3: Xác định nguồn gốc và biện pháp xử lý
Cán bộ xử lý tiến hành xác định nguồn gốc gây ra lỗi, hƣớng xử lý lỗi, cách thức kiểm tra và các biện pháp giải quyết. Nếu trong Knowledge Base chƣa có biện pháp giải quyết cho lỗi phát sinh, cán bộ xử lý có thể:
Tự đề xuất biện pháp giải quyết.
Trao đổi trong nhóm hoặc xin ý kiến chuyên gia.
Trên cơ sở đó, cán bộ xử lý xây dựng giải pháp xử lý lỗi theo hƣớng đã chọn. Trong những trƣờng hợp phức tạp cần trao đổi trong nhóm về cách giải quyết tối ƣu, thử nghiệm và xin ý kiến cấp trên (phụ trách phòng hoặc lãnh đạo) về việc thực hiện. Ghi nhật ký quá trình xây dựng - chọn lựa giải pháp xử lý.
3.3.2.5. Bước 4: Thực hiện xử lý lỗi
Cán bộ xử lý lỗi áp dụng các biện pháp bảo đảm an toàn cần thiết trƣớc khi tiến hành xử lý lỗi: thông báo tới ngƣời sử dụng về việc xử lý lỗi và thời gian thực hiện, sao lƣu dữ liệu, lƣu lại giải pháp xử lý. Thực thi giải pháp xử lý lỗi và ghi nhật ký về quá trình xử lý lỗi.
3.3.2.6. Bước 5: Kiểm tra kết quả và nhận phản hồi từ đầu mối liên hệ
Cán bộ xử lý kiểm tra kết quả xử lý dựa trên các biện pháp đã xác định và thơng báo tình hình xử lý lỗi tới cán bộ tiếp nhận. Cán bộ tiếp nhận yêu cầu ngƣời sử dụng gửi phản hồi về kết quả xử lý lỗi và ghi nhật ký về việc kiểm tra kết quả xử lý lỗi. Nếu việc xử lý lỗi thành cơng, q trình xử lý lỗi chuyển qua bƣớc 6. Trong các trƣờng hợp khác, quá trình sẽ lặp lại từ bƣớc 2.
3.3.2.7. Bước 6: Kết thúc yêu cầu xử lý lỗi
Cán bộ tiếp nhận đóng yêu cầu xử lý lỗi. Cán bộ xử lý soạn tài liệu hƣớng dẫn xử lý lỗi nhằm cập nhật/ bổ sung vào kho kiến thức chung về xử lý sự cố.
3.3.3. Quy trình sao lƣu cơ sở dữ liệu
Việc sao lƣu cơ sở dữ liệu đƣợc thực hiện hàng ngày 1 cách tự động (thông qua chế độ đặt lịch hoạt động của hệ thống quản lý, vận hành tập trung các hệ thống thông tin ngành Thuế) hoặc khi có sự cố xảy ra trên cơ sở dữ liệu và cần thực hiện sao lƣu trƣớc khi xử lý.
Việc sao lƣu cơ sở dữ liệu có thể đƣợc thực hiện theo một trong các cách sau:
Full offline copy database
Export
3.3.4. Quy trình khơi phục cơ sở dữ liệu
Việc khôi phục cơ sở dữ liệu đƣợc thực hiện khi có sự cố xảy ra trên cơ sở dữ liệu. Việc khôi phục cơ sở dữ liệu phụ thuộc vào từng trƣờng hợp sự cố cụ thể mà có giải pháp tƣơng ứng.
Việc khơi phục cơ sở dữ liệu có thể đƣợc thực hiện theo một trong các cách cơ bản sau:
Restore database từ bản full offline backup
Import
Ngoài ra, căn cứ vào tình hình thực tế có thể thực hiện những phƣơng pháp khác để khôi phục cơ sở dữ liệu.
3.3.5. Nhật ký quản trị CSDL
Nhật ký quản trị cơ sở dữ liệu lƣu lại các thông tin về các sự cố xảy ra trên cơ sở dữ liệu và các bƣớc mà cán bộ quản trị cơ sở dữ liệu thực hiện để kiểm tra sự cố cũng nhƣ giải quyết sự cố. Tài liệu này có thể sử dụng làm căn cứ để theo dõi quá trình thực hiện xử lý sự cố của các cán bộ, và sử dụng làm nguồn thông tin đầu vào cho kho kiến thức chung về xử lý sự cố. Mỗi cán bộ thuộc nhóm quản trị cơ sở dữ liệu sẽ có một “Nhật ký quản trị cơ sở dữ liệu” lƣu lại các sự cố mình thực hiện xử lý. Nhật ký