Câu hỏi về điểm thất bại duy nhất cho các hoạt động nhỏ


9
  1. Nếu bạn không đủ khả năng hoặc không cần một cụm hoặc máy chủ dự phòng đang chờ để trực tuyến trong trường hợp xảy ra lỗi, có vẻ như bạn có thể chia các dịch vụ được cung cấp bởi một máy chủ mạnh mẽ thành hai máy chủ ít mạnh hơn. Do đó, nếu Máy chủ A ngừng hoạt động, khách hàng có thể mất quyền truy cập, giả sử email và nếu Máy chủ B không hoạt động, họ có thể mất quyền truy cập vào hệ thống ERP .

    Mặc dù lúc đầu, điều này có vẻ đáng tin cậy hơn, nhưng nó không đơn giản làm tăng khả năng lỗi phần cứng? Vì vậy, bất kỳ một thất bại nào cũng sẽ không ảnh hưởng lớn đến năng suất, nhưng bây giờ bạn đang tự đặt ra cho mình gấp đôi số lần thất bại.

    Khi tôi nói "ít thịt bò", điều tôi thực sự muốn nói là thông số kỹ thuật thấp hơn, không phải chất lượng thấp hơn. Vì vậy, một đặc điểm kỹ thuật của máy được hiển thị so với hai máy chủ được chỉ định để tải ít hơn mỗi máy chủ.

  2. Thông thường, SAN được khuyến nghị để bạn có thể sử dụng phân cụm hoặc di chuyển để duy trì dịch vụ. Nhưng còn bản thân SAN thì sao? Nếu tôi đặt tiền vào nơi xảy ra lỗi, thì đó sẽ không phải là phần cứng máy chủ cơ bản, nó sẽ có liên quan đến việc lưu trữ. Nếu bạn không có một số SAN dư thừa, thì những máy chủ dự phòng đó sẽ không mang lại cho tôi cảm giác tự tin tuyệt vời. Cá nhân đối với một hoạt động nhỏ, sẽ hợp lý hơn đối với tôi khi đầu tư vào các máy chủ có các thành phần dự phòng và ổ đĩa cục bộ. Tôi có thể thấy một lợi ích trong các hoạt động lớn hơn trong đó giá cả và tính linh hoạt của SAN có hiệu quả về chi phí. Nhưng đối với các cửa hàng nhỏ hơn, tôi không thấy đối số, ít nhất là không chịu lỗi.

Câu trả lời:


7

Tất cả điều này sôi xuống để quản lý rủi ro. Thực hiện một phân tích chi phí / rủi ro thích hợp của các hệ thống CNTT của bạn sẽ giúp bạn tìm ra nơi để tiêu tiền và những rủi ro bạn có thể hoặc phải sống cùng. Có một chi phí liên quan đến tất cả mọi thứ ... điều này bao gồm HA và thời gian chết.

Tôi làm việc tại một nơi nhỏ vì vậy tôi hiểu cuộc đấu tranh này và sự đam mê CNTT trong tôi muốn không có điểm thất bại nào ở bất cứ đâu nhưng chi phí để làm điều đó ở mọi cấp độ không phải là một lựa chọn thực tế. Nhưng đây là một vài điều mà tôi có thể làm mà không cần có ngân sách lớn. Điều này không phải lúc nào cũng có nghĩa là loại bỏ điểm duy nhất của sự thất bại.

Network Edge : Chúng tôi có 2 kết nối internet là T1 và Comcast Business. Kế hoạch chuyển tường lửa của chúng tôi sang một cặp máy tính cũ chạy pfSense bằng CARP cho HA.

Mạng : Nhận một vài công tắc được quản lý cho lõi mạng và sử dụng liên kết để phân chia các máy chủ quan trọng giữa hai công tắc sẽ ngăn chặn lỗi chuyển đổi lấy ra toàn bộ tủ dữ liệu.

Máy chủ : Tất cả các máy chủ đều có RAID và nguồn điện dự phòng.

Máy chủ dự phòng : Tôi có một hệ thống cũ không mạnh bằng máy chủ tệp chính nhưng nó có một vài ổ đĩa sata lớn trong raid5, có các ảnh chụp nhanh hàng giờ của máy chủ tệp chính. Tôi đã thiết lập tập lệnh cho việc này để chuyển đổi vai trò thành máy chủ tệp chính nếu nó bị hỏng.

