LAN 및 Wi-Fi를 통한 부하 분산


8

Mac OS X 10.6 또는 Ubuntu 9.10 또는 Windows XP (Multiboot)를 실행하는 Mac이 있습니다. 어떤 시스템이든 더 나은 솔루션이 될 수 있습니다.

나는이 두 가지의 ISP를 하나를 통해 액세스 할 수 있습니다, 와이파이 하나를 통해 액세스 할 수 있습니다, LAN . Mac OS XI에서는 우선 순위를 정의 할 수 있습니다. 그러나 내가하고 싶은 것은 두 네트워크와의 부하 분산 입니다.

추가 하드웨어를 사고 싶지 않습니다. 도움이된다면 사용하지 않는 Wi-Fi 라우터가 있습니다.

Linux에서 프로그램을 컴파일하고 구성하는 것은 문제가되지 않습니다.

비슷한 질문 : 여러 게이트웨이로로드 밸런싱


2
제안 된 솔루션에 인터페이스를 통한 연결 유지 규칙이 있는지 확인하고 싶을 것입니다. ISP간에 연결이 반송되면 다른 쪽 서버가 혼동 될 수 있습니다. 예를 들어, 다른 IP 주소에서 연결하면 Yahoo IM이 연결을 끊는다는 것을 알고 있습니다.
더그 해리스

서로 다른 2 개의 WIFI 라우터의 신호를 흡수하고 LAN 연결을 통해 컴퓨터에 공급하려면 일종의 Wireless Multi-WAN 리피터가 필요합니다.
djangofan 2016 년

LISP (Locator / Identifier Separation Protocol)는 해결책이 될 수 있지만 이것은 너무 복잡합니다. ;-)
Synox

무엇을로드 밸런싱하고 싶습니까?
David Schwartz

큰 파일 다운로드, 비디오 스트림, YouTube 등
Synox

답변:


1

리눅스에서 가장 가까운 주제는 경로에 대한 '메트릭'설정입니다. 높은 숫자보다 낮은 숫자가 선호됩니다. 두 경로에 동일한 측정 항목을 제공하면 동일한 확률로 선택 될 것으로 생각됩니다.

나는 당신이 달성하려고하는 기술을 multihoming 이라고 생각합니다 . 나는 그것에 대한 직접적인 경험이 없습니다. 그러나 명심해야 할 몇 가지 사항이 있습니다.

  • 기본적으로 하나의 기본 경로로 끝날 것이라고 생각합니다. 즉, 모든 발신 트래픽은 기본적으로 하나의 인터페이스를 선호합니다. 기본 경로가 여러 개 있거나 시간이 지남에 따라 해당 경로를 동적으로 변경해야합니다.
  • 개별 수신 (TCP) 연결의 수명을 위해서는 연결과 동일한 인터페이스를 유지해야합니다. 내 생각에

어쨌든, 그것들은 내가 지금 생각할 수있는 모든 포인터입니다.


metricWindows 및 OS X의 네트워크 인터페이스에 대한 매개 변수입니다. 여러 네트워크 인터페이스를 지원하는 모든 OS에는 우선 순위를 설정하는 수단이 필요합니다.
apraetor

1

라우팅 테이블에 두 개의 인터넷 연결을 모두 동일한 메트릭으로 설치하는 라우팅 메트릭 시스템을 사용할 수 있습니다. 그런 다음 운영 체제는이 두 경로를 동일하게 사용하여 두 링크에서 아웃 바운드 트래픽을 효과적으로 분할해야합니다.

요청에 대한 응답으로 들어오는 트래픽도 요청이 발생한 인터페이스 (공용 IP)로 돌아갈 수 있도록 균형을 유지해야합니다.

문제는 세션 지속성입니다. 예를 들어 링크 중 하나를 통해 웹 사이트를 볼 수 있지만 다음 페이지보기가 다른 인터페이스에서로드 밸런싱되면 소스 IP 주소가 지속적으로 변경되므로 일부 응용 프로그램이 혼동 될 수 있습니다.

