Dữ liệu lớn và SDN - Không phải là không thể tránh khỏi?


Vũ Thiên Duyên
7 năm trước
Hữu ích 7 Chia sẻ Viết bình luận 0
Đã xem 5635
Trong khi hầu hết các cuộc nói chuyện liên quan đến SDN (và OpenFlow) là về việc tách rời các mặt phẳng điều khiển và chuyển tiếp, có một ẩn ý tinh tế sẽ xuất hiện thêm một chút trong các quý tới. Thật tuyệt khi có thể lập trình mọi thứ tập trung, nhưng cần phải thông báo những quyết định đó. Nếu mạng được coi là tài nguyên chứ không phải là tập hợp các thiết bị điểm, thì phải có thông tin về tài nguyên đó để bộ điều khiển SDN có thể đưa ra quyết định đúng đắn.

Nhập phân tích. Hoặc, nếu bạn đưa ra kết luận cục bộ này, nó có khả năng là Dữ liệu lớn.

Mặc dù hầu hết mọi người tập trung vào cách chúng tôi lập trình các yếu tố chuyển tiếp rời rạc trong mạng, nhưng chắc chắn có một câu hỏi hiện ra về cách chúng tôi xử lý các đầu vào bên ngoài để thúc đẩy những thay đổi này. Cụ thể hơn, vai trò của phân tích đóng vai trò gì trong việc xác định những thứ như đường dẫn? Và khi nói đến khắc phục sự cố, nguồn gốc sự thật cho trạng thái mạng là gì khi các quyết định chuyển tiếp được thực hiện tập trung dựa trên các điều kiện mạng không tĩnh hoặc nhất thiết phải gắn với cấu hình có thể được kiểm tra?

Những câu hỏi này vượt ra ngoài cách chúng tôi xây dựng các mạng được xác định bằng phần mềm (hoặc trung tâm dữ liệu) và hiểu thêm về những gì sẽ cần để làm cho các thiết kế này sẵn sàng sản xuất. Có một cái gì đó hoạt động không thay thế cho việc có một cái gì đó có tất cả các công cụ sản xuất và khoa cần thiết.

Vì vậy, điều này có nghĩa là thực tế?

  • Độ chi tiết phù hợp để thu thập dữ liệu là gì? Ngày nay, nhiều công cụ phân tích xem xét dữ liệu và tính trung bình trong một khoảng thời gian. Nếu dữ liệu đó đang thúc đẩy thay đổi thời gian thực trong cơ sở hạ tầng, thời gian nội bộ phù hợp là gì? Nếu nó quá rộng, dữ liệu là vô ích. Quá hẹp và bạn gặp vấn đề dao động trong đó bạn không bao giờ đạt đến trạng thái ổn định.

  • Khi chúng ta di chuyển đến ngày càng nhiều dữ liệu thông báo quyết định, dữ liệu đó có được thu thập và xử lý trong các công việc hàng loạt không? Hay bạn bỏ qua các tính toán cụ thể để được thực hiện theo gia số nhỏ hơn? Nếu tất cả cùng một lúc, bạn phải nghiền nát rất nhiều thứ, nhưng nếu bạn chia mọi thứ thành các nhiệm vụ nhỏ, thì bạn phải sắp xếp các nhiệm vụ đó.

  • Ở mức độ nào chúng ta sẵn sàng tin tưởng máy tính để quản lý trung tâm dữ liệu? Nếu chúng ta chuyển sang một khung tự động cao, vai trò của người vận hành là gì? Hệ thống có đưa ra các đề xuất được xem xét và phê duyệt không? Hay hệ thống đi trước và thay đổi?

  • Chúng tôi giữ bao nhiêu dữ liệu? Và trong bao lâu? Và ở đâu? Nếu mọi thứ đều dựa trên dữ liệu, thì phải giữ bao nhiêu lịch sử để phân tích hoặc xử lý sự cố? Và dữ liệu đó được lưu giữ ở đâu? Các câu trả lời sẽ có tác động sâu sắc đến cách các công cụ hỗ trợ được phát triển. Nếu dữ liệu được phân phối trên các thiết bị cục bộ, thì bất kỳ công cụ phân tích dữ liệu nào cũng cần thu thập dữ liệu, điều này làm tăng thêm độ phức tạp và một số tình huống lỗi thú vị. Một kho lưu trữ trung tâm có các vấn đề thiết kế riêng và các kịch bản thất bại.


Nếu bạn hỏi tôi mọi thứ phát triển như thế nào, tôi nghi ngờ rằng chúng ta sẽ không thấy bất kỳ tiêu chuẩn hóa công nghiệp thực sự nào về câu trả lời cho những câu hỏi này. Một số công cụ và trường hợp sử dụng sẽ ủng hộ một câu trả lời trong khi những công cụ khác sẽ ủng hộ một câu trả lời khác. Nhu cầu thay đổi đáng kể đến mức có nhiều không gian cho các loại công cụ khác nhau. Chỉ riêng trong khu vực cung cấp, chúng tôi biết về Chef, Ansible, Puppet, CFEngine, Salt và những người khác. Khi bạn mở rộng rộng hơn sang các loại công cụ khác, danh sách chỉ phát triển.

Vậy làm thế nào để chúng ta xử lý hàng ngàn tích hợp khác nhau để chúng ta có thể sử dụng tất cả các công cụ này? Tôi nghi ngờ câu trả lời cho câu hỏi đó sẽ là những gì tách biệt các nhà cung cấp ở một mức độ nào đó. Trại thịnh hành cho đến nay dường như ủng hộ các API ở mọi nơi và tích hợp điểm. Đối với các công cụ có giá trị cao (đọc: một khách hàng đã yêu cầu), các nhà cung cấp sẽ tích hợp. Đối với mọi thứ khác, sự tồn tại của API để khách hàng có thể tích hợp dường như là câu trả lời.

Tôi nghĩ rằng phương pháp này hoạt động miễn là tích hợp điểm được áp dụng rộng rãi và khách hàng hài lòng khi thực hiện tích hợp của riêng họ. Nhưng trong một không gian mới nổi, thị trường có nhiều khả năng bị phân chia giữa các công cụ tiềm năng và đối với hầu hết các cửa hàng, mong muốn xử lý các tích hợp nặng nề là không có. Một cách tiếp cận khác nhau sẽ phải bề mặt. Thay vì dựa vào API hệ thống, có thể câu trả lời đúng là về cơ bản là chuẩn bị dữ liệu và trình bày tất cả dữ liệu mạng từ một công cụ dữ liệu. Tất cả các dịch vụ dữ liệu sẽ tích hợp với công cụ này thông qua một cơ sở hạ tầng chung làm cho việc tích hợp ít tùy chỉnh hơn. Tôi sẽ không đi sâu vào đây quá nhiều, nhưng tôi thích cách tiếp cận sau này vì nó đi xa hơn một bước so với việc chỉ nói "Chúng tôi có API cho điều đó."

Bất kể điều gì xảy ra mặc dù, tôi nghĩ rằng giao điểm của Dữ liệu lớn và SDN sẽ xảy ra. Đó chỉ là vấn đề khi nào và ở đâu. Nếu bạn nghĩ rằng một từ viết tắt buzzword là khó khăn, thì việc chỉ nhắc đến hai từ có lẽ khiến bạn không yên tâm. Nhưng tôi sợ điều này là không thể tránh khỏi.

Hữu ích 7 Chia sẻ Viết bình luận 0
Đã xem 5635