Máy chủ sao lưu ngoại vi : Tương tự như sao lưu tại chỗ, chúng tôi sao lưu hàng đêm vào máy chủ qua đường hầm vpn đến một trong những ngôi nhà của chủ sở hữu.

Máy ảo : Tôi có một cặp máy chủ vật lý chạy một số dịch vụ bên trong các máy ảo sử dụng Xen. Chúng đang chạy một chia sẻ NFS trên máy chủ tệp chính và tôi có thể thực hiện di chuyển trực tiếp giữa các máy chủ vật lý nếu có nhu cầu.


Cảm ơn! Nhưng tôi thực sự hỏi về việc sử dụng hai máy chủ trên một mà không cần phân cụm hoặc sao chép ... về cơ bản chỉ là phân chia dịch vụ giữa hai máy chủ. Và nếu một NAS hoặc SAN được sử dụng để lưu trữ, thì đó không phải là chỉ tạo lại điểm thất bại duy nhất sao? Từ quan điểm thành phần chắc chắn tôi sẽ luôn có dự phòng (ổ đĩa, v.v.). Nhưng điều đó không giúp ích gì khi bộ điều khiển RAID bị hỏng và phá vỡ mảng.
Boden

Vâng, tôi đã từng mất một mảng RAID5 vào một mạch hoạt động sai trong khung trao đổi nóng làm hỏng toàn bộ chuỗi. Điều đó không phải là vấn đề với các tương đương nối tiếp hiện đại như với các xe buýt song song cũ. Loại bỏ những điểm thất bại duy nhất sẽ không hiệu quả về mặt chi phí ở quy mô mà bạn đang nói đến. Trừ khi chi phí cho một thất bại là rất cao không có khả năng. Tôi có một đề nghị mặc dù ... nhưng tôi sẽ làm điều đó trong một bình luận khác.
3dinfluence

Nếu bạn chỉ có 2 máy chủ, bạn có thể làm điều này. Giả sử cả hai máy chủ có đủ dung lượng lưu trữ / ram và hỗ trợ ảo hóa. Bạn có thể thiết lập Xen trên cả hai máy chủ. Thiết lập các công việc cron trên mỗi máy để lưu trạng thái của các máy ảo và sao chép tệp kết quả vào máy vật lý khác hàng đêm. Theo cách đó, nếu bạn gặp lỗi hệ thống, bạn có thể sao lưu và chạy nhanh trên phần cứng còn lại. Trừ đi những gì từng thay đổi xảy ra ngày hôm đó ít nhất.
3dinfluence

Đó là một gợi ý thú vị. Tuy nhiên, điều đó có khả năng làm tăng đáng kể chi phí của các máy chủ. Mỗi người sẽ phải có khả năng chạy tải của người kia (mặc dù có lẽ với hiệu suất bị suy giảm). Bạn sẽ tiêu loại tiền đó, vậy thì tại sao không có hai máy chủ giống hệt nhau với một máy chủ nóng?
Boden

Tất cả điều này quay trở lại việc quản lý chi phí / rủi ro. Bạn đang ở vị trí tốt nhất để trả lời các câu hỏi như: Việc chạy các dịch vụ của bạn trong hiệu suất xuống cấp tốt hơn so với việc chúng bị ngừng hoạt động? Bạn có sẵn sàng để mất tất cả các thay đổi kể từ ảnh chụp nhanh cuối cùng không? Bạn có thể có được xung quanh đó với một số chiến lược sao lưu. Đến một điểm không có điểm thất bại duy nhất là khó khăn nếu không có nền kinh tế quy mô làm việc có lợi cho bạn. Amazon Cloud có thể là một lựa chọn. Nhưng ảo hóa đang thay đổi điều này nhưng không hoàn toàn ở đó và có thể không có 2 máy chủ. Các dự án như Sheepdog trông thú vị.
3dinfluence

5

Tôi nghĩ rằng đây là một câu hỏi có nhiều câu trả lời nhưng tôi đồng ý ở nhiều cửa hàng nhỏ hơn, một số giải pháp máy chủ hoạt động và như bạn nói, ít nhất một cái gì đó sẽ tiếp tục nếu có lỗi. Nhưng nó phụ thuộc vào những gì thất bại.

