100 % 가동 시간을 가진 응용 프로그램 업데이트

Question

지난 인터뷰에서 100 % 가동 시간을 유지해야하고, 매우 반응적이고 업데이트 가능해야하는 업무 핵심 Windows 서비스를 작성하는 방법을 묻습니다. 이 서비스는 요청을 받아 계산을 수행하고 응답을 다시 보내는 원격 응용 프로그램으로 설명되었습니다.

내 솔루션은 단순히 게이트웨이 역할을하는 매우 일반적인 서비스를 갖추는 것이 었습니다. 이 서비스는 결코 중단되지 않습니다. 요청을 대기열에 넣고 요청을 실제로 처리 할 별도의 앱 도메인에있는 다른 서비스로 전달합니다. 이러한 핸들링 서비스 중 적어도 두 가지가 필요할 것이므로 다른 하나가 들어오는 요청에 응답하는 동안 업데이트 될 수 있습니다. 서비스 간의 인터페이스에는 서비스가 실행 중인지 확인하기 위해 핸드 셰이크 기능이 포함됩니다. 매우 작은 시간 제한이 존재하므로 서비스가 완료되면 요청을 보류하지 않습니다. 나는 또한이 솔루션이 다른 상자에 더 많은 서비스를 추가 할 수있는만큼 확장 될 수 있다는 점을 강조했습니다.

면접관은 앱 도메인간에 통신하는 것과 네트워크를 통해 통신하는 것 사이의 대기 시간 문제로 인해이 아이디어에 너무 열중하지 않았습니다. 미션 크리티컬 한 애플리케이션에 대해서는 소프트웨어만으로는 답이 될 수 없으므로 견고한 인프라를 구축해야한다고 말했습니다. 그는 또한 현재 재배착을 사용하는 시스템을 갖추고 있다고 말했다. 어셈블리를 응용 프로그램 도메인에로드하고 어셈블리 변경을위한 디렉토리를 보려고 생각했지만 오류가 발생하기 쉬운 것처럼 보입니다.

비슷한 요구 사항을 가진 사람이 있습니까? 어떤 해결책을 사용 했습니까? 작동하지 않는 것은 무엇입니까? 반영은 유용한 옵션입니까?

Answer 1

.Net은 어셈블리를 사용하는 동안 어셈블리 업데이트를 지원합니다. Shadow Copy이라고하며 효율적으로 어셈블리를로드하기 전에 별도의 디렉터리에 복사합니다. 새 버전을로드하기 전에 여전히 appdomain을 언로드해야하지만 다른 appdomain에서는 이전 버전의 어셈블리를 계속 사용할 수 있습니다. 그렇게하면 새로운 appdomain이로드되는 동안 하나의 appdomain이 요청을 처리 할 수 ​​있습니다. 이것은 IIS와 ASP.Net이 처리하는 방법이기도합니다.

Answer 2

가동 시간 100 %? "파이브 나 인"은 연간 315 초의 다운 타임을 의미합니다. 당신이 그것을 관리 할 수 ​​있다면, 당신은 정말로 잘 할 것입니다.

불가능한 인터뷰 질문처럼 들립니다. "... 100 % 가동 시간을 유지하고 반응이 좋으며 업데이트가 가능합니다 ..."- 가동 시간에 대한 하나의 측정 항목이 주어졌지만 응답성에 대한 측정 항목은 없습니다.

대기 시간은 걱정할 가치가있는 문제이지만, 원격 응용 프로그램이라고 했으므로 멀리 떨어져있을 수 없습니다. 나는 면접관이 자기 자신을 위해서 동의하지 않았을 수도 있고 아마도 당신이 그것을 어떻게 다룰지를보기 위해서일지도 모른다고 생각합니다.

Answer 3

스프링 dm 서버는 OSGi 번들의 핫 전개/전개를 수행 할 수 있다고 주장합니다. 하드웨어가 충분히 길게 유지 될 수 있다면 서버를 다운시키지 않고도 응용 프로그램을 업데이트 할 수 있습니다. 이 문제가 발생하면 모든 Java EE 애플리케이션 서버의 표준 기능이됩니다.

Answer 4

100 % 가동 시간 같은 것은 없습니다. 최고의 시스템조차도 가동 중단 시간을 99.999 %의 가동 시간을 의미하는 "5 nines"로 측정합니다.

또한 중요한 점은이 측정 값이 예기치 않은 다운 타임과 마찬가지로 실패로 적용됩니다. 정기 유지 보수를 위해 시스템을 가동하지 않은 시간은 포함되지 않습니다.

어쨌든 목표는 예정된 시간이나 다른 방법으로 다운 타임을 발생시키지 않고 소프트웨어를 설치/업데이트하는 것입니다.웹 서버가 기본적으로 동적 재로드를 지원하지 않는다면 솔루션이 올바르지 만 요즘은 많은 서버에 내장되어 있다고 생각합니다. 즉, 새 파일을 서버에 놓기 만하면 자동으로 무언가가 변경된 것을보고 사용을 시작합니다.

그러나 세션 상태에 문제를 일으킬 수있는 변경의 특성에 따라 다릅니다. 즉, 기존 사용자 세션은 새 코드와 호환되지 않는 세션에 저장된 객체로 끝날 수 있습니다. 다시 말하지만, 아마도 서버는 이전 코드를 사용하는 모든 세션이 종료 될 때까지 원본 코드의 캐시 된 사본을 보관할만큼 똑똑 할 수도 있지만 어쩌면 직접 처리해야 할 수도 있습니다. 귀하의 "섀도 서버"접근 방식을 잘 처리해야합니다.

Answer 5

우리는 플랫폼이 절대 가동 시간을 필요로하는 Wireless Telecom에서 근무하고 있으며, 모든 다른 전략을 보았을 때 소프트웨어 기반의 접근법을 사용해서는 안되며 소프트웨어 복잡성이 추가됩니다. 하드웨어를 추가하는 것입니다.

히트가없는 업그레이드를 요청 했으므로 중복 시스템이 있어야하며 서버 응용 프로그램을 중복시키는 가장 좋은 방법은 하드웨어 부하 분산 장치를 사용하는 것입니다. 직장에서 우리는 파운드리를 보유하고 있으며 새로운 모든 것들은 Cisco Ace로드 밸런서로 가고 있습니다.

두 대의 시스코로드 밸런서가 필요합니다.로드 밸런서 간의 페일 오버를 위해 이들 사이에 HSRP를 설정하십시오. 장애 조치 설정에서는 매우 공격적 일 수 있지만 경험상 너무 공격적이어서 불필요한 장애 조치가 발생할 수 있습니다. 또한 proxy-arp를 해제하십시오 (시스코에 기본적으로 설정되어 있으므로 걱정하지 않아도됩니다).

이제 응용 프로그램 서버 클러스터가 있습니까? 따라서로드 밸런서 ping, 포트 ping 및 모니터링 응용 프로그램 응답 시간이 있습니다. 최소한 두 개의 서버 만 있으면되지만 나중에 더 추가 할 수 있습니다 (용량 계획은 어디에 있습니까?). 이제 여기서 유지 보수 기간 동안 히트가없는 업그레이드가 제공됩니다. 부하 분산기에서 서버 중 하나를 관리 할 수 ​​있습니다. 그러나로드 밸런서는 자연스럽게 끝날 때까지 현재 연결이 남아있는 정말 위키아의 관리자 다운을 할 수 있습니다.

이 상태에서 모든 요청은 두 번째 서버로 이동하고 업그레이드하는 서버에 원하는 모든 작업을 수행 할 수 있습니다. 정말로, 왜 3 개월마다 서버를 재부팅하여 중요한 Windows 패치를 적용해야 할 때 멋진 응용 프로그램 도메인을 다시로드하는 응용 프로그램을 작성해야합니까? 하드웨어에 현금을 쏟아 붓고 100 % 제대로 작동하는 무언가를 가지며 계획되지 않은 문제가있는 경우에도 5x9의 범위에서 고객을 확보 할 수 있습니다.

다음은 지리적 중복입니다. 시스코는 지리적로드 밸런싱을 수행 할 수있는로드 밸런싱 제품을 보유하고 있지만 본 적이 없습니다. 필자가 보아온 가장 훌륭한 지오그래픽 모델은 실제로 요청하는 애플리케이션을 기반으로합니다. 이것은 무중단 업그레이드가 아니지만 절대적으로 신뢰할 수 있습니다. 요청 응용 프로그램에서 기본 및 장애 조치 서버 IP 주소를 구성합니다. 서버가 사용할 수 없게되면 요청에있는 응용 프로그램이 대기 상태 (이 경우 동일한 서버 실 또는 백업 위치에있을 수 있음)로 동일한 요청을 시작합니다. 애플리케이션은로드 밸런서 가상 IP를 한 위치 또는 백업 위치로 타겟팅 할 수있는 조합 일 수 있으며로드 밸런서를 사용하여 각 위치에서 100 %를 유지할 수 있습니다.

또한 앱 도메인 간의 대기 시간이나 네트워크 전체의 대기 시간이 걱정되면 그 사람은 적절한 시스코 장비를 사용하고 기가비트 링크의 지연 시간은 마이크로 초이며 사용자가 아닐 것입니다. 약점.

행운을 빈다.