따라서 응용 프로그램, 대상 또는 프로토콜에 따라 동일한 비용 경로를 사용하지 않고 트래픽의 일부만 다른 인터페이스로 분할 할 수 있습니다. 교통 경로를 일관되게 유지하는 것입니다.


1

Connectify Dispatch 에는 필요한 작업을 수행 할 수있는 솔루션이 있습니다. 현재는 Windows 만 해당하지만 사람들은 OS X에서 소프트웨어를 가상화 하고 사용하는 데 성공 했습니다.

Windows XP를 이미 실행하고 있었기 때문에 그 부분을 스스로 알아낼 수 있다고 생각했습니다.


이것의 가장 큰 문제는 Windows가 여러 개의 NIC를 쉽게 지원한다는 것입니다. 반면 OS X에서는 구현하기가 쉽지 않습니다.


0

해결 방법은 다음과 같습니다. 내 응용 프로그램이로드 밸런싱을 수행 할 수 있으며 2 개의 연결을 정의한 다음 두 연결을 모두 사용할 수 있습니다.

그런 다음 서버 IP 중 하나를 IPS 중 하나로 라우팅합니다.

Mac OS 10.6 :

경로 추가 -host XXX.XXX.XXX.XXX 192.168.1.1

나는 이것이 매우 구체적이며 server-ip가 항상 같은 경우에만 작동한다는 것을 알고 있습니다. 그리고 애플리케이션이 어떤 식 으로든로드 밸런싱 할 수 있다면.


0

나가는 모든 트래픽이 하나의 ISP이고 들어오는 트래픽이 다른 ISP와 같은 것을 수행하지 않으면 이것이 가능할 것이라고 생각하지 않습니다.

이유는 두 트래픽을 두 개의 개별 네트워크로 나누는 것이 다시 되 돌리는 것처럼 보이지는 않습니다. 하나의 ISP에서 2 개의 파이프가있는 경우 가능할 수 있습니다.

앞서 말한 것처럼 어쨌든 기본값이 필요하고 한 경로를 통해 특정 트래픽을 차단하고 다른 경로를 통해 나머지 트래픽을 억제 할 수 있다고 생각합니다. LAN 에서처럼로드 밸런싱이 여기에서 작동한다고 생각하지 마십시오.

예 : 192.168.2. *를 사용하여 업데이트 실행 * Wi-Fi ISP는 192.168.1. * LAN ISP를 사용하여 반감기를 실행합니다.



0

나는이 같은 질문을 수십 번 다른 방법으로 들었습니다. 먼저 내부 세션과 외부 세션이 비슷하게 처리되지만 동일하지는 않습니다. 모든 내부 세션마다 여러 개의 외부 세션이있을 수 있으며 그 반대도 마찬가지입니다. 당신이 말하는 것은 논리적으로 불가능하지는 않지만 약간의 프로그래밍과 준비가 필요합니다. 일부 장치는 내부적으로 네트워크에서 더 빠른 네트워크 속도를 위해 이더넷 연결 또는 Wi-Fi를 집계 할 수있는 기능으로 구축되고 있지만 외부 네트워킹의 경우 FAILOVER가있는 장치 만 찾았습니다. 즉, 필요할 때만 전환 할 수 있습니다. 그러나 각 EXTERNAL 세션에 대해 다른 게이트웨이를 통해 트래픽을 리디렉션하는 연결 프로토콜에서 기본 스위칭 (0 또는 1을 가진 if 문)을 사용할 수 있습니다. 그런 다음 sessionID를 사용하여 서브 세션을 기본 세션 내에 랩핑하여 각 내부 세션에 연결된 각 외부 세션을 추적해야합니다. 그런 다음 사이트 도메인을 확인하거나 sessionID를 사용하여 내부 라우팅을 완료 할 수있는 방법이 필요합니다 (즉, 각 외부 세션 / 연결마다 클라이언트와 메시지를 구분할 수 있어야합니다. 사이트에서 파이프를 거부하지 않도록 각 사이트의 파이프가 설정되도록 데이터를 요청하거나 데이터를 전송하는 사이트). 즉, 라우터에 새로운 네트워크 프로토콜을 구축하고 연결을 구별하는 방법을 결정해야합니다 (사이트 도메인에서만 수행하는 경우 라우터에서 가능할 수 있지만 클라이언트는 ipaddress의 ipaddress를 사용하려고 시도 할 수 있음) 이를 무효화하는 웹 사이트의 외부 게이트; 양쪽 끝에서 수행되는 경우 클라이언트는 일부 식별자, 일반적으로 이진 마스킹의 숫자 값을 추적해야합니다.이를 통해 전송 수신이 메인 게이트에서 라우팅되는 외부 세션과 일치 할 수 있습니다. 다시 말해, 네트워킹을 처리하기 위해 자체 프로토콜을 프로그래밍해야하며, 직접 구축할지 (클라이언트 및 호스트 프로그래밍을 사용하여) 구축할지 또는 무언가 구축 하려는지를 결정해야합니다. 이는 기존의 기존 프로그래밍과 호환됩니다 (호스트와 클라이언트 간의 메시징에 의해 바인딩되어 호스트에 더 많은 마모가 발생하지만 클라이언트에게는 새로운 것은 아님). 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 클라이언트는 일부 식별자 (일반적으로 이진 마스킹의 숫자 값)를 추적해야하며, 이로 인해 송신 수신자가 메인 게이트에서 라우팅되는 외부 세션과 일치 할 수 있습니다. 다시 말해, 네트워킹을 처리하기 위해 자체 프로토콜을 프로그래밍해야하며, 직접 구축할지 (클라이언트 및 호스트 프로그래밍을 사용하여) 구축할지 또는 무언가 구축 하려는지를 결정해야합니다. 이는 기존의 기존 프로그래밍과 호환됩니다 (호스트와 클라이언트 간의 메시징에 의해 바인딩되어 호스트에 더 많은 마모가 발생하지만 클라이언트에게는 새로운 것은 아님). 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 클라이언트는 일부 식별자 (일반적으로 이진 마스킹의 숫자 값)를 추적해야하며, 이로 인해 송신 수신자가 메인 게이트에서 라우팅되는 외부 세션과 일치 할 수 있습니다. 다시 말해, 네트워킹을 처리하기 위해 자체 프로토콜을 프로그래밍해야하며, 직접 구축할지 (클라이언트 및 호스트 프로그래밍을 사용하여) 구축할지 또는 무언가 구축 하려는지를 결정해야합니다. 이는 기존의 기존 프로그래밍과 호환됩니다 (호스트와 클라이언트 간의 메시징에 의해 바인딩되어 호스트에 더 많은 마모가 발생하지만 클라이언트에게는 새로운 것은 아님). 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 일반적으로 이진 마스킹의 숫자 값으로, 송신 리시버를 메인 게이트에서 라우팅되는 외부 세션과 일치시킬 수 있습니다. 다시 말해, 네트워킹을 처리하기 위해 자체 프로토콜을 프로그래밍해야하며, 직접 구축할지 (클라이언트 및 호스트 프로그래밍을 사용하여) 구축할지 또는 무언가 구축 하려는지를 결정해야합니다. 이는 기존의 기존 프로그래밍과 호환됩니다 (호스트와 클라이언트 간의 메시징에 의해 바인딩되어 호스트에 더 많은 마모가 발생하지만 클라이언트에게는 새로운 것은 아님). 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 일반적으로 이진 마스킹의 숫자 값으로, 송신 리시버를 메인 게이트에서 라우팅되는 외부 세션과 일치시킬 수 있습니다. 다시 말해, 네트워킹을 처리하기 위해 자체 프로토콜을 프로그래밍해야하며, 직접 구축할지 (클라이언트 및 호스트 프로그래밍을 사용하여) 구축할지 또는 무언가 구축 하려는지를 결정해야합니다. 이는 기존의 기존 프로그래밍과 호환됩니다 (호스트와 클라이언트 간의 메시징에 의해 바인딩되어 호스트에 더 많은 마모가 발생하지만 클라이언트에게는 새로운 것은 아님). 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 전송 게이트를 메인 게이트에서 라우팅되는 외부 세션과 일치시킬 수 있습니다. 다시 말해, 네트워킹을 처리하기 위해 자체 프로토콜을 프로그래밍해야하며, 직접 구축할지 (클라이언트 및 호스트 프로그래밍을 사용하여) 구축할지 또는 무언가 구축 하려는지를 결정해야합니다. 이는 기존의 기존 프로그래밍과 호환됩니다 (호스트와 클라이언트 간의 메시징에 의해 바인딩되어 호스트에 더 많은 마모가 발생하지만 클라이언트에게는 새로운 것은 아님). 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 전송 게이트를 메인 게이트에서 라우팅되는 외부 세션과 일치시킬 수 있습니다. 다시 말해, 네트워킹을 처리하기 위해 자체 프로토콜을 프로그래밍해야하며, 직접 구축할지 (클라이언트 및 호스트 프로그래밍을 사용하여) 구축할지 또는 무언가 구축 하려는지를 결정해야합니다. 이는 기존의 기존 프로그래밍과 호환됩니다 (호스트와 클라이언트 간의 메시징에 의해 바인딩되어 호스트에 더 많은 마모가 발생하지만 클라이언트에게는 새로운 것은 아님). 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 클라이언트 또는 호스트 프로그래밍을 모두 사용하여 직접 빌드할지 또는 기존의 기존 프로그래밍과 호환되는 것을 빌드 하려는지 (호스트 간의 메시징으로 바인딩해야 함)를 결정해야합니다 클라이언트는 호스트에 더 많은 마모를 입히지 만 클라이언트에게는 새로운 것은 없습니다. 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 클라이언트 또는 호스트 프로그래밍을 모두 사용하여 직접 빌드할지 또는 기존의 기존 프로그래밍과 호환되는 것을 빌드 하려는지 (호스트 간의 메시징으로 바인딩해야 함)를 결정해야합니다 클라이언트는 호스트에 더 많은 마모를 입히지 만 클라이언트에게는 새로운 것은 없습니다. 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 호스트에 더 많은 마모를 입히지 만 클라이언트에게는 새로운 것은 없습니다. 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다. 호스트에 더 많은 마모를 입히지 만 클라이언트에게는 새로운 것은 없습니다. 유닉스를 알고 있거나 윈 서버 프로그래밍을 알고 있다면,이 작업은 약간의 시간 만에 수행 할 수 있지만 균형을 잡는 각 장치에 더 많은 양의 리소스가 할당되어야합니다.

더 큰 회사 스타일 네트워크의 경우 네트워킹을 메시하고 각 층 또는 부서에 전용 게이트웨이를 제공하여 여러 ISP를 허용하고 그 중 어느 것도 너무 많이 사용하지 않도록 할 수 있습니다. 장애가 발생했을 때 변경 사항을 다른 게이트웨이로 보내거나 다른 게이트웨이로 리디렉션하는 허브가 장애 조치를 처리하도록 할 수도 있습니다. 이것은 약간의 내결함성을 제공합니다.


2
텍스트가 아닌 경우 답변을 더 많이 읽을 수 있습니다. 잠시 시간을내어 단락으로 나누십시오.
fixer1234

나는했다. 그러나 인터페이스는 어쨌든 텍스트 벽으로 게시했습니다.
Htd Tech

참고로, 단일 연결의로드 밸런싱에 대한 대답은 양쪽 끝에서 작업하지 않으면 실제로 실현 가능하지 않다는 것입니다. 그러나 웹 액세스 속도를 높이기 위해 내부 네트워크에 동시에 액세스하는 타사 다중 NIC 카드가 있습니다. isp 서비스가 여러 개인 경우 시스템에서 대역폭 균형을 처리 할 수 ​​있습니다. 양 끝이 패킷 크기를 협상하기 때문에 게임이나 압축되지 않은 비디오에는 실제로 적용 할 수 없지만 업무상 많은 온라인 작업을하는 경우에는 실현 가능하며 성능이 약간 향상됩니다.
Htd Tech

나는 단 하나의 단락 나누기를 발견하고 고쳤다. "비밀"은 단락 사이에 이중 반환 (빈 줄)이 필요하다는 것입니다. 그렇지 않으면 편의상 시스템이 함께 실행됩니다.
fixer1234
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.