Chọn Tên Miền - Bước Đi Đầu Tiên Quyết Định Thành Công

Thành công từ tên miền 

Thương mại điện tử (E-commerce)  là xu thế phát triển tất yếu trong môi trường kinh doanh toàn cầu hóa như hiện nay. Các doanh nghiệp ngày càng có nhiều cơ hội mở rộng kênh bán hàng, tiếp thị sản phẩm đến người tiêu dùng với sự giúp sức của công nghệ, sự bùng nổ của các thiết bị kết nối Internet, ứng dụng di động…

Thương mại điện tử ngày càng phát triển mạnh mẽ và trở thành một xu thế tất yếu của kinh tế toàn cầu. Trung bình 10 siêu thị tại các quốc gia châu Âu và Mỹ thì có một nơi phải đóng cửa do người tiêu dùng ngày càng ưa chuộng hình thức mua sắm trực tuyến.

Thị trường thương mại điện tử ởViệt Nam cũng diễn ra vô cùng sôi động trong những năm gần đây. Thống kê cho thấy năm 2014, doanh thu thương mại điện tử của cả nước đạt tới 2,97 tỉ USD, chiếm 2,12% tổng doanh thu bán lẻ của cả thị trường. Số liệu cho thấy, thị phần dành cho thương mại điện tử ở Việt Nam còn rất rộng mở.

Nhưng không phải doanh nghiệp Việt Nam nào cũng thành công khi ứng dụng thương mại điện tử do doanh nghiệp chưa thực sự có tầm nhìn xa và mục tiêu dài hạn. Có rất nhiều doanh nghiệp trong nước chưa đánh giá đúng tầm quan trọng của một website chính thống, hoạt động ổn định để phục vụ lâu dài cho hoạt động thương mại điện tử.

Xây dựng website với tên miền uy tín, hoạt động ổn định không phải là công việc quá phức tạp và tốn quá nhiều chi phí. Nhưng nếu doanh nghiệp không có định hướng và đầu tư đúng đắn ngay từ đầu thì hoạt động thương mại điện tử của doanh nghiệp sẽ gặp khá nhiều khó khăn, thậm chí không thể thực hiện được.

Read more

Khi Nào Cần Đăng Ký Tên Miền Miễn Phí

Dựa vào nhu cầu và mức độ quan trọng của website đối với doanh nghiệp, cá nhân mà có sự lựa chọn tên miền khác nhau có phí hoặc miễn phí. Vậy khi nào thì đăng ký tên miền miễn phí?

Bài viết này sẽ chia tên miền thành 2 loại:

Tên miền miễn phí là những tên miền có đuôi sạng tk, co.cc, …

Tên miền trả phí là những tên miền dạng .com, .net, .org, .vn hay .com.vn, ...

Khi nào thì nên đăng ký tên miền miễn phí

Khi bạn chỉ muốn tìm hiểu, code nghịch ngợm, test website.

Bạn không quan tâm đến lưu lượng truy cập hay thứ hạng kết quả  tìm kiếm trên google.

Bạn muốn xây dựng một thế giới riêng, một trang cá nhân mà không cần ai đụng vào hay biết tới.

Bạn chấp nhận việc mất dữ liệu, tên miền bất cứ lúc nào.

6 lý do nên sử dụng tên miền trả phí 

- Với mỗi doanh nghiệp, tổ chức hay cá nhân, tên miền chính là bộ mặt trên internet. Nên nó chính là lý do đầu tiên bạn không nên sử dụng tên miền miễn phí.

- Khi bạn có một tên miền trả phí là website của bạn sẽ được nằm trong danh mục tìm kiếm của Google. Mới đây, Google đã loại bỏ toàn bộ tất cả các kết quả tìm kiếm liên quan đến co.cc, một cú sốc cho các webmaster tiếc khoản tiền nhỏ mà bỏ đi lợi ích lâu dài. Do vậy khi có ai đó search trên google với từ khóa của bạn đặt thì trang của bạn sẽ không hy vọng được vào top ten 10 kết quả của google đưa ra. Mà có thể nó nằm ở trang thứ vài chục hoặc vài trăm hoặc thậm chí còn không có.

- Khách đến thăm trang web của bạn với một tên miền thương mại sẽ đánh giá trang web của bạn cao hơn là một tên miền miễn phí. Ví dụ www.powernet.vn thì hay hơn và hoành tráng hơn nhiều so với www.powernet.co.cc hay là www.powernet.tk,…

- Nếu bạn muốn kiếm tiền từ trang web của mình, thì một tên miền thương mại luôn cho đối tác sẽ đặt quảng cáo trên trang web của bạn một sự tin tưởng nhất định.

- Dịch vụ miễn phí có thể “chết” bất cứ lúc nào và bạn không thể làm gì được. Hãy tưởng tượng bạn có một website cứ cho là không nhỏ, với hàng nghìn bài viết, hàng chục nghìn truy cập hàng ngày. Bỗng một hôm nhà cung cấp tuyên bố phá sản, ngừng cung cấp dịch vụ, bạn hình dung ra được khi đó bạn thế nào chứ?

- Không có sự hỗ trợ. Một khi bạn sử dụng dịch vụ miễn phí, đừng trông chờ gì vào việc bạn sẽ được nhà cung cấp hỗ trợ tốt cho dịch vụ của mình. Khi có sự cố, bạn sẽ gặp rất nhiều khó khăn để xử lý nó. Nhất là nếu như bạn không có nhiều kinh nghiệm về CNTT.

Read more

Bảo Vệ Tên Miền Ở Việt Nam Đóng Vai Trò Quan Trọng

Ngày nay, người sử dụng Internet tại Việt Nam đã rất quen thuộc với tên miền .com và tên miền .com.vn

Tên miền đóng vai trò rất quan trọng trong việc xây dựng thương hiệu, bạn không thể xây dựng danh tiếng cho thương hiệu công ty mình khi chưa sở hữu địa chỉ trực tuyến của thương hiệu đó.

Việc Công ty có lấy được một tên miền ( Domain) trùng với nhãn hiệu hàng hóa hay không sẽ ảnh hưởng rất lớn đến thương hiệu của Công ty.

Dẫn đến viêc quảng bá phát triển một thương hiệu lớn hiện nay liên quan chặt chẽ tới khả năng đồng bộ nhãn hàng với một tên miền.

Nếu bạn chọn một tên miền không tương ứng, bạn có thể sẽ gặp một số vấn đề như sau:

Bị mất một số khách hàng tiềm năng. Vì theo thói quen, họ sẽ truy cập vào trang web .com hay .com.vn, nhưng đó không phải là trang web của bạn.

Một tay đầu cơ nào đó mua tên miền này, lập ra trang web làm thiệt hại uy tín công ty bạn và ép bạn phải mua lại tên miền với giá cao.

Đối thủ cạnh tranh của bạn mua tên miền này, và lập ra trang web với thông tin sai lệch về công ty bạn.

Uy tín thương hiệu của công ty bị giảm sút vì không sở hữu được tên miền theo tên công ty của mình.

Bạn có thể liên hệ ngay với Chúng tôi.

Để được tư vấn và chọn những tên miền phù hợp với thương hiệu của Công ty ,thu hút người dùng click vào web của bạn và mang lại hiệu quả kinh doanh lớn.

Đối với tên miền mua tại chúng tôi, bạn sẽ có được những dịch vụ miễn phí. Chúng tôi cung cấp một nền tảng công nghệ đáng tin cậy và an toàn, giải pháp để quản lý tên miền của bạn và các dịch vụ giá trị gia tăng.

Read more

7 Thủ Tục Khi Chuyển Đổi Tên Miền

Chuyển tên miền từ nơi khác chúng tôi tức là chuyển quyền quản lý và gia hạn thêm 1 năm và các năm tiếp sẽ gia hạn tại chúng tôi. Các bước cần thực hiện trước khi chuyển tên miền về chúng tôi.

- Bạn kiểm tra tên miền không bi lock (domain trạng thái active)

- Tên miền còn thời gian duy trì trên 30 ngày

- Bạn đề nghị nhà cung cấp tên miền trước đó cung cấp số Authorization Key

- Bạn phải check được email quản trị tên miền 

- Nộp phí gia hạn tên miền thêm một năm

- Phí gia hạn bằng 80%

Chuyển tên miền|domain về chúng tôi không tốn phí, bạn chỉ cần đóng tiền gia hạn tên miền thêm 1 năm để gia hạn, tên miền của bạn tại chúng tôi tự động gia hạn thêm 1 năm. Thời gian chuyển nhanh nhất là 2 ngày và chậm nhất là 15 ngày làm việc.

Read more

Những Cách Phòng Chống Hách Tên Miền

Hiện nay các trang web có thể bị đánh cướp bất cứ lúc nào nếu không chú trọng đến vấn đề bảo mật cho tên miền. Domain có thể bị tấn công qua nhà cung cấp dịch vụ hoặc khách hàng.

Nếu nhắm vào nhà cung cấp, hacker sẽ lợi dụng sơ hở của người quản trị hay lỗ hổng của máy chủ để chiếm quyền điều khiển. Sau đó chuyển tên miền qua nhà cung cấp khác. Ở cấp độ thấp hơn, kẻ tấn công sẽ nhằm vào các reseller (những người mua lại số lượng lớn tên miền từ các nhà cung cấp gốc để bán lại cho người dùng cuối).

Tuy nhiên, hướng tấn công tên miền phổ biến nhất là nhắm vào phía khách hàng (chiếm khoảng 90% các vụ đánh cắp tên miền). Thủ thuật của hình thức này thường giống nhau là tìm cách chiếm đoạt tài khoản thông qua e-mail được người dùng đăng ký tên miền. Cách thực hiện là gửi Trojan, cài keylogger, dùng fake log-in mail... để trộm mật khẩu, đặc biệt là mật khẩu của e-mail dùng đăng ký tên miền (domain của Diễn đàn tin học bị cướp cũng bằng cách này). Một phương thức khác cũng là mạo danh e-mail rồi gửi tới nhà cung cấp tên miền để yêu cầu thay mật khẩu mới, hay chuyển tên miền qua nơi khác.

Để phòng tránh, điều quan trọng trước nhất là phải chọn mua tên miền ở nơi đáng tin cậy nhất. Chúng tôi cam kết mang đến cho bạn một dịch vụ đáng tin cậy. Bước tiếp theo là phải tự bảo vệ tài khoản tên miền và cả e-mail dùng để đăng ký (hạn chế dùng e-mail này trong các giao dịch khác). Cần yêu cầu nhà cung cấp xác lập trạng thái "khóa" domain và chỉ thực hiện chuyển tên miền khi nhận được yêu cầu của chính người dùng thông qua điện thoại hoặc văn bản, nhằm tránh bị mạo danh.

Ngoài ra, nên thường xuyên quét kiểm tra Trojan, virus, không nhận hay download những file lạ đính kèm e-mail, không vào các website lạ... Đặc biệt là nên thường xuyên kiểm tra trạng thái tên miền thông qua đăng nhập trực tiếp vào website nhà cung cấp

Read more

Hướng Dẫn Cách Kiểm Tra Domain Hết Hạn Và Đăng Ký Tên Miền Hết Hạn

Hướng dẫn các bạn một cách để tìm kiếm các domain quốc tế có độ tuổi + PR cao (4,5,6,7) để mua lại tại các trang web sau:

Mã:

_http://www.expireddomains.net/deleted-com-domains/?o=pr&r=d => .com

_http://www.expireddomains.net/deleted-net-domains/?o=pr&r=d => .net

_http://www.expireddomains.net/deleted-org-domains/?o=pr&r=d => .org

_http://www.expireddomains.net/deleted-info-domains/?o=pr&r=d => .info

_http://domaincom.org => website khá hay để săn tên miền có độ tuổi.

Ở khung Status nếu xuất hiện chữ free có nghĩa là tên miền đó vẫn còn, bạn hãy nhanh tay check  

whois và đăng ký nhé  

Hướng dẫn mua tên miền hết hạn từ  Godaddy:  

Nơi đây mua bán những tên miền hết hạn được đăng ký tại Godaddy. Nơi đây cũng tập trung các domain của những nhà kinh doanh domain sắp hết hạn muốn bán. Đây cũng là một kênh để có thể mua được những tên miền chất lượng giá rẻ.

Hướng dẫn cách mua:

Bước 1

Vào Godaddy.com và đăng ký một tài khoản miễn phí nếu bạn chưa có

Bước 2

Hoặc vào TDNAM.com and bắt đầu chọn Domain.

Bước 3

Sử dụng chức năng tìm kiếm để tối ưu hoá nhu cầu, có thể sử dụng các bộ lọc theo số chữ trong domain, domain có số hay không...

Bước 4

Khi tìm kiếm bằng từ khoá, bạn phải gõ từ khoá hoặc nhiều từ khoá và sau đó chọn từ khoá đứng đầu hay đứng sau domain.

Bước 5

Mỗi domain có chi phí dịch vụ là $10. Nếu bạn mua được domain, bạn sẽ phải trả 10 USD cho chi phí dịch vụ này

Bước 6

Đặt lệnh mua nếu bạn tìm được domain vừa ý. Thông thường nếu là một tên miền thông dụng và đẹp, bạn nên chờ đến gần kết thúc phiên đấu giá hãy đặt lệnh.

Bước 7

Nếu bạn muốn bán domain tại TDNAM.com, chi phí là 5USD để trở thành thành viên.

Bước 8

Khi phân tích để chọn Domain, đừng đặt nặng suy nghĩ về traffic của domain. Hãy nghĩ đến những nhân tố mà người mua sẽ mau lại đặc biệt là khả năng đọc và gõ phím.

Bước 9

Xem xét chọn những tên miền có thể thay thế. Những tên miền thông dụng như YouTube có thể bị gõ nhầm bởi UTube hoặc UToob.

Bước 10

Tránh domain .net, .org. .hoặc bất cứ thứ gì khác ngoài .com

Bước 11

Cuối cùng, bạn có thể tìm kiếm theo nhóm để thấy các domain liên quan theo lĩnh vực bạn muốn mua. Luôn sử dụng chức năng để có thể thấy 500 domain trên 1 trang, điều này giúp bạn có thể đọc lướt và so sánh rất nhanh, đồng thời không bỏ lỡ các ý tưởng trong lúc tìm kiếm.

3, Hướng dẫn săn Domain việt nam hết hạn Pr cao:

Đầu tiên bạn phải có tài khoản tại trang https://ahrefs.com/ : Sau đó bạn check trang Thongbao.vnnic.vn/  xem có bao nhiêu backlink trỏ về trang đó, và việc của bạn chỉ là theo dõi, check lại rồi đăng ký thôi  :)

Read more

Những Lý Do Cần Phải Sử Dụng Giải Pháp Khôi Phục Dữ Liệu Sau Thảm Họa

Trong hiện thời kinh tế phát triển mạnh mẽ ở Việt Nam, sự phát triển lớn mạnh của hệ thống ngành công nghệ thông tin như một trợ thủ đắc lực để giúp các quý doanh nghiệp phát triển.Đi đôi với sự tăng trưởng của tổ chức, doanh nghiệp sẽ kéo theo sự gia tăng không ngừng của hệ thống ngành công nghệ thông tin, nhất là hệ thống lưu trữ dữ liệu như dịch vụ cho thuê máy chủ ảo.Thông thường, các công ty cũng như doanh nghiệp sẽ tự xây dựng triển khai cho mình các trung tâm dữ liệu (chỗ đặt máy chủ), phòng máy chủ với đầy đủ chủng loại thiết bị có cấu hình mạnh, đồng thời chú trọng vào các vấn đề đảm bảo an toàn và khả năng khôi phục dữ liệu cho hệ thống và nâng cao tính sẵn sàng trong mọi hoạt động trao đổi thông tin và coi đó như một phần quan trọng trong việc duy trì mọi hoạt động của tổ chức, doanh nghiệp.

Khôi phục dữ liệu

   Khôi phục dữ liệu sau thảm họa sẽ giúp cho dữ liệu thông tin của các công ty cũng như doanh nghiệp không bị mất đi

   Thảm họa có thể dẫn đến dưới mọi hình thức khác nhau: Thiên tai, bão lũ, động đất, sóng thần, hỏa hoạn, sét đánh, lỗi hệ thống nguồn điện, viruts...gây ra sự mất mát dữ liệu thậm chí phá hỏng hoàn toàn hệ thống gây những thiệt hại cho công ty,tổ chức cũng như doanh nghiệp.

   Giải pháp Khôi phục dữ liệu sau thảm họa (Disaster Recovery) là giải pháp đảm bảo khả năng khôi phục một trung tâm dữ liệu từ một site khác khi site chính gặp thảm họa làm ngưng trệ hoạt động trao đổi thông tin của tổ chức, doanh nghiệp.

Giải phá kỹ thuật

Tùy theo từng mức độ quan trọng của dữ liệu cũng như từng cá nhân doanh nghiệp có thể công ty chúng tôi luôn có những giải pháp dự phòng phù hợp như sau:

Giải pháp đơn giản, chỉ sao lưu dữ liệu dự phòng

Với giải pháp này chỉ có phương án sao lưu dữ liệu dự phòng ra băng từ (tape) hoặc các thiết bị khác. Dữ liệu được sao lưu hằng ngày và các  băng từ được chuyển đến một nơi khác (offsite) để cất giữ. nên khi cần khôi phục các tape được mang trở lại để khôi phục lại phần dữ liệu bị sự cố.

Lợi điểm của giải pháp này là chi phí thấp, quản trị đơn giản rất phù hợp cho các doanh nghiệp vùa và nhỏ.

Giải pháp xây dựng trung tâm dữ liệu dự phòng và sao lưu dữ liệu theo chu kỳ

Với giải pháp này chúng tôi chỉ sao lưu dự phòng dữ liệu kết hợp với một trung tâm dự phòng nhưng ở mức chỉ an toàn cho dữ liệu. Một khi có sự cố tại trung tâm chính chúng ta vẫn đảm bảo toàn bộ dữ liệu của doanh nghiệp vẫn an toàn nhưng cần có thời gian nhất định để khôi phục cho hệ thống máy chủ hoạt động lại. Tuy nhiên do dữ liệu chỉ được sao lưu theo chu kỳ nên có thể sẽ có sự mất mát nhỏ dữ liệu của những giao dịch nằm trong khoảng giữa chu kỳ sao lưu. Ưu điểm của giải pháp là chi phí thấp và hầu như đảm bảo dữ liệu không bị mất mát khi có thảm hoạ xảy ra

Giải pháp xây dựng trung tâm dữ liệu dự phòng và sao lưu dữ liệu trực tuyến (online)

Với giải pháp này chúng ta chăc chắn rằng dữ liệu không bị mất mát và khắc phục được các nhược điểm của giải pháp trên nhờ sao lưu dữ liệu liên tục và tự động thông qua đường truyền nhưng chi phí đầu tư cao hơn.Với giải pháp này tuy chưa đảm bảo an toàn cho tất cả dữ liệu vì sao lưu trực tuyến nhưng hệ thống vẫn cần một khoảng thời gian ngắn để thực thi, nhưng giải pháp này đã có thể đảm bảo gần như 99,99% dữ liệu của doanh nghiệp được sao lưu an toàn.

Khi trung tâm dữ liệu chính bị sự cố, trung tâm dữ liệu dự phòng khôi phục dữ liệu có sẵn và sẵn sàng thay thế trung tâm dữ liệu chính.

Giải pháp xây dựng trung tâm dữ liệu dự phòng và đồng bộ dữ liệu bằng đường truyền cao tốc

Với giải pháp này chúng tôi chắc chắn tất cả dữ liệu của công ty cũng như doanh nghiệp được sao lưu về trung tâm dự phòng nhờ khả năng đồng bộ dữ liệu liên tục. Tức bất kỳ giao dịch phát sinh thay đổi nào tại trung tâm chính đều được đồng bộ ngay tức thời về trung tâm dự phòng.

Mặc dù với giải pháp này đã đảm bảo dự liệu của doanh nghiệp luôn được bảo toàn trong bất kỳ trường hợp sự cố nào ở trung tâm chính, nhưng ngoài nhược điểm chi phí khá cao thì giải pháp này vẫn hạn chế vì cần một thời gian ngắn nhất định để khôi phục khi có sự cố xảy ra.

Để triển khai giải pháp này cần:

Đòi hỏi phải xây dựng một trung tâm dữ liệu dự phòng với các thiết bị tương thích.

Dữ liệu được đồng bộ giữa 2 site bằng đường truyền tốc độ cao.

Khi trung tâm dữ liệu chính bị sự cố, trung tâm dữ liệu dự phòng sẵn sàng thay thế trung tâm dữ liệu chính.

Giải pháp DR toàn diện

Tuỳ theo nhu cầu của quý khách hàng, công ty vdo.vn chúng tôi đảm bảo cung cấp cho khách hàng giải pháp DR toàn diện về mặt dữ liệu cũng như tự động khôi phục hoạt động mà không phải dừng hệ thống trong bất kỳ hoàn cảnh nào.

Trong giải pháp kỹ thuật này chúng tôi xây dựng dự phòng cho hầu hết các thành phần có ảnh hưởng đến hoạt động của quý doanh nghiệp theo tiêu chuẩn DR quốc tế. Tức dự phòng bao gồm cho: dữ liệu, máy chủ, hệ thống mạng, hệ thống an ninh.

Read more

Tìm Hiểu Một Số Giải Pháp Ảo Hóa Domain Controller - Phần Cuối

Trong phần này chúng tôi sẽ tiếp chuyện giới thiệu về vấn đề ảo hóa domain controller bằng cách khảo sát vai trò của máy chủ global catalog bên trong Active Directory. Trong phần cũng sẽ giới thiệu cho các bạn về các cách thực hành tốt nhất được Microsoft khuyến cáo cho việc sắp đặt máy chủ global catalog.

Trong phần trước của loạt bài này, chúng tôi đã giới thiệu cho các bạn một số tùy chọn phân phối các domain controller giữa các máy chủ host trong môi trường ảo. Một trong những vấn đề mà chúng tôi chưa giới thiệu trong phần trước là việc sắp đặt các máy chủ global catalog. Chính vì thế trong phần này chúng tôi sẽ giới thiệu cho các bạn cách xếp đặt các máy chủ này như thế nào trong môi trường ảo hóa.

Máy chủ global catalog là gì?

Phần đông các bạn đang đọc bài này chắc chắn đã biết về khái niệm máy chủ global catalog. Tuy nhiên đối với một số bạn còn mới đối với Active Directory, chúng tôi muốn dành một tí để giải thích về máy chủ global catalog là gì và nó làm những gì. Nếu đã biết khái niệm này, bạn có thể bỏ qua phần này để đọc phần bên dưới.

Có thể dùng cả một loạt bài để nói về vai trò của các máy chủ global catalog, tuy nhiên để không mất tụ hội, chúng tôi sẽ giảng giải một cách đơn giản. Các bạn chỉ cần biết, Active Directory gồm có một hoặc nhiều domain. Mỗi domain này được tạo nên bởi một hoặc nhiều domain controller. Mỗi domain controller lại gồm có một phân vùng domain directory. Mỗi một phân vùng domain directory lại gồm có một bản copy ắt các đối tượng Active Directory (trương mục người dùng, máy tính, nhóm,…) tồn tại bên trong miền.

Do quá trình tạo bản sao Active Directory sẽ đồng bộ các domain controller bên trong một miền, Mỗi một domain controller gồm có một bản copy các đối tượng bên trong miền mà nó phục vụ. Do đó, một domain controller có thể phục vụ các đề nghị cho một miền của nó.

Các mạng lớn thường dùng nhiều Active Directory forest gồm đa miền. Trong các môi trường kiểu như vậy, các máy chủ global catalog sẽ làm nhiệm vụ cung cấp định vị các đối tượng bên trong các domain có trong forest, tuy nhiên nó không cần biết đối tượng tồn tại trong domain nào. Đó là vì các domain controller được thiết kế để làm việc như các máy chủ global catalog có bản sao chỉ đọc (read-only) của mỗi phân vùng domain directory bên trong forest. Các phân vùng này tồn tại bên ngoài phân vùng domain directory cho miền có máy chủ global catalog là thành viên.

Các Domain Forest đơn

Trong phần trước của loạt bài này, chúng tôi đã giới thiệu lược đồ như mô tả trong hình A bên dưới. Sơ đồ này có một domain forest đơn với các domain controller nằm rải rác ở cả các máy vật lý và máy ảo.

Trong một mạng như mạng được viện dẫn ở trên, việc sắp đặt máy chủ global catalog không trở nên vấn đề quá quan yếu. Lý do cho điều này là một domain forest đơn chỉ có một phân vùng domain directory. Mỗi một domain controller đơn trong forest lại gồm có một bản sao của một và chỉ một phân vùng domain directory. Như vậy, mỗi domain controller sẽ được cấu hình để làm việc như một máy chủ global catalog. Cách thực hiện này không được khuyến khích trong một forest đa miền, tuy nhiên bạn có thể tránh cấu hình mỗi domain controller trong một domain forest đơn để làm việc như một máy chủ global catalog vì thực hiện như vậy không tăng hiệu suất dùng CPU hoặc sử dụng đĩa và cũng không tăng lưu lượng tạo bản sao.

Khi nói đến các forest đa miền, việc sắp đặt máy chủ global catalog cần phải được xem xét một cách cẩn thận. Trước khi bắt đầu đàm luận về sự xếp đặt máy chủ global catalog này, bạn cần phải nhận ra rằng dù vai trò máy chủ global catalog được sử dụng ở mức domain controller thì các kiêng kị global catalog sẽ là hoạt động mức forest.

Với lưu ý đó, Microsoft khuyến cáo rằng mỗi site Active Directory được cấp một máy chủ global catalog cho riêng nó. Khuyến cáo này khởi hành từ một số lý do.

Một trong các lý do chính mà bạn cần phải nhớ là sự phụ thuộc của ứng dụng trên các máy chủ global catalog. Một ví dụ hoàn hảo cho sự phụ thuộc này là Exchange Server. Giải pháp hiện thực tốt nhất cho Exchange Server tuyên bố rằng bạn nên có ít ra một máy chủ global catalog trong mỗi site Active Directory có máy chủ mailbox. Khuyến cáo này không có gì đáng kinh ngạc vì nó thuộc về khuyến cáo chung của Microsoft cho việc xếp đặt máy chủ global catalog. Dù rằng vậy, có một số tình huống mà ở đó chúng ta dùng nhiều máy chủ global catalog bên trong một site. Cho thí dụ, các tổ chức với các khai triển Exchange Server cỡ lớn thường đề nghị nhiều máy chủ global catalog. Microsoft khuyến cáo nên có một tỉ lệ 4:1 của máy chủ mailbox đối với máy chủ global catalog bên trong một site. Bởi vậy, nếu một site Active Directory gồm có 8 máy chủ mailbox thì bạn cần tối thiểu là 2 máy chủ global catalog bên trong một site.

Số lượng máy chủ global catalog được đề nghị không phải là thứ duy nhất cần lưu ý khi nói đến các ứng dụng của bạn. Bình thường đề nghị Exchange Server bị bỏ qua là các máy chủ global catalog không thể hàm trên các domain controller chỉ đọc. Trong khi Microsoft tương trợ (và thậm chí trong một số trường hợp còn khuyến cáo) việc chỉ định các domain controller chỉ đọc làm nhiệm vụ như các máy chủ global catalog thì Exchange Server lại không xứng với các domain controller chỉ đọc. Thành ra, hạn chế này không tồn tại với bản thân các domain controller mà đúng hơn là với ứng dụng

Trong một số trường hợp, bạn có thể phát hiện thấy không thực tại khi đặt một máy chủ global catalog bên trong một site Active Directory. Điều này có phần đúng với nhiều site từ xa được tách biệt với văn phòng chính bởi kết nối tốc độ thấp. Trong các tình huống như vậy, lưu lượng tạo bản sao Active Directory được đề nghị để duy trì máy chủ Global Catalog có thể làm bão hòa kết nối WAN của bạn.

Việc đặt một máy chủ global catalog bên trong site Active Directory cũng phi thực tại nếu có ít hơn 100 người dùng trong một site. Dù bạn có thể cung cấp một máy chủ global catalog cho mỗi site như vậy nhưng việc thực hiện đó là quá mức cần thiết trừ khi tồn tại sự phụ thuộc của vận dụng hoặc site phục vụ cho việc roaming người dùng là chính.

Như những gì bạn thấy, có một số cảnh huống mà ở đó việc đặt máy chủ global catalog bên trong site Active Directory có thể không là giải pháp thực tế tốt nhất. Thậm chí người dùng bên trong site đó vẫn có thể giải quyết các đề nghị Active Directory. Tuy nhiên Microsoft đã cung cấp cho chúng ta một phương pháp thay thế, phương pháp này được sử dụng trong các cảnh huống này.

Như những gì được biết, Mỗi một site Active Directory yêu cầu ít nhất một domain controller. Thay cho việc chỉ định domain controller làm máy chủ global catalog, bạn có thể kích hoạt việc lưu trữ hội viên nhóm phổ dụng. Điều này cho phép domain controller trong site có thể nhớ nhóm toàn cục và SIDS của nhóm phổ dụng được đề nghị từ máy chủ global catalog. Mặc dù việc lưu hội viên nhóm phổ dụng giảm đáng kể sự phụ thuộc nhưng vấn đề ở đây là cần phải đảm bảo rằng các site đó đang sử dụng việc lưu hội viên phổ dụng sẽ không tạo bản sao từ máy chủ global catalog.

Kết luận

Trong phần này chúng tôi đã giới thiệu được cho các bạn một số khyến khích có liên quan đến sự sắp đặt máy chủ global catalog. Trong phần tiếp theo của loạt bài, chúng tôi sẽ giới thiệu cho các bạn những kiến trúc đa miền được dùng đối với các trọng tâm dữ liệu, thêm vào đó chúng tôi cũng sẽ giới thiệu sẹ sự sắp đặt máy chủ global catalog trong các trường hợp như vậy.

Read more

Tìm Hiểu Một Số Giải Pháp Ảo Hóa Domain Controller - Phần 3

Dù rằng domain controller dường như là một khái niệm khá đơn giản nhưng việc ảo hóa domain controller thực thụ lại không phải vấn đề đơn giản chút nào. Để tiếp theo hai phần trước của loạt bài này, chúng tôi sẽ giới thiệu cho các bạn về các tùy chọn cho việc ảo hóa domain controller.

Trong phần trước của loạt bài này, chúng tôi đã giới thiệu cho các bạn về một mô hình sắp xếp máy chủ kết hợp giữa các domain controller vật lý và domain controller ảo. Trước khi giới thiệu về những vấn đề mới, tôi muốn quay trở lại một tẹo và miêu tả mô hình domain controller mà chúng ta sẽ nối luận bàn ở đây.

Ý tưởng căn bản nằm phía sau mô hình domain controller mà chúng tôi đang đề cập đến là một mô hình có hai máy chủ vật lý mới được thiết lập làm các domain controller mới. Tất cả các domain controller tồn tại trước đó đều được ảo hóa,

Như những gì chúng tôi đã chỉ ra trong phần trước của loạt bài này, chúng ta hiện đang làm việc dưới sự thừa nhận rằng forest chỉ gồm có một domain. Có nhiều mô hình giống nhau cho nhiều domain forest tuy nhiên chúng tôi sẽ đề cập đến các mô hình đó trong các phần sau. Còn lúc này, chúng ta nên đơn giản hóa mọi thứ để bạn có thể tụ hội vào các khái niệm cơ bản.

Ngoài những gì cần lưu ý trên, còn có một số thứ chúng tôi muốn giới thiệu thêm trong sơ đồ trên. Như những gì các thấy, hình biểu đạt ở trên gồm có hai hàng máy chủ. Hàng trên là các máy chủ vật lý còn hàng dưới là các máy chủ ảo. Có tất cả 6 domain controller được biểu thị trong lược đồ này. Tuy nhiên điều đó không có nghĩa rằng chúng tôi sẽ triển khai 6 domain controller. Các domain controller được biểu hiện trong sơ đồ chỉ mang tính chất đại diện. Số lượng thực tại các domain controller mà bạn cần đến sẽ phụ thuộc vào kích tấc và cấu hình mạng của bạn.

Bạn sẽ thấy rằng mỗi một domain controller đều được kết liên với một miền có tên Contoso.Com và các domain controller đó đều được gán nhãn bằng các số từ 1 đến 6. Các con số này biểu tượng cho thứ tự cho các domain controller khi chúng được bổ sung vào miền. Cho tỉ dụ, vdo.vn biểu lộ đây là domain controller trước hết online. Như vậy domain controller này sẽ hosting các vai trò hoạt động chính và cũng làm việc như một DNS server chính cho forest / domain.

Sơ đồ này cũng cho thấy rằng chúng tôi đã online hai máy chủ vật lý  thành các domain controller trước để ảo hóa bốn domain controller đầu. Cách thức này giúp chúng ta đạt được hai mục đích. Đầu tiên, các domain controller vật lý sẽ cung cấp một mức thăng bằng tải vì các yêu cầu Active Directory lúc này sẽ được phân phối qua 6 domain controller thay vì 4. Điều này có vẻ không gớm ghê lắm, nhưng cần nhớ rằng các máy chủ ảo phải cạnh tranh một lượng tài nguyên nhất thiết nào đó. Nếu các yêu cầu nào đó làm cho cả bốn domain controller trở thành bận rộn thì việc chia sẻ bớt một số luồng công việc sang các domain controller vật lý kiên cố sẽ làm cho các domain controller ảo rỗi rãi hơn. Chỉ có một cách để chắc chắn điều này là dùng một số công cụ rà hiệu suất.

Một điều quan trọng hơn nữa là việc bổ sung thêm hai domain controller vật lý sẽ giúp khắc phục hiện tượng lỗi host server. Cho thí dụ, giả thử VM-Host1.Contoso.Com bị lỗi, lỗi này làm cho DC1.Contoso.Com và DC2.Contoso.Com cũng bị rớt mạng. Trong khi đó DC1.Contoso.Com lại đang đóng vai trò một DNS server chính cho mạng. Do Active Directory hoàn toàn phụ thuộc vào DNS nên một lỗi như vậy có thể làm vỡ vạc tuốt luốt mạng. Đó là lý do tại sao chúng tôi cấu hình một máy chủ vật lý làm DNS server thứ cấp. Lúc này nếu host server chứa DNS server chính bị lỗi thì DNS server thứ hai vẫn có thể tiếp quản công việc và như vậy khắc phục được tình trạng sập vơ mạng.

Đây là chủ đề đang đề cập đến việc sếp đặt domain controller nên cũng cần nói thêm rằng các domain controller ảo cần đặt tản mác bên cạnh các host. Sơ đồ ở trên là một tỉ dụ, chúng tôi có bốn domain controller ảo và chúng cư trú trên hai host tách biệt nhau. Mặc dầu một host server mới hiện thời có thể hosting cho bốn domain controller nhưng chúng ta không nên làm như vậy là vì, việc đặt tất thảy domain controller ảo vào một host nào đó sẽ vô tình biến host server này thành một điểm lỗi toàn cục. Nếu host server gặp sự cố, nó sẽ kéo theo cả bốn domain controller ảo vỡ vạc theo nó.

Ngoại giả, chúng tôi cũng đã nhấn mạnh tầm quan trọng của việc trải rộng các domain controller ra nhiều host vì vấn đề trọng tải, một host bị quá tải cũng có thể trở nên một lỗi toàn cục. Như vậy đó là thứ chúng ta cần tránh không để xảy ra, lỗi toàn cục.

Thậm chí ngay cho dù có một mạng đơn giản giống như trên thì bạn cũng nên để ý đến việc phân phối các domain controller của mình cho nhiều host. Để thấy được lý do, bạn có thể mường tượng rằng VM-Host1.Contoso.Com đang hosting cả bốn domain controller ảo và VM-Host2.Contoso.Com không tồn tại. Cho rằng VM-Host1.Contoso.Com đang gặp phải một lỗi thảm.

Trong tình huống này, mạng sẽ vẫn hoạt động. Hai domain controller còn lại có thể phục vụ các đề nghị Active Directory và DNS, và chúng có thể được chỉ định vai trò hoạt động chủ nếu cần. Vậy cái lợi trong việc trải rộng các domain controller ảo ở đây là gì? Trong tình huống chúng tôi đã biểu lộ, hai domain controller vật lý còn lại sẽ xử lý luồng công việc mà trước đó được san sớt qua 6 domain controller. Rất có thể hiệu suất sẽ suy giảm nghiêm trọng và bạn vững chắc sẽ gặp vấn đề nếu một trong hai domain controller vật lý còn lại gặp sự cố. Trái lại, nếu bạn cấu trúc sắp xếp các domain controller theo cách được biểu hiện trong hình A thì lỗi sẽ không bao giờ làm mất đi của bạn hơn hai domain controller.

Ở trên chúng tôi đã giảng giải lý do vì sao chúng ta nên thiết kế một mạng theo cách trình bày trong hình A. Tuy nhiên có một lý do nữa, lý do rút cuộc, mà chúng tôi muốn nói đến trong phần này. Nếu quan sát lại hình trên, bạn sẽ thấy rằng cả hai host server (VM-Host1,Contoso.Com và VM-Host2.Contoso.Com) đều là các thành viên miền. Điều này cho phép các host server có thể truy cập vào cùng thông tin Active Directory như các máy chủ khác trong mạng, điều này giúp cho việc quản lý mạng dễ dàng hơn.

Kết luận

Trong phần này, chúng tôi đã giới thiệu kỹ cho các bạn tầm quan yếu của các domain controller vật lý, bên cạnh đó là việc phân phối các domain controller ảo ra nhiều host server. Trong phần tiếp theo của loạt bài, chúng tôi sẽ giới thiệu giao hội cách sắp đặt máy chủ global catalog vào trong thiết kế này.

Read more

Tìm Hiểu Một Số Giải Pháp Ảo Hóa Domain Controller - Phần 2

Trong phần hai của  bài này, chúng tôi sẽ tiếp tục giới thiệu cho các bạn một số tùy chọn cho việc ảo hóa domain controller.

Mặc dù có một số nhược điểm trong việc đặt các host ảo của bạn vào một forest chuyên dùng. Như chúng tôi đã ám chỉ trong phần trước, một trong những bất thuận lợi lớn là yêu cầu của cơ sở hạ tầng. Nói theo cách khác, một forest chuyên dụng sẽ yêu cầu các domain controller riêng, DNS server riêng và nó cũng thể yêu cầu các kiểu máy chủ cơ sở hạ tầng khác chẳng hạn như các máy chủ quản lý bản vá, quản lý antivirus hoặc backup.

Một bất thuận lợi nữa trong việc tạo một forest chuyên dụng cho các host ảo là sự mất kết nối giữa forest ảo và forest sản xuất. Phụ thuộc vào cấu hình mạng của bạn, sự mất kết nối này có thể ngăn chặn việc chia sẻ các thông tin Active Directory giữa hai forest. Điều này có thể khó giải quyết nếu bạn đang sử dụng giải pháp backup phụ thuộc vào Active Directory và muốn backup các máy chủ từ cả hai forest.

Ở phần cuối của phần một chúng tôi đã đề cập đến khả năng tạo một Active Directory forest hoàn toàn độc lập để quản lý các host ảo của bạn. Ưu điểm của phương pháp này là cho phép bạn ảo hóa tất cả các domain controller sản xuất của mình trong khi đó vẫn có thể sử dụng các công cụ quản lý phụ thuộc Active Directory.

Thậm chí ngay cả khi bạn không quan tâm đến sự cách ly Active Directory gây ra bởi việc sử dụng nhiều forest thì yêu cầu về cơ sở hạ tầng liên quan trong việc tạo một forest hoàn toàn độc lập cho các host ảo hóa có thể sẽ làm bạn phân vân rằng liệu sử dụng phương pháp này có đáng với nỗ lực của mình. Quả thực không có chiến lược nào cho việc ảo hóa và tổ chức các domain controller là hoàn hảo. Tuy nhiên vẫn có một số thứ để bạn có thể làm cho phương pháp này trở nên lôi cuốn hơn đôi chút.

Một phương pháp mà bạn có thể sử dụng ở đây là cấu hình hai máy chủ vật lý làm việc như các domain controller cho miền sản xuất. Sau đó có thể cấu hình một trong hai domain controller vật lý làm việc như một DNS server tích hợp Active Directory.

Khi hoàn tất cấu hình này, bạn có thể join các máy chủ host của mình vào miền sản xuất mà không cần phải lo lắng về nghịch biện “trứng có trước hay gà có trước”. Bạn có thể thực hiện ảo hóa một cách an toàn tất cả các domain controller của mình, ngoại trừ hai domain controller mà vừa thiết lập. Rõ ràng trong cách thực hiện này, chúng ta đã thừa nhận rằng forest đang được đề cập đến chỉ gồm có một miền. Trong các phần sau của loạt bài này, chúng tôi sẽ đề cập đến các chế độ ảo hóa đa miền, còn lúc này đây chúng tôi chỉ muốn đơn giản hóa mọi thứ bằng cách sử dụng một domain forest.

Nhân tố cơ bản nằm bên dưới việc sử dụng phương pháp này là nó bảo vệ bạn tránh được các lỗi máy chủ host (tối thiểu cũng được vài mức). Chúng ta giả sử rằng hai domain controller vật lý không tồn tại và rằng bạn đã ảo hóa tất cả các domain controller khác của mình. Phụ thuộc vào cách cấu hình các domain controller này, bạn có thể gặp tình huống mà ở đó lỗi của máy chủ host sẽ làm cho các domain controller ảo hóa của bạn trở thành không thể truy cập, do đó nó sẽ ngăn chặn việc đăng nhập vào mạng. Có hai domain controller vật lý riêng sẽ bảo đảm việc người dùng có thể đăng nhập vào mạng thậm chí khi toàn bộ cơ sở hạ tầng ảo hóa thất bại.

Rõ ràng việc đơn giản hóa ở con số hai domain controller vật lý là không đủ. Như những gì bạn có thể xem lại, chúng tôi đã đề cập rằng, một trong số hai máy chủ này cần được cấu hình làm DNS server. Cho đến đây chúng ta vẫn chưa cấu hình bất cứ máy nào trên mạng của mình để sử dụng nó như vậy. Lời khuyên ở đây là thiết lập máy chủ này làm DNS server thứ hai. Theo cách đó, các host trên mạng của bạn sẽ vẫn có thể sử dụng DNS server chính. Trong trường hợp DNS server chính của bạn hoặc các host mà nó cư trú trên bị lỗi thì DNS server vật lý vẫn có thể xử lý các truy vấn DNS trong mạng cho tới khi tình huống được khắc phục.

Một vấn đề khác mà bạn cần phải xét xem liệu có nên đi theo phương pháp này hay không nằm ở các role Flexible Single Master Operation. Windows 2000 Server và các phiên bản gần đây sử dụng chế độ tạo bản sao multi master, trong đó các nâng cấp cho cơ sở dữ liệu Active Directory có thể được ghi đè vào bất cứ domain controller có sẵn nào. Mặc dù vậy, một số domain controller được xem như quan trọng hơn một số domain controller khác. Các domain controller được gán cho các role Flexible Single Master Operation sẽ chịu trách nhiệm duy trì tính niêm trực của Active Directory. Cho ví dụ, domain controller đang nắm giữ Schema Master sẽ có trách nhiệm duy trì giản đồ Active Directory. Tất cả những sự thay đổi của giản đồ sẽ được ghi đè vào domain controller này.

Như những gì bạn biết, có hai kiểu role Flexible Single Master Operation; domain level role và forest level role. Khi bạn tạo một Active Directory forest, domain controller đầu tiên mà bạn thiết lập sẽ tự động được gán tất cả các role ở mức forest (forest level role) và tất cả các role mức miền (domain level role) cho miền mà bạn đã tạo. Nếu bạn tạo các miền bổ sung bên trong forest thì domain controller đầu tiên trong mỗi miền sẽ được gán các role mức miền cho miền đó.

Chúng tôi sẽ không biến bài viết này thành một thảo luận chuyên sâu về các Flexible Single Master Operations role và các chức năng của chúng mà chỉ đề cập đến sự thay thế role Flexible Single Master Operation bên trong môi trường ảo hóa.

Với lưu ý đó chúng ta hãy quay lại chế độ ảo hóa của mình với hai domain controller vật lý và tất cả các domain controller đã được ảo hóa. Chúng ta hãy tiếp tục giả định rằng chế độ này được áp dụng cho một forest chỉ gồm có một miền đơn.

Vì tất cả các domain controller đang tồn tại đều đã được ảo hóa, điều đó cũng có nghĩa rằng tất cả các flexible single master operation role đều đang được cấu hình trên domain controller ảo. Do Active Directory không thể thực hiện lâu mà không cần truy cập vào domain controller, nơi các role được gán nên chúng ta cần phải quan tâm đến có nên hay không ảo hóa domain controller này.

Theo quan điểm của chúng tôi, sẽ không có gì bất lợi trong việc ảo hóa domain controller đang giữ các flexible single master operations role. Tuy các máy chủ host có thể lỗi, làm cho domain controller lỗi theo với nó, nhưng các máy chủ vật lý cũng có thể bị lỗi như vậy.

Lý do tại sao chúng ta tin ảo hóa domain controller gồm các Flexible Single Master Operations role an toàn là vì lỗi xảy ra với domain controller này sẽ không thê thảm (giả định rằng có một số domain controller khác trên mạng). Miễn là một số domain controller và một DNS server còn trên mạng của bạn thì Active Directory sẽ tiếp tục hoạt động bình thường trong một thời gian.

Nếu lỗi xuất hiện cho thấy rằng dường như việc khôi phục là không thể thì bạn có thể bỏ các role flexible single master operations ra khỏi domain controller bị lỗi và bổ nhiệm các role vào domain controller đang làm việc. Khả năng này sẽ an toàn hơn nếu ảo hóa các domain controller thậm chí nếu chúng có các flexible single master operations role.

Kết luận

Trong phần này, chúng tôi đã giới thiệu được cho các bạn một số ưu điểm trong việc sử dụng máy chủ vật lý để thực hiện nhiệm vụ như các domain controller, trong bài cũng đề cập đến sự an toàn trong việc sử dụng các domain controller đã được gán flexible single master operations role. Trong phần ba của loạt bài này, chúng tôi sẽ tiếp tục giới thiệu thêm về chế độ thay thế domain controller và sự thay thế máy chủ global catalog.

Read more