Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 2건
  왜 Windows Server 2012 의 Dynamic Team이 대단한가? 
작성일시 : 2014.02.27 22:11 | 분류 : Windows Server/Kernel

기존 Out bound A/A Team 구현 방식의 한계

- 구현 방식은 TCP Port / IP Address / Mac Address Hash 방식이 제공되었습니다 반면 현재의 Dynamic Teaming의 경우 동일한 Port일지라도 Flowlet에 따라 부하 분산이 가능하나 기존의 구현 방식은 Port 수준까지만의 부하 분산만 지원 하였습니다.

왜? TCP Port 수준 밑단까지는 부산 분산을 구현 할 수 없었을까?

- 만약 TCP Stream 상의 패킷들이 동시에 NIC를 통해 외부로 전송된다고 생각해 보자. 이렇게 전달된 패킷들은 실제의 Stream 순서대로 목적지로 전송되지 않을 확률이 큽니다. 일반적으로 이러한 경우을 Out-of-order라고 부르고 있으며 이 경우 목적지에서는 이에 대한 Packet Re-ordering을 진행하게 됩니다. 자 다시 말해 바로 하나의 스트림에 해당하는 데이터가 동시에 Team을 이루고 있는 NIC로 전송됨으로써 당연히 Out-of-order의 발생이 필연적이 되게 되는 이는 수신측의 Re-ordering 연산으로 인한 성능 저하로 이어지게 됩니다.

정말 이런 Re-ordering 이 성능에 영향을 주나요?

- 내 아래 문서를 참조하세요. (http://kb.pert.geant.net/PERTKB/PacketReordering)
In principle, applications that use a transport protocol such as TCP or SCTP don't have to worry about packet reordering, because the transport protocol is responsible for reassembling the byte stream (message stream(s) in the case of SCTP) into the original ordering. However, reordering can have a severe (심각한) performance impact on some implementations of TCP.

그렇다면 동일 TCP Stream는 여러 팀 Member 중 하나만 사용하게 되나요?

- 내 맞습니다. 문제는 TCP Stream을 과연 Team 드라이버가 인식할 수 있냐는 부분입니다. R2의 Dynamic 부하 분산 모드는 동일한 Port를 사용하더라도 TCP Stream이 다른 경우 부하 분산을 제공해 줍니다. 이는 TCP Stream을 이해 할 수 있는 알고리즘인 Flowlet 이 적용되어 있기 때문입니다.

잠깐 Flowlet은 어떻게 구현 되어 있나요?

- 수많은 TEST를 거쳐서 동일 Port를 이용하는 Traffic에 대해서 연속 스트립 여부를 확인할 수 있게 되었습니다. 결론은 시간차이인데요. 동일 스트림일때와 단일 스트림에서 다른 스트림으로 바뀔때는 약간의 시간차가 있습니다. 그리고 그 시간차를 확인하여 동일 스트림이 아닌 경우 다른 NIC 즉 다른 팀 멤버를 사용하도록 디자인 한거죠.

- 실은 자연 과학도 마찮가지지만 관찰과 직관은 꽤 멋진 결과물을 내곤 합니다. 제가 소계해 드리는 Flowlet 알고리즘 역시 그 관찰과 직관의 결과물이죠.
“흔한 예로 IBM 친구들의 최고의 발명품 중 하나인 RISC 프로세서가 있습니다.”

그 외에 다른 장점은 없나요?

- VM에서 외부로 나가는 Traffic 역시도 Dynamic 모드를 통해 Team을 이루고 있는 멤버들 모두를 이용한 부하 분산 모드를 제공하고 있습니다.

PS. 아차… 혹시 이거 쓰는데 네트워크 성능이 더 떨어진다 싶으면 스위치에 라우터 가드 기능을 끄시는게… :) 꼭 궁합이 않맞는 장비가 일부 있는거 같더라구요.

신고
  Windows Server 2012 R2 기반의 VDI 구축시에는 꼭 확인하세요. 
작성일시 : 2014.02.27 21:53 | 분류 : Windows Server/Virtualization

꼭 활성화 해 사용해야 하는 설정 몇 가지

0. 사용하는 RDP 버전에 맞는 RDP Client 모듈을 이용합니다.

1. 먼저 아래의 두 개 정책은 모두 사용하도록 해주세요.

Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host –> Connections
clip_image002

clip_image002[5]

clip_image002[7]

2. 다음 정책은 TEST 진행 후 결과에 따라 설정해 주세요.

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Configure compression for RemoteFX data

clip_image001

3. RDGW에서 UDP 3391이 오픈되어 있는지 꼭 확인 하세요.

clip_image002[9]

4. Windows 7 VM으로 구현 하는 경우 아래 정책 활성화는 필수 입니다.

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment\Enable Remote Desktop Protocol 8.0 또는 8.1

5. 필요에 따라 Windows 7 기반의 VDI의 경우에는 암호화 수준을 조정 할 필요가 있습니다.
아래의 정책을 활성화 하고 암호화 수준을 Low 즉 낮음으로 변경 합니다.
image

주의 : 이 경우 Client에서 보내는 모든 신호는 암호화가 되지만 서버의 경우에는 암호화 하지 않습니다.
다만 아시는 바와 같이 서버에서 보내는 트래픽은 RDP 자체가 압축되어 전송 되기 때문에 패킷을 직접 보더라도 쉽게 내용을 확인하기가 어렵습니다.

6. CRL 체크 Timeout을 1초로 줄입니다.
(절대 권고는 아닙니다.)
(해당 설정은 VM이 아닌 접속하는 Device 레벨에서 진행 하게 됩니다.)

중요 : RDS 인프라가 인터넷이 막혀 있는 경우 RDS 인프라에 해당하는 GW, CB등에도 동일 설정을 해주셔야 합니다.

CRL Check는 인증서 사용할 때 필수 입니다.
하지만 고객에 따라서 때로는 CRL을 확인 할 수 있는 방법을 URL, LDAP, 또는 파일 쉐어로 오픈을 하셔야하는데, 여희치 않는 경우가 있습니다.

이때에는 15초라는 Default Timeout 기간 동일 해당 위치에 대한 접근을 시도하게 되고 이는 초기 접속에 대한 성능 이슈를 야기 합니다. 그렇기 때문에 때대로 이 Timeout 시간을 1초로 조정해 줄 필요가 있습니다.

image

image

또한 필요에 따라 “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot DisableRootAutoUpdate” 의 값을 1 즉 Disable 해야 해 줄 필요가 있는데 이 경우는 VDI에 접속하는 머신이 인터넷이 않될 경우 생각해 보실 수 있습니다.

신고
 Prev   1   Next 

티스토리 툴바