Chúng tôi tiếp tục hòa mình vào thế giới hấp dẫn của trò đoán ... khắc phục sự cố bằng nhật ký. TRONG chúng tôi đã đồng ý về ý nghĩa của các thuật ngữ cơ bản và xem xét cấu trúc tổng thể của Veeam như một ứng dụng duy nhất bằng một con mắt. Nhiệm vụ của phần này là tìm ra cách các tệp nhật ký được hình thành, loại thông tin nào được hiển thị trong chúng và lý do tại sao chúng trông như vậy.
Bạn nghĩ những "bản ghi" này là gì? Theo hầu hết, nhật ký của bất kỳ ứng dụng nào nên được giao vai trò của một loại thực thể toàn năng, phần lớn thời gian sống thực vật ở đâu đó trong sân sau, nhưng vào đúng thời điểm, bất ngờ xuất hiện trong bộ áo giáp sáng ngời và cứu mọi người. Nghĩa là, chúng phải chứa mọi thứ, từ những lỗi nhỏ nhất trong từng thành phần đến các giao dịch cơ sở dữ liệu riêng lẻ. Và để sau khi xảy ra lỗi, người ta lập tức viết cách khắc phục. Và tất cả điều này sẽ phù hợp với một vài megabyte, không hơn. Nó chỉ là văn bản! Tệp văn bản không thể chiếm hàng chục gigabyte, tôi đã nghe nó ở đâu đó!
Vì vậy các bản ghi
Trong thế giới thực, nhật ký chỉ là kho lưu trữ thông tin chẩn đoán. Và những gì để lưu trữ ở đó, lấy thông tin ở đâu để lưu trữ và mức độ chi tiết của thông tin đó là do chính các nhà phát triển quyết định. Ai đó đi theo con đường của chủ nghĩa tối giản bằng cách ghi lại mức BẬT / TẮT và ai đó siêng năng cào mọi thứ họ có thể tiếp cận. Mặc dù cũng có một tùy chọn trung gian với khả năng chọn cái gọi là Cấp độ ghi nhật ký, khi chính bạn chỉ ra mức độ thông tin chi tiết mà bạn muốn lưu trữ và dung lượng đĩa bổ sung mà bạn có =) Nhân tiện, VBR có sáu cấp độ như vậy. Và, tin tôi đi, bạn không muốn xem điều gì xảy ra với việc ghi nhật ký chi tiết nhất với dung lượng trống trên đĩa của bạn.
Khỏe. Chúng tôi đã hiểu đại khái những gì chúng tôi muốn lưu, nhưng một câu hỏi chính đáng được đặt ra: lấy thông tin này từ đâu? Tất nhiên, chúng tôi tạo thành một phần của các sự kiện để tự ghi nhật ký bằng các quy trình nội bộ của mình. Nhưng phải làm gì khi có sự tương tác với môi trường bên ngoài? Để không trượt vào địa ngục của nạng và xe đạp, Veeam có xu hướng không phát minh ra những phát minh đã được phát minh. Bất cứ khi nào có API làm sẵn, chức năng tích hợp sẵn, thư viện, v.v., chúng tôi sẽ ưu tiên cho các tùy chọn làm sẵn trước khi bắt đầu rào các thiết bị của mình. Mặc dù sau này cũng là đủ. Do đó, khi phân tích nhật ký, điều quan trọng là phải hiểu rằng phần lớn lỗi rơi vào các thông báo từ API của bên thứ ba, lệnh gọi hệ thống và các thư viện khác. Trong trường hợp này, vai trò của VBR là chuyển tiếp các lỗi này sang tệp nhật ký. Và nhiệm vụ chính của người dùng là học cách hiểu dòng nào là của ai và “ai” này chịu trách nhiệm về việc gì. Vì vậy, nếu một mã lỗi từ nhật ký VBR đưa bạn đến một trang MSDN, thì điều đó tốt và chính xác.
Như chúng ta đã thống nhất trước đó: Veeam được gọi là ứng dụng dựa trên SQL. Điều này có nghĩa là tất cả các cài đặt, tất cả thông tin và nói chung là mọi thứ chỉ cần thiết cho hoạt động bình thường - mọi thứ đều được lưu trữ trong cơ sở dữ liệu của nó. Do đó, sự thật đơn giản: những gì không có trong nhật ký rất có thể có trong cơ sở dữ liệu. Nhưng đây cũng không phải là viên đạn bạc: một số thứ không có trong nhật ký cục bộ của các thành phần Veeam, cũng như trong cơ sở dữ liệu của nó. Do đó, bạn cần học cách nghiên cứu nhật ký máy chủ, nhật ký của máy cục bộ và nhật ký của mọi thứ liên quan đến quá trình sao lưu và khôi phục. Và nó cũng xảy ra rằng thông tin cần thiết không có sẵn ở bất cứ đâu. Đó chính là cách giải quyết.
Một số ví dụ về các API như vậy
Danh sách này không nhằm mục đích hoàn thành một cách đặc biệt, vì vậy không cần phải tìm kiếm sự thật cuối cùng trong đó. Mục đích của nó chỉ là để hiển thị các API và công nghệ phổ biến nhất của bên thứ ba được sử dụng trong các sản phẩm của chúng tôi.
Hãy bắt đầu với VMware.
Đầu tiên trong danh sách sẽ là API vSphere. Được sử dụng để xác thực, đọc cấu trúc phân cấp, tạo và xóa ảnh chụp nhanh, yêu cầu thông tin về máy và nhiều (rất nhiều) hơn thế nữa. Chức năng của giải pháp rất rộng, vì vậy tôi có thể đề xuất Tham chiếu API VMware vSphere cho phiên bản и . Đối với các phiên bản hiện tại hơn, mọi thứ chỉ là googled.
API VIX. Ma thuật đen của trình ảo hóa, có một phần riêng . VMware API để làm việc với các tệp trên máy chủ mà không cần kết nối với chúng qua mạng. Phương án cuối cùng khi bạn cần đặt một tệp vào máy mà không có kênh liên lạc nào tốt hơn. Thật khó chịu nếu tệp lớn và máy chủ được tải. Nhưng ở đây, quy tắc hoạt động là thậm chí 56,6 Kb / s vẫn tốt hơn 0 Kb / s. Trong Hyper-V, thứ này được gọi là PowerShell Direct. Nhưng đó chỉ là trước đây
API dịch vụ web vSpehere Bắt đầu từ vSphere 6.0 (xấp xỉ, vì API này được giới thiệu lần đầu tiên trên phiên bản 5.5), nó được sử dụng để hoạt động với các máy khách và đã thay thế VIX ở hầu hết mọi nơi. Trên thực tế, đây là một API khác để quản lý vSphere. Đối với những người quan tâm, tôi khuyên bạn nên nghiên cứu thủ công.
VDĐK (Bộ công cụ phát triển đĩa ảo). Thư viện, đã được thảo luận một phần trong phần này . Được sử dụng để đọc đĩa ảo. Ngày xửa ngày xưa, nó là một phần của VIX, nhưng theo thời gian, nó đã được chuyển thành một sản phẩm riêng biệt. Nhưng với tư cách là người thừa kế, nó sử dụng các mã lỗi giống như VIX. Nhưng vì một số lý do, không có mô tả nào về các lỗi này trong chính SDK. Do đó, theo kinh nghiệm, người ta phát hiện ra rằng các lỗi VDDK với các mã khác chỉ là bản dịch từ mã nhị phân sang mã thập phân. Nó bao gồm hai phần - nửa đầu là thông tin không có giấy tờ về bối cảnh và phần thứ hai là các lỗi VIX / VDDK truyền thống. Ví dụ: nếu chúng ta thấy:
VDDK error: 21036749815809.Unknown error
Sau đó, chúng tôi mạnh dạn chuyển đổi số này thành hex và nhận được 132200000001. Chúng tôi chỉ cần loại bỏ phần đầu không có thông tin của 132200 và phần còn lại sẽ là mã lỗi của chúng tôi (VDDK 1: Lỗi không xác định). Về các lỗi VDDK thường gặp nhất, gần đây đã có một lỗi riêng .
Bây giờ chúng ta hãy nhìn vào Các cửa sổ.
Ở đây, mọi thứ cần thiết và quan trọng nhất đối với chúng tôi đều có thể được tìm thấy trong tiêu chuẩn Event Viewer. Nhưng có một nhược điểm: theo truyền thống lâu đời, Windows không ghi lại toàn bộ lỗi mà chỉ ghi số của nó. Ví dụ: lỗi 5 là “Truy cập bị từ chối” và 1722 là “Máy chủ RPC không khả dụng” và 10060 là “Đã hết thời gian kết nối”. Tất nhiên, thật tuyệt nếu bạn nhớ những cái nổi tiếng nhất, nhưng còn những cái chưa từng thấy thì sao?
Và để cuộc sống dường như không có mật ngọt chút nào, các lỗi cũng được lưu trữ ở dạng thập lục phân, với tiền tố 0x8007. Ví dụ: 0x8007000e thực sự là 14, Hết bộ nhớ. Tại sao và cho ai điều này đã được thực hiện là một bí ẩn bao phủ trong bóng tối. Tuy nhiên, bạn có thể tải xuống danh sách đầy đủ các lỗi miễn phí và không cần SMS từ .
Nhân tiện, đôi khi có các tiền tố khác, không chỉ 0x8007. Trong một tình huống đáng buồn như vậy, để hiểu HRESULT (“xử lý kết quả”), bạn cần tìm hiểu sâu hơn nữa về cho các nhà phát triển. Trong cuộc sống bình thường, tôi không khuyên bạn nên làm điều này, nhưng nếu bạn đột nhiên áp sát vào tường hoặc chỉ tò mò, thì bây giờ bạn biết phải làm gì.
Nhưng các đồng chí ở Microsoft đã thương hại chúng tôi một chút và cho cả thế giới thấy một tiện ích . Đây là một niềm vui nho nhỏ của bảng điều khiển có thể dịch mã lỗi thành con người mà không cần sử dụng Google. Nó hoạt động như thế này.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Một câu hỏi chính đáng được đặt ra: tại sao chúng ta không ghi ngay phần giải mã vào nhật ký mà lại để lại những mã bí ẩn này? Câu trả lời là trong các ứng dụng của bên thứ ba. Khi bạn tự mình thực hiện một số lệnh gọi WinAPI, không khó để giải mã phản hồi của nó, bởi vì thậm chí còn có một lệnh gọi WinAPI đặc biệt cho việc này. Nhưng như đã đề cập, mọi thứ chỉ đến với chúng tôi trong các phản hồi đều được ghi vào nhật ký của chúng tôi. Và ở đây, để giải mã nó, người ta sẽ phải liên tục theo dõi luồng ý thức này, lấy ra các phần có lỗi Windows từ đó, giải mã và dán lại. Hãy trung thực, không phải là hoạt động thú vị nhất.
API quản lý tệp của Windows được sử dụng theo mọi cách có thể khi làm việc với tệp. Tạo tệp, xóa, mở để ghi, làm việc với các thuộc tính, v.v.
đã đề cập ở trên PowerShell trực tiếp như một dạng tương tự của API VIX trong thế giới Hyper-V. Thật không may, nó không linh hoạt: rất nhiều hạn chế về chức năng, nó không hoạt động với mọi phiên bản của máy chủ và không phải với tất cả khách.
RPC (Cuộc gọi thủ tục từ xa) Tôi không nghĩ rằng có một người nào đã từng làm việc với WIndows mà không thấy các lỗi liên quan đến RPC. Bất chấp quan niệm sai lầm phổ biến, đây không phải là một giao thức đơn lẻ mà là bất kỳ giao thức máy khách-máy chủ nào đáp ứng một số tham số. Tuy nhiên, nếu có lỗi RPC trong nhật ký của chúng tôi, thì 90% trường hợp đó sẽ là lỗi từ Microsoft RPC, đây là một phần của DCOM (Mô hình đối tượng thành phần phân tán). Bạn có thể tìm thấy một lượng lớn tài liệu về chủ đề này trên mạng, nhưng phần lớn tài liệu về nó đã khá lỗi thời. Nhưng nếu có một mong muốn cấp thiết để nghiên cứu chủ đề này, thì tôi có thể giới thiệu các bài báo , và danh sách dài .
Nguyên nhân chính gây ra lỗi RPC trong nhật ký của chúng tôi là do không thể giao tiếp giữa các thành phần VBR (ví dụ: máy chủ > proxy) và thường là do sự cố giao tiếp.
Đỉnh cao nhất trong số tất cả các đỉnh là lỗi Máy chủ RPC không khả dụng (1722). Nói một cách đơn giản, máy khách không thể thiết lập kết nối với máy chủ. Làm thế nào và tại sao - không có câu trả lời duy nhất, nhưng thường thì đó là vấn đề với xác thực hoặc với quyền truy cập mạng vào cổng 135. Cái sau là điển hình cho cơ sở hạ tầng có gán cổng động. Về chủ đề này, thậm chí còn có . Và Microsoft đã để tìm ra nguyên nhân của sự thất bại.
Lỗi phổ biến thứ hai: Không có thêm điểm cuối nào từ trình ánh xạ điểm cuối (1753). Máy khách hoặc máy chủ RPC không thể tự gán cổng. Thường xảy ra khi máy chủ (trong trường hợp của chúng tôi là máy khách) đã được cấu hình để phân bổ động các cổng từ một phạm vi hẹp đã kết thúc. Và nếu bạn đăng nhập từ phía máy khách (trong trường hợp của chúng tôi là máy chủ VBR), điều này có nghĩa là VeeamVssAgent của chúng tôi không khởi động hoặc không được đăng ký làm giao diện RPC. Về chủ đề này cũng có .
Chà, để hoàn thành 3 lỗi RPC hàng đầu, hãy nhớ chức năng gọi RPC không thành công (1726). Xuất hiện nếu kết nối đã được thiết lập, nhưng các yêu cầu RPC không được xử lý. Ví dụ: chúng tôi yêu cầu thông tin về trạng thái của VSS (đột nhiên một quả mìn bóng tối đang được tạo ở đó và chúng tôi đang cố gắng leo lên), và để đáp lại chúng tôi, hãy im lặng và phớt lờ.
API sao lưu băng Windows cần thiết để làm việc với các thư viện băng hoặc ổ đĩa. Như tôi đã đề cập ở phần đầu: chúng tôi không vui gì khi viết trình điều khiển của riêng mình và sau đó khổ sở với sự hỗ trợ của từng thiết bị. Do đó, vim không có bất kỳ trình điều khiển nào của riêng nó. Tất cả thông qua một API tiêu chuẩn, sự hỗ trợ được thực hiện bởi chính các nhà cung cấp phần cứng. Như vậy hợp lý hơn nhiều đúng không?
SMB / CIFS Theo thói quen, mọi người viết chúng cạnh nhau, mặc dù không phải ai cũng nhớ rằng CIFS (Hệ thống tệp Internet chung) chỉ là một phiên bản riêng của SMB (Khối tin nhắn máy chủ). Vì vậy, không có gì sai khi khái quát hóa các khái niệm này. Samba đã là một triển khai LinuxUnix và nó có những đặc thù riêng, nhưng tôi lạc đề rồi. Điều quan trọng ở đây: khi Veeam yêu cầu ghi một cái gì đó vào đường dẫn UNC (thư mục máy chủ), máy chủ sẽ sử dụng hệ thống phân cấp trình điều khiển hệ thống tệp, bao gồm mup và mrxsmb, để ghi vào quả bóng. Theo đó, các trình điều khiển này cũng sẽ phát sinh lỗi.
không thể làm mà không có API Winsock. Nếu cần thực hiện điều gì đó qua mạng, VBR sẽ hoạt động thông qua Windows Socket API, thường được gọi là Winsock. Vì vậy, nếu chúng tôi thấy một loạt IP:Port trong nhật ký, thì chính là nó. Các tài liệu chính thức có một danh sách tốt có thể .
đã đề cập ở trên WMI (Windows Management Instrumentation) là một loại API toàn năng để quản lý mọi thứ và mọi người trong thế giới Windows. Ví dụ, khi làm việc với Hyper-V, hầu như tất cả các yêu cầu đến máy chủ đều đi qua nó. Nói một cách dễ hiểu, thứ này hoàn toàn không thể thay thế và rất mạnh mẽ trong khả năng của nó. Trong nỗ lực giúp tìm ra vị trí và cái gì bị hỏng, công cụ WBEMtest.exe tích hợp sẵn sẽ giúp ích rất nhiều.
Và cuối cùng trong danh sách, nhưng không có nghĩa là kém quan trọng nhất - VSS (Lưu trữ bóng âm lượng). Chủ đề này là vô tận và bí ẩn như nhiều tài liệu đã được viết về nó. Shadow Copy được hiểu đơn giản nhất là một loại ảnh chụp đặc biệt, mà bản chất của nó là như vậy. Nhờ anh ấy, bạn có thể tạo các bản sao lưu phù hợp với ứng dụng trong VMware và hầu hết mọi thứ trong Hyper-V. Tôi đã có kế hoạch làm một bài viết riêng về một số bóp trên VSS, nhưng bây giờ bạn có thể thử đọc . Chỉ cần cẩn thận, bởi vì. cố gắng hiểu VSS trong nháy mắt có thể dẫn đến chấn thương não.
Về điều này, có lẽ, chúng ta có thể dừng lại. Tôi coi nhiệm vụ giải thích những điều cơ bản nhất đã hoàn thành, vì vậy trong chương tiếp theo chúng ta sẽ xem xét nhật ký. Nhưng nếu bạn có bất kỳ câu hỏi nào, vui lòng hỏi họ trong phần bình luận.
Nguồn: www.habr.com