Rất khó để bao gồm tất cả các cơ sở nhưng nguồn cung cấp năng lượng dự phòng, năng lượng chất lượng tốt và sao lưu tốt có thể giúp đỡ.

Chúng tôi đã sử dụng Backup Exec System Recovery cho một số hệ thống quan trọng. Không quá nhiều để sao lưu hàng ngày nhưng là một công cụ phục hồi. Chúng tôi có thể khôi phục phần cứng khác nhau, nếu có và chúng tôi cũng sử dụng phần mềm để chuyển đổi hình ảnh sao lưu sang Máy ảo. Nếu máy chủ bị lỗi và chúng tôi cần chờ sửa chữa phần cứng, chúng tôi có thể khởi động VM trên một máy chủ hoặc máy trạm khác và đi khập khiễng. Không hoàn hảo nhưng nó có thể lên và chạy nhanh.


3

Về SAN: Hầu hết mọi thứ bạn sử dụng sẽ là dư thừa. Ngay cả khi đó là một vỏ bọc đơn, bên trong sẽ là nguồn cung cấp năng lượng kép, đầu nối kép và 'đầu' kép, mỗi đầu có liên kết với tất cả các đĩa. Ngay cả một thứ đơn giản như MD3000 được bán bởi Dell cũng có tất cả các tính năng này. SAN được thiết kế để trở thành cốt lõi của các hộp của bạn, vì vậy chúng được chế tạo để tồn tại bất kỳ lỗi phần cứng ngẫu nhiên nào.

Điều đó đang được nói, bạn có một điểm rằng dự phòng không phải luôn luôn là lựa chọn tốt nhất. ĐẶC BIỆT nếu nó làm tăng sự phức tạp. (và nó sẽ) Một câu hỏi hay hơn để hỏi là ... "Công ty sẽ chấp nhận bao nhiêu thời gian chết". Nếu việc mất máy chủ mail của bạn trong một hoặc hai ngày không phải là vấn đề lớn, thì có lẽ bạn không nên bận tâm với hai người trong số họ. Nhưng nếu một máy chủ web ngừng hoạt động bắt đầu làm bạn mất tiền thật mỗi phút, thì có lẽ bạn nên dành thời gian để tạo một cụm thích hợp cho nó.


2

Càng nhiều máy chủ bạn càng có nhiều cơ hội phá vỡ thứ gì đó, đó là một cách để xem xét nó. Một cách khác là nếu một lần phá vỡ, bạn sẽ đạt được 100%, giống như bạn đang nói.

Lỗi phần cứng phổ biến nhất là HD, giống như bạn đã nói ở trên. Bất kể bạn muốn phân chia các hoạt động giữa bao nhiêu, bạn cần RAID cho bạn lưu trữ.

Tôi sẽ bỏ phiếu cho một vài máy chủ (tất nhiên là RAID) thay vì một máy chủ lớn, cả về sự ổn định và hiệu suất hoạt động. Ít phần mềm va vào mỗi yêu cầu tài nguyên, giảm sự lộn xộn, nhiều đĩa được đọc / ghi vào, v.v.


2

Cá nhân tôi sẽ chọn cho nhiều máy chủ. Tôi không nghĩ rằng sự cố thiết bị có nhiều khả năng trong kịch bản này. Có, bạn có nhiều thiết bị có thể thất bại, nhưng tỷ lệ của bất kỳ đơn vị nào bị lỗi sẽ không đổi.

Điều có nhiều máy chủ trong cấu hình không dự phòng / không HA mang lại cho tôi là khả năng giảm tải một số công việc cho máy chủ khác trong trường hợp xảy ra lỗi. Vì vậy, nói rằng máy chủ in của tôi đi xuống. Nếu tôi có thể ánh xạ một vài máy in đến máy chủ tệp trong khi tôi sửa máy chủ in, tác động đến các hoạt động sẽ giảm đi. Và đó là nơi nó thực sự quan trọng. Chúng ta thường có xu hướng nói về sự dư thừa phần cứng, nhưng phần cứng chỉ là một công cụ để tiếp tục hoạt động.


Chà, tỷ lệ trúng xổ số của bạn sẽ cao hơn nếu bạn mua hai vé, mặc dù nó không thực sự khác biệt nhiều. Một máy chủ có cuộc gọi 6 giờ để sửa chữa có thể ít tốn kém hơn hai, ngay cả khi bao thanh toán bị mất từ ​​sáu giờ ngừng hoạt động. Mặc dù tôi đồng ý rằng một số dịch vụ có thể được chuyển nhanh chóng đến máy chủ thứ hai, thời gian cần thiết để di chuyển các dịch vụ lớn hơn có thể lớn hơn thời gian để sửa chữa máy chủ bị lỗi. "Có thể" là từ khóa. Đó là một vấn đề thú vị. Cảm ơn vì đã phản hồi!
Boden

1

Tôi làm việc trong một cửa hàng nhỏ (bộ phận CNTT một người) và sẽ không trao đổi nhiều máy chủ của tôi cho một máy chủ trong bất kỳ trường hợp nào. Nếu bất kỳ một trong các máy chủ gặp sự cố, tôi có tùy chọn thêm các dịch vụ hiện đang thiếu vào một máy khác hoặc thậm chí chỉ cần thiết lập chúng trên một PC dự phòng. Chúng ta có thể sống với sự cố mất một hoặc hai giờ cho hầu hết mọi thứ nhưng chúng ta không thể sống với sự ngừng hoạt động hoàn toàn của tất cả các hệ thống. Mặc dù tôi có thể thay thế bất kỳ máy chủ nào của chúng tôi bằng PC, ít nhất là tạm thời, tôi không có hoặc có thể dễ dàng nắm giữ mọi thứ gần như đủ mạnh để thay thế tất cả các máy chủ cùng một lúc.


1

Bài đăng gốc của bạn đưa ra giả thuyết rằng bạn không thể đủ khả năng cho một cụm, nhưng bạn xem xét các giải pháp với hai máy chủ (không bao gồm các bản sao lưu). Điều đó có nghĩa là rất có thể bạn có ba máy chủ trong tay, đủ để bắt đầu một cụm.

Có các giải pháp trung gian có thể tránh SPoF và vẫn phù hợp trong các doanh nghiệp vừa / nhỏ: nhân rộng từ nút sang nút mà không cần lưu trữ SAN.

Điều này được Proxmox hỗ trợ (nhưng tôi nghĩ nó cũng được hỗ trợ bởi XCP-ng / XenServer và có lẽ bởi ESXi).

Hãy xem xét thiết lập 3 nút. Tất cả đều có RAID, PSU dự phòng, mạng dự phòng.

  • Nút A và B có CPU mạnh mẽ và nhiều RAM.
  • Node C khiêm tốn hơn về CPU / RAM nhưng có nhiều dung lượng lưu trữ và được sử dụng để cung cấp đại biểu cho cơ quan giám sát tính sẵn sàng cao và sao lưu máy chủ.

Sau đó, hai lựa chọn:

  1. Tất cả các máy ảo thường chạy trên nút A và được sao chép trên nút B (yêu cầu các CPU riêng biệt)
  2. Các VM được phân chia giữa nút A và B và được sao chép lẫn nhau từ nút A đến nút B và từ nút B đến nút A.

Kiểu thiết lập này có thể chịu được lỗi mạng, lỗi toàn bộ và nút lớn (bất kỳ trong số ba), với thời gian ngừng hoạt động khoảng 1 phút (khoảng thời gian cần thiết để VM khởi động). Nhược điểm là mất dữ liệu kể từ lần sao chép cuối cùng (tùy thuộc vào cài đặt và hiệu suất phần cứng của bạn có thể thấp đến 1 phút và cao đến vài giờ).

Với tùy chọn thứ 2 (VM thường phân chia giữa nút A và B), bạn phải ưu tiên VM nào được phép quay lại trực tuyến. Vì, khi tải VM của bạn thường được phân chia giữa hai máy chủ, việc tất cả chúng chạy trên một nút có thể làm cạn kiệt RAM của nút hoặc làm tắc nghẽn CPU.


0

"Mặc dù lúc đầu, điều này có vẻ đáng tin cậy hơn, nhưng nó không đơn giản làm tăng khả năng lỗi phần cứng?"

  • Từ quan điểm phần cứng, tôi không thấy nó thực sự làm tăng cơ hội thất bại như thế nào. Có rất nhiều biến số ở đây và tôi chưa bao giờ nghiên cứu xác suất, nhưng để đơn giản hóa hơn: Hãy nói rằng Dell tạo ra 1 máy chủ xấu trên mỗi 100.000 mà họ tạo ra. Cơ hội của bạn đã thay đổi từ 1 trên 100.000 thành 2 trong 100.000 (hoặc 1 trên 50.000). Vì vậy, có, gấp đôi cơ hội, nhưng vẫn vì quy mô mà cơ hội thực tế không khác nhau.
  • Tôi nghĩ quan điểm là chìa khóa ở đây. "Bạn đang tự đặt ra cho mình gấp đôi số lần thất bại." Có thể theo quan điểm của bạn , nhưng trong cả hai kịch bản mà bạn đưa ra, email đang chạy trên một máy chủ và ERP đang chạy trên một máy chủ. Vì vậy, từ quan điểm của email hoặc erp (đó là những gì doanh nghiệp quan tâm), nó thực sự giống nhau. Trừ khi họ cảm thấy cô đơn, hoặc thích không gian của họ ;-)
  • Tôi nghĩ bạn cũng nên nhìn nó từ quan điểm của mọi người. Tôi nghĩ rằng thất bại do sai lầm của mọi người có thể có nhiều khả năng, và theo cách này ai đó có thể chỉ làm hỏng một máy chủ tại một thời điểm. Nó cũng làm cho nó dễ dàng hơn để xác định các vấn đề với những thứ như tải. Nếu cả email và trang web đều chạy trên máy chủ, hãy thêm thời gian để tìm hiểu vấn đề ở đâu.

Nó không bao giờ đơn giản, các máy chủ lớn mạnh mẽ này có thể được thực hiện tốt hơn hoặc tồi tệ hơn được thực hiện. Chúng có thể có các bộ phận chất lượng cao hơn, nhưng có thể tạo ra nhiều nhiệt hơn và không được làm mát đúng cách. Một máy chủ mạnh mẽ có nhiều RAM hơn, nhiều CPU hơn, vì vậy cuối cùng có thể bạn có nhiều CPU trong cả hai trường hợp nên có thể máy chủ không phải là đơn vị phù hợp để suy nghĩ.

Bởi vì sự phức tạp của các cơ hội, bất cứ điều gì là chiến thắng hiệu quả nhất về chi phí tôi nghĩ. Nếu bạn phải trả tiền cho giấy phép thì 1 máy chủ lớn có thể rẻ hơn một vài máy chủ nhỏ hơn tùy thuộc vào cấu trúc cấp phép.


Tôi nghĩ rằng nó làm tăng khả năng lỗi phần cứng. 1/2 MTBF, giả sử cả hai máy chủ đều giống nhau và chạy cùng số giờ và tải ...
Scott Lundberg

Scott: Cập nhật để giải thích thêm một chút, ý tôi là thực tế. Ngoài ra, tôi thực sự nghĩ rằng đó là về quan điểm.
Kyle Brandt

Ngoài ra, các máy chủ không giống nhau ...
Kyle Brandt

Nó làm tăng cơ hội thất bại. RAID0 với hai ổ đĩa có nhiều khả năng bị lỗi sớm hơn một ổ đĩa. Tất nhiên trong trường hợp đó, bạn mất tất cả mọi thứ, vì vậy nó không hoàn toàn tương tự như tình huống tôi đang mô tả: chia dịch vụ của bạn thành hai máy chủ thay vì chạy tất cả trên một. Kết quả của một lỗi không phải là xấu, nhưng bây giờ tôi có nhiều phần cứng có thể bị lỗi.
Boden

Cảm ơn các cập nhật! Tôi xin lỗi và tôi nên có đủ điều kiện câu hỏi của tôi tốt hơn một chút, ít nhất là về mặt "mạnh mẽ". Điều tôi đang nói ở đây là lựa chọn giữa, một HP DL380 với bộ xử lý kép, một tấn RAM và 8 ổ cứng so với hai DL380 với bộ xử lý đơn, ít bộ nhớ và ổ cứng hơn, ít bộ nhớ điều khiển hơn, v.v. ( chỉ là một ví dụ ... nhưng giả sử chất lượng xây dựng của các máy chủ "ít thịt bò" giống như máy chủ "đơn giản") Có, chi phí cao hơn cho hai máy chủ theo cách này, nhưng khi nào thì nó trở nên đáng giá?
Boden

0

Cách tiếp cận mặc định của tôi là để tránh bất kỳ cơ sở hạ tầng tập trung. Ví dụ, điều này có nghĩa là không có SAN , không có Cân bằng tải . Bạn cũng có thể gọi một cách tiếp cận tập trung như vậy là "nguyên khối".

Là một kiến ​​trúc sư phần mềm, tôi đang làm việc với cơ sở hạ tầng của khách hàng. Điều đó có thể có nghĩa là sử dụng trung tâm dữ liệu riêng của họ hoặc sử dụng một cái gì đó như AWS. Vì vậy, tôi thường không kiểm soát được việc họ có sử dụng SAN hay không. Nhưng phần mềm của tôi thường kéo dài nhiều khách hàng, vì vậy tôi xây dựng nó như thể nó sẽ được chạy trên các máy riêng lẻ trên mạng.

Ví dụ email

Email là lạ, bởi vì đó là một hệ thống kế thừa (hoạt động). Nếu email được phát minh ngày hôm nay, nó có thể sẽ sử dụng API RESTFul trên các máy chủ web và dữ liệu sẽ nằm trong cơ sở dữ liệu có thể được sao chép bằng các công cụ thông thường (Sao chép giao dịch, Sao lưu tăng dần).

Giải pháp kiến ​​trúc phần mềm là Ứng dụng Web sẽ kết nối với một trong danh sách các nút khả dụng (ngẫu nhiên) và nếu không có sẵn, nó sẽ cố gắng kết nối với nút khác (ngẫu nhiên). Một khách hàng có thể bị đuổi khỏi máy chủ, nếu nó quá bận. Ở đây, không cần một bộ cân bằng tải để kết nối thông qua một trang trại web; và, không cần SAN vì tính sẵn sàng cao. Cũng có thể phân đoạn cơ sở dữ liệu theo từng bộ phận hoặc địa lý.

Hàng hóa có nghĩa là ...

Vì vậy, thay vì có 1 hoặc 2 máy chủ đắt tiền và SAN với các biện pháp dự phòng nội bộ, bạn có thể sử dụng một số máy móc giá rẻ năng lượng thấp.

  • Đơn giản - dự phòng hoàn toàn đến từ số lượng thiết bị. Bạn có thể dễ dàng xác minh sự dư thừa của mình bằng số lượng máy. Và bạn ước tính chính xác hơn họ có cơ hội thất bại cao hơn và chuẩn bị cho điều đó.

  • Tỷ lệ phần trăm dự phòng - Nếu bạn có 2 máy chủ, nếu một lỗi bạn có 1 trái (50%). Nếu bạn có 10 máy chủ hàng hóa và một máy chủ bị lỗi, bạn còn 9 máy chủ (90%)

  • Hàng tồn kho - một thiết bị hàng hóa có sẵn từ bất kỳ cửa hàng gần đó với một mức giá tuyệt vời.

  • Khả năng tương thích - với các kênh sợi và tất cả các loại tiêu chuẩn cho định dạng ổ đĩa, thiết bị hàng hóa và kiến ​​trúc phần mềm có nghĩa là bạn không bị khóa trong một mô hình hoặc nhãn hiệu thiết bị duy nhất.

  • Hiệu suất - Với 2 thiết bị trên SAN, chúng cần ở trong cùng một phòng. Với phương pháp tiếp cận máy hàng hóa, nếu bạn có 5 văn phòng, bạn có thể có 2 văn phòng ở mỗi văn phòng, với dự phòng VPN WAN giữa các văn phòng. Điều này có nghĩa là phần mềm và comms có trên mạng LAN với thời gian truy cập <1ms.

  • Bảo mật - xây dựng trên mức độ dư thừa cao, bạn có thể dễ dàng xây dựng lại các nút như một quy trình hàng hóa thường xuyên. Bạn muốn xây dựng lại một cụm 2 máy chủ nguyên khối? Nhận ra hướng dẫn. Bằng cách xây dựng lại máy móc thường xuyên (với tự động hóa), bạn luôn cập nhật phần mềm và ngăn chặn bất kỳ tin tặc hoặc vi rút nào có được chỗ đứng trên mạng của bạn.

Lưu ý: Bạn vẫn cần có nhiều dự phòng bộ chuyển mạch và cổng bộ định tuyến

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.