이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 6. Deploying a single logical service across many sites for failover


A typical scenario for using Service Interconnect is to deploy a server process on two sites with the intention that if one site fails, the other site seamlessly processes any further requests. In this scenario the primary server responds to all requests while that server is available and traffic is only directed to the secondary server when the primary server is not available. The procedure describes two servers, however this technique works for many servers.

Prerequisites

  • Two or more unlinked sites.
  • A basic understanding of Service Interconnect and its networking model.

Procedure

  1. Create sites by using skupper init.
  2. Deploy your servers on different sites.
  3. Generate a token on the first site:

    $ skupper token create token.yaml

    This file contains a key and the location of the site that created it.

    Note

    Access to this file provides access to the service network. Protect it appropriately.

  4. Use the token on the cluster that you want to connect from:

    To create a link to the first site:

    $ skupper link create token.yaml --cost 99999

    The high cost setting means that traffic is not directed to this site under normal circumstances. However, if there is no other server available, all traffic is directed to this site.

  5. Expose the servers on the service network for both sites.

    1. Create the service:

      $ skupper service create <name> <port>

      where

      • <name> is the name of the service you want to create.
      • <port> is the port the service uses.

      By default, this service is now visible on both sites, although there is no server available to process requests to this service.

      Note

      By default, if you create a service on one site, it is available on all sites. However, if enable-service-sync is set to false you need to create the service on both sites.

    2. Bind the service with the server on both sites.

      $ skupper service bind <service-name> <target-type> <target-name>

      where

      • <service-name> is the name of the service on the service network
      • <target-type> is the object you want to expose, deployment, statefulset, pods, or service.
      • <target-name> is the name of the cluster service

      For example:

      $ skupper service bind hello-world-backend deployment hello-world-backend
  6. You can use the console to check the traffic flow or monitor the services using your tooling. Clients can connect to either site, and the server on that site processes the requests until the server is not available. Further requests are processed by the server on the other site.

If the server on the original site becomes available, it processes all further requests. However existing TCP connections to the secondary or backup server will persist until those TCP connections are closed.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.