잊지 않겠습니다.

TMAX Windows

시끌벅적 2009. 7. 8. 01:38
예비군 훈련중에도 너무 궁금해서 친구에게 문자로 생중계를 부탁해서 현장 분위기를 계속해서 듣고 있었다. 
듣다가 너무나 황당해서.. -_-

개인적으로는 정말 경멸하는 회사가 TMAX이다. 
이 회사는 사람을 사람으로 보지를 않는다. 사람을 부품보다 못한 존재로 만들어버린다.
당당하게.. 이거 개발하다가 개발자중에서 두명이 이혼했어요. 여자친구랑 깨졌어요. 를 이야기하는 정신나간 기업인이 어디에 있는지 모르겠다. 아니.. 솔찍히 그 생각이 우리나라 기업인들의 마인드라면.. 우리나라는 이제 망한거다. 

자신의 회사의 구성원들의 사생활과 개인생활을 망가트리고나서 그게 자랑스럽다고 이야기하는 그 어투란..
증오스럽다. 

황우석때와 마찬가지로 월화수목금금금을 외치는 기업. 
취업되고 나면 친구 및 가족들하고 연락이 단절되는 기업.
모든 단가를 반으로 후려쳐버려서 우리나라 IT의 정당한 가격도 받지 못하게 해버린 기업.
배낀 프레임워크가지고 자신의 기술이라고 떠들어대고 있는 기업. 

소송에서도 밀렸고, 이번 TMAX Windows의 경우에도 Open Source 부분의 많은 저작권을 위반하고 있는 것이 눈에 보이고. 정말 반성과 자성이 조금은 필요한 기업이라고 생각된다. 하는 짓을 보면 지금 2MB랑 너무나 잘 어울려서 탈이지만. 

아. 그리고 TMAX Windows의 첫 고객이 2MB가 될거라고 하던데. 2MB는 일단 로그인을 못해요. 


저작자표시 비영리 변경금지 (새창열림)
Posted by Y2K
,

.NET을 이용한 Powershell Script 제어

.NET Framework 2009. 7. 6. 17:34
.NET 객체를 이용하는 PowerShell의 object들은 모두다 이용가능하지만, Powershell은 결정적으로 자신만의 .NET 객체를 만들지 못하는 단점을 가지고 있다.

그렇지만, 시스템 관리 및 MS에서 제공되는 대부분의 (SCVMM, Exchange, MS-SQL) 제품들은 Powershell에서 사용할 수 있는 방법 및 cmdlet을 제공하고 있고, 이를 이용하면 불편하게 시스템을 바닥까지 긁어가면서 개발을 하지 않아도 된다.

그리고, .NET 객체로 PowerShell을 이용해서 개발을 할 수 있는 방법을 역시 MS가 제공하고 있기 때문에.. PowerShell만 조금 알고, 약간의 개발을 한다면 손쉽게 PowerShell을 이용해서 시스템을 제어하는 프로그램을 만들어줄 수 도 있다.

PowerShell을 이용한 개발을 하기 위해서는 다음과 같은 절차가 이루어져야지 된다.

1. PowerShell Runspace를 정해준다.
2. 실행될 Script가 동작될 Pipeline을 만들어준다.
3. Command 생성
4. Pipeline을 통해서 Script를 invoke 시켜준다.


1. Runspace 생성
Runspace는 자신의 application이 동작할 system pool과 동일한 개념이다.
먼저 RunspaceConfiguration을 만들어준 후, 그 Configuration을 이용해서 Runspace를 만들어준다.

2. Pipeline 생성
Pipeline은 Powershell을 사용하면 쉽게 알 수 있는 하나의 cmdlet이 실행될 때, 그에 대한 output의 연결 통로이다. 예를 들어, 아래와 같은 script가 실행이 되었을때,
get-service에서 얻어지는 모든 객체를 ForEach-Object 구문으로 전달하게 되는 것이 get-service 명령어가 종료된 이후에 pipeline을 통해서 전달되게 된다. Pipeline의 생성 구문은 다음과 같다. IDispose Interface를 상속받고 있기 때문에 using을 사용하는 것이 code가 깔끔해진다.

3. Command 생성
이제 판을 벌인 상태이고, 여기에서 굿을 보던 떡을 팔던 할 차례이다. cmdlet을 Command로 만들어주고, 그 cmdlet의 parameter를 각각 넣어주면 된다. 여기에서 재미있는 점중 하나가.. 일반적으로 get-service "SMS" 라고 넣어주면 되었던 것들이 get-service -name "SMS" 라는 식으로 full name으로 들어가져야지 된다는 것이다. Name이 없이 넣는 방법은 못찾겠다. ;;

재미있는 것이 pipeline에 여러 command를 넣는 것이 가능하다는 것이다. 여러 command를 넣어서 여러 작업을 동시에 automation을 시킬때 편리할 듯 싶다.

4. Pipeline Invoke
Invoke를 통해서 실행을 하고 그 return 값을 받는데.. 이 받는 과정이 조금 재미있다. PowerShell은 .NET 을 이용한다. 따라서, 이 Invoke의 Return값도 .NET 객체 또는 Wmi Script의 결과가 나오게 되는데. .NET만이 나온다면 System.Object를 사용하면 될 것 같은데.. WMI Object 역시 지원하고 있기 때문에 PSObject라는 약간 생뚱 맞은 Object가 튀어나오게 된다. PSObject에서 ImmediateObject Property를 이용해서 .NET Object로 casting을 해줘서 .NET에서 사용해줘도 되고, 그냥 일반적으로 PSObject.ToString()을 호출해주면 PowerShell에서 나오는 결과와 동일한 결과를 나타나게된다.

casting을 시켜줄때가 가장 문제인것 같은데.;;


저작자표시 비영리 변경금지 (새창열림)
Posted by Y2K
,

LVS 방법에 따른 제약사항 정리

OS 자료들 2009. 7. 3. 13:53
LVS를 이용해서 Load Balancer를 구성할때 Direct Routing, NAT, Tunneling 방식으로 3가지 방식으로 사용될 수 있는데, 각 3가지 방법은 다음과 같은 차이를 가지고 있다.

1. Direct Routing
LVS에 VIP를 설정, VIP를 통해서 Node단에 Network Load 전송

* LVS
- eth0 에 자신의 private ip가 eth0:1에 VIP가 설정되는 식으로 VIP와 private ip를 모두 갖는다.
* Node
- loopback devicde(lo)에 LVS의 VIP가 설정되어야지 된다.
: IP Diagram에 자신이 처리해야지 되는 연결임을 알 수 있도록 설정되어야지 된다.

2. NAT
- 조금 특이한 형태. Input/output이 모두 LVS를 통해서 나가게 된다.
- 20대 이상의 대규모 네트워크에 매우 불리하다.

* LVS
- 반드시 2개 이상의 network adapter가 필요하다.
- 1개는 public ip로 연결, 나머지 1개는 private ip로 연결된다.
* Node
- private ip가 반드시 있어야지 된다. (public ip는 필요 없다.)
- private ip의 gateway에 LVS의 private ip가 설정된다.
: Network input/output이 모두 NAT를 통해서 나가게 되기 때문에 gateway를 모두 같이 맞춰줄 필요가 있다.
: IP class에 따라 제한이 될 수 있다.

3. Tunneling
- IP Diagram 변경을 통해 Network Load가 전송된다.

* LVS
- 특별하게 지정해줄 필요 없다. ipvsadm 명령어 옵션만 다를 뿐이다.
* Node
- tunl0 라는 network 가상 device를 추가해주고, LVS의 private ip로 연결되어야지 된다.
: LVS와 node간의 연결 통로를 미리 지정해주게 된다. 그리고, 이 곳에서 온 자신에 대한 네트워크 연결은 Tunneling으로 온 것으로 판단하고, 들어온 입력이 아닌, ip diagram에 있는 정보를 이용해서 return 시켜주게 된다.


결론
네트워크 시스템을 어떻게 구성할지를 고민해야지 될듯. 모든 Network에 대한 감시가 필요하고, LVS를 좋은 녀석으로 구성한다면 NAT가 가장 최선의 방법이 될 수도 있지만, 이는 LVS 에 엄청난 부하를 줄 수 있기 때문에 가장 많이 사용되는 것은 Direct Routing 방법. 그렇지만, Node에 따로 설정을 해줘야지 된다는 것은 부담으로 남는다.


저작자표시 비영리 변경금지 (새창열림)
Posted by Y2K
,

티스토리툴바