Tetapkan batas sumber daya Memahami alokasi memori armada kontainer Mengkonfigurasi Akses Drive NVMe Tentukan wadah penting Konfigurasikan koneksi jaringan Menyiapkan pemeriksaan kesehatan untuk kontainer Tetapkan dependensi kontainer Konfigurasikan armada kontainer

Sesuaikan sebuah GameLift Server Amazon armada kontainer

Topik di bagian ini menjelaskan beberapa fitur opsional untuk wadah ter Amazon GameLift Servers kelola. Anda dapat memilih untuk menggunakan salah satu atau semua fitur ini.

Topik

Tetapkan batas sumber daya
Memahami alokasi memori armada kontainer
Mengkonfigurasi Akses Drive NVMe
Tentukan wadah penting
Konfigurasikan koneksi jaringan
Menyiapkan pemeriksaan kesehatan untuk kontainer
Tetapkan dependensi kontainer
Konfigurasikan armada kontainer

Tetapkan batas sumber daya

Untuk setiap grup kontainer, Anda dapat menentukan berapa banyak memori dan daya komputasi yang dibutuhkan grup kontainer untuk menjalankan perangkat lunaknya. Amazon GameLift Serversbergantung pada informasi ini untuk mengelola sumber daya di seluruh grup kontainer. Ini juga menggunakan informasi ini untuk menghitung berapa banyak grup kontainer server game yang dapat ditampung oleh gambar armada. Anda juga dapat menetapkan batas untuk wadah individu.

Anda dapat menetapkan batas maksimum pada memori dan daya komputasi untuk grup kontainer. Secara default, sumber daya ini dibagikan oleh semua wadah dalam grup. Anda dapat menyesuaikan manajemen sumber daya lebih lanjut dengan menetapkan batas untuk wadah individu.

Tetapkan batas opsional untuk wadah individu

Menyetel batas sumber daya khusus wadah memungkinkan Anda untuk memberikan kontrol yang lebih besar atas bagaimana wadah individu dapat menggunakan sumber daya grup. Jika Anda tidak menetapkan batas khusus wadah, semua wadah dalam grup berbagi sumber daya grup. Berbagi menawarkan fleksibilitas yang lebih besar untuk menggunakan sumber daya di tempat yang dibutuhkan. Ini juga meningkatkan potensi proses untuk bersaing satu sama lain dan mengakibatkan kegagalan wadah.

Tetapkan salah satu ContainerDefinition properti berikut untuk wadah apa pun.

MemoryHardLimitMebibytes— Tetapkan batas memori maksimum untuk wadah. Jika wadah melebihi batas ini, itu menghasilkan restart.
Vcpulimit — Cadangkan jumlah minimum sumber daya vCPU untuk penggunaan eksklusif kontainer. Wadah selalu memiliki jumlah cadangan yang tersedia untuknya. Ini dapat melebihi minimum ini kapan saja, jika sumber daya tambahan tersedia. (1024 unit CPU setara dengan 1 vCPU.)

Tetapkan batas sumber daya total untuk grup kontainer

Jika Anda menetapkan batas untuk wadah individual, Anda mungkin perlu mengubah jumlah memori dan sumber daya vCPU yang dibutuhkan grup kontainer. Tujuannya adalah untuk mengalokasikan sumber daya yang cukup untuk mengoptimalkan kinerja server game. Amazon GameLift Serversmenggunakan batasan ini untuk menghitung cara mengemas grup kontainer server game pada instance armada. Anda juga akan menggunakannya saat memilih jenis instans untuk armada kontainer.

Hitung total memori dan vCPU yang dibutuhkan untuk grup kontainer. Pertimbangkan hal berikut:

Apa saja proses yang berjalan di semua wadah dalam grup kontainer? Tambahkan sumber daya yang diperlukan untuk proses ini. Perhatikan batasan khusus wadah apa pun.
Berapa banyak proses server game bersamaan yang Anda rencanakan untuk dijalankan di setiap grup kontainer? Anda menentukan ini dalam gambar wadah server game Anda.

Berdasarkan perkiraan persyaratan grup kontainer Anda, tetapkan ContainerGroupDefinition properti berikut:

TotalMemoryLimitMebibytes— Tetapkan batas memori maksimum untuk grup kontainer. Semua wadah dalam grup berbagi memori yang dialokasikan. Jika Anda menetapkan batas wadah individu, batas memori total harus sama dengan atau lebih besar dari batas memori khusus wadah tertinggi.
TotalVcpuLimit— Tetapkan batas vCPU maksimum untuk grup kontainer. Semua wadah dalam grup berbagi sumber daya CPU yang dialokasikan. Jika Anda menetapkan batas kontainer individual, batas CPU total harus sama dengan atau lebih besar dari jumlah semua batas CPU khusus kontainer. Sebagai praktik terbaik, pertimbangkan untuk mengatur nilai ini untuk menggandakan jumlah batas CPU kontainer.

Contoh skenario

Katakanlah kita mendefinisikan grup kontainer server game dengan tiga kontainer berikut:

Wadah A adalah wadah server game kami. Kami memperkirakan kebutuhan sumber daya untuk satu server game pada 512 MiB dan 1024 CPU. Kami berencana untuk menjalankan wadah 1 proses server. Karena wadah ini menjalankan perangkat lunak kami yang paling penting, kami tidak menetapkan batas memori atau batas cadangan vCPU.
Container B adalah wadah pendukung dengan kebutuhan sumber daya diperkirakan 1024 MiB dan 1536 CPU. Kami menetapkan batas memori 2048 MiB, dan batas cadangan CPU 1024 CPU.
Wadah C adalah wadah pendukung lainnya. Kami menetapkan batas memori keras 512 MiB dan batas cadangan CPU 512 CPU.

Dengan menggunakan informasi ini, kami menetapkan batas total berikut untuk grup kontainer:

Batas memori total: 7680 MiB. Nilai ini melebihi batas memori tertinggi (1024 MiB).
Batas total CPU: 13312 CPU. Nilai ini melebihi jumlah batas CPU (1024+512 CPU).

Memahami alokasi memori armada kontainer

Saat Amazon GameLift Servers menerapkan grup kontainer pada instance armada, tidak semua memori instans tersedia untuk kontainer Anda. Amazon GameLift Serversmenyimpan sebagian memori instans untuk sistem operasi, agen Amazon ECS, dan layanan pendukung lainnya. Jumlah memori yang dicadangkan bervariasi berdasarkan total memori jenis instans. Memahami overhead ini membantu Anda mengonfigurasi definisi grup kontainer Anda untuk sepenuhnya memanfaatkan sumber daya yang tersedia.

Rumus overhead memori

Amazon GameLift Serversmenghitung memori yang tersedia untuk grup kontainer Anda menggunakan langkah-langkah berikut:

Tentukan persentase buffer memori. Amazon GameLift Serversmenyimpan persentase dari total memori instans berdasarkan tingkatan berikut:

Memori instans (MiB)	Persentase yang dicadangkan
Kurang dari 5.000	8%
5.000 sampai 9.999	6%
10.000 sampai 89.999	5%
90.000 sampai 199,999	4%
200.000 atau lebih	3%

Hitung memori yang tersedia. Kurangi memori cadangan dari total memori instance:

AvailableMemory = InstanceMemory - round(InstanceMemory × BufferPercentage)
Kurangi memori grup kontainer per instans. Jika armada Anda menggunakan grup kontainer per instans, kurangi grup tersebut TotalMemoryLimitMebibytes dari memori yang tersedia. Satu grup kontainer per instans berjalan pada setiap instance armada.

AvailableMemory = AvailableMemory - PerInstanceCGD.TotalMemoryLimitMebibytes
Akun untuk overhead router log. Jika logging diaktifkan untuk armada, Amazon GameLift Servers cadangan tambahan 50 MiB per grup kontainer server game untuk router log.
Hitung grup kontainer server game maksimum. Jumlah maksimum grup wadah server game yang sesuai dengan instance berdasarkan memori adalah:

MaxGroupsByMemory = floor(AvailableMemory / (GameServerCGD.TotalMemoryLimitMebibytes + LogRouterMemory))

Dim LogRouterMemory ana 50 MiB jika logging diaktifkan, atau 0 jika logging dinonaktifkan.

catatan

Memori hanyalah satu faktor yang menentukan berapa banyak grup wadah server game yang cocok pada sebuah instance. Amazon GameLift Serversjuga mempertimbangkan kapasitas vCPU dan port koneksi yang tersedia, dan menggunakan minimum dari ketiga perhitungan.

Contoh perhitungan memori

Pertimbangkan armada menggunakan c5.xlarge instance (total memori 8.192 MiB) dengan logging diaktifkan:

Memori instans adalah 8.192 MiB, yang berada di tingkat 5.000—9.999 (buffer 6%)
Memori cadangan = bulat (8.192 × 0,06) = 492 MiB
Memori yang tersedia = 8.192 - 492 = 7.700 MiB
Jika menggunakan grup kontainer per instans dengan 512: TotalMemoryLimitMebibytes Memori yang tersedia = 7.700 - 512 = 7.188 MiB
Jika setiap grup wadah server game memiliki TotalMemoryLimitMebibytes 1.024: MaxGroupsByMemory = lantai (7.188/(1.024 + 50)) = lantai (7.188/1.074) = 6

Memori yang tersedia berdasarkan jenis instance

Tabel berikut menunjukkan total memori dan memori yang tersedia (setelah Amazon GameLift Servers buffer) untuk jenis instans yang umum digunakan. Gunakan nilai-nilai ini sebagai titik awal saat mengonfigurasi definisi grup kontainer Anda. Kolom Memori yang tersedia menunjukkan memori yang tersedia untuk semua grup kontainer pada instans, sebelum mengurangi setiap grup kontainer per instans atau overhead router log.

Tipe instans	Total memori (MiB)	Persentase penyangga	Memori yang tersedia (MiB)
`c5.large`	4.096	8%	3.768
`c5.xlarge`	8.192	6%	7.700
`c5.2xlarge`	16.384	5%	15.565
`c5.4xlarge`	32.768	5%	31.130
`c5.9xlarge`	73,728	5%	70.042
`c5.12xlarge`	98.304	4%	94.372
`c5.18xlarge`	147.456	4%	141.558
`c5.24xlarge`	196٬608	4%	188.744
`m5.large`	8.192	6%	7.700
`m5.xlarge`	16.384	5%	15.565
`m5.2xlarge`	32.768	5%	31.130
`m5.4xlarge`	65,536	5%	62.259
`m5.8xlarge`	131٬072	4%	125.829
`m5.12xlarge`	196٬608	4%	188.744
`r5.large`	16.384	5%	15.565
`r5.xlarge`	32.768	5%	31.130
`r5.2xlarge`	65,536	5%	62.259
`r5.4xlarge`	131٬072	4%	125.829
`c6i.large`	4.096	8%	3.768
`c6i.xlarge`	8.192	6%	7.700
`c6i.2xlarge`	16.384	5%	15.565
`c6i.4xlarge`	32.768	5%	31.130
`c6i.8xlarge`	65,536	5%	62.259
`c7i.large`	4.096	8%	3.768
`c7i.xlarge`	8.192	6%	7.700
`c7i.2xlarge`	16.384	5%	15.565
`c7i.4xlarge`	32.768	5%	31.130
`c7i.8xlarge`	65,536	5%	62.259
`m7i.large`	8.192	6%	7.700
`m7i.xlarge`	16.384	5%	15.565
`m7i.2xlarge`	32.768	5%	31.130
`m7i.4xlarge`	65,536	5%	62.259
`m7i.8xlarge`	131٬072	4%	125.829
`m7i.12xlarge`	196٬608	4%	188.744
`r7i.large`	16.384	5%	15.565
`r7i.xlarge`	32.768	5%	31.130
`r7i.2xlarge`	65,536	5%	62.259
`r7i.4xlarge`	131٬072	4%	125.829
`c8a.medium`	2.048	8%	1.884
`c8a.large`	4.096	8%	3.768
`c8a.xlarge`	8.192	6%	7.700
`c8a.2xlarge`	16.384	5%	15.565
`c8i.large`	4.096	8%	3.768
`c8i.xlarge`	8.192	6%	7.700
`c8i.2xlarge`	16.384	5%	15.565
`m8a.medium`	4.096	8%	3.768
`m8a.large`	8.192	6%	7.700
`m8a.xlarge`	16.384	5%	15.565
`m8a.2xlarge`	32.768	5%	31.130
`m8i.large`	8.192	6%	7.700
`m8i.xlarge`	16.384	5%	15.565
`m8i.2xlarge`	32.768	5%	31.130
`c9g.medium`	2.048	8%	1.884
`c9g.large`	4.096	8%	3.768
`c9g.xlarge`	8.192	6%	7.700
`c9g.2xlarge`	16.384	5%	15.565
`m9g.large`	8.192	6%	7.700
`m9g.xlarge`	16.384	5%	15.565
`m9g.2xlarge`	32.768	5%	31.130

Misalnya jenis yang tidak tercantum di sini, Anda dapat menghitung memori yang tersedia menggunakan rumus yang dijelaskan di atas. Periksa dokumentasi jenis instans Amazon EC2 untuk total memori jenis instans yang Anda pilih.

Mengkonfigurasi Akses Drive NVMe

Pada instance tipe-d, drive NVMe secara otomatis dipasang ke /data direktori selama startup host. Untuk mengaktifkan wadah untuk mengakses penyimpanan SSD, atur ContainerGroupDefinition properti berikutMountPoints:

InstancePath— Setel /data untuk mereferensikan drive NVMe yang dipasang secara otomatis pada instance host.
AccessLevel— Pilih tingkat akses yang sesuai untuk kebutuhan wadah Anda (misalnya, READ_ONLY atau READ_WRITE).
ContainerPath— (Opsional) Tentukan jalur di mana jalur instance akan dipasang di dalam wadah. Jika tidak ditentukan, default ke jalur instance.

Untuk informasi selengkapnya tentang titik pemasangan, lihat ContainerMountPoint Referensi API GameLift Server Amazon.

Tentukan wadah penting

Untuk grup kontainer per instans, tentukan setiap wadah sebagai penting atau tidak esensial. Per-instance kelompok kontainer harus memiliki setidaknya satu wadah pendukung penting. Wadah penting melakukan pekerjaan penting dari grup kontainer. Wadah penting selalu diharapkan berjalan. Jika gagal, seluruh grup kontainer dimulai ulang.

Setel ContainerDefinition properti Essential ke true atau false untuk setiap wadah.

Konfigurasikan koneksi jaringan

Anda dapat menyesuaikan akses jaringan untuk memungkinkan lalu lintas eksternal terhubung ke kontainer apa pun dalam armada kontainer. Misalnya, Anda harus membuat koneksi jaringan ke wadah yang menjalankan proses server game Anda, sehingga klien game dapat bergabung dan memainkan game Anda. Klien game terhubung ke server game menggunakan port dan alamat IP.

Dalam armada kontainer, koneksi antara klien dan server tidak langsung. Secara internal, proses dalam wadah mendengarkan di port kon tainer. Secara eksternal, lalu lintas masuk terhubung ke instance armada menggunakan port koneksi. Amazon GameLift Serversmemelihara pemetaan antara port kontainer internal dan port koneksi eksternal, sehingga lalu lintas masuk dialihkan ke proses yang benar pada instance. Untuk mengambil pemetaan port saat ini untuk grup kontainer tertentu, panggil operasi. DescribeContainerGroupPortMappings Untuk informasi selengkapnya tentang melihat pemetaan port, lihat. Lihat pemetaan port kontainer

Amazon GameLift Serversmenyediakan lapisan kontrol tambahan untuk koneksi jaringan Anda. Setiap armada kontainer memiliki pengaturan izin masuk, yang memungkinkan Anda mengontrol akses ke setiap port koneksi yang menghadap ke eksternal. Misalnya, Anda dapat menghapus izin untuk semua port koneksi untuk mematikan semua akses ke kontainer armada.

Anda dapat memperbarui izin masuk armada, port koneksi, dan port kontainer.

Awas

Jika Anda memberikan kustom InstanceConnectionPortRange atau InstanceInboundPermissions, tidak Amazon GameLift Servers akan lagi mengelola nilai kedua untuk armada Anda. Anda harus mengatur kedua bidang untuk menghindari perilaku yang tidak ditentukan.

Atur rentang port kontainer

Konfigurasikan rentang port kontainer sebagai bagian dari setiap definisi kontainer. Ini adalah parameter yang diperlukan untuk definisi grup kontainer. Anda perlu mengkonfigurasi port yang cukup untuk mengakomodasi semua proses yang berjalan secara bersamaan yang membutuhkan akses eksternal. Beberapa kontainer tidak memerlukan port apa pun.

Wadah server game Anda, yang menjalankan server game Anda, membutuhkan port untuk setiap proses server game yang berjalan secara bersamaan. Proses server game mendengarkan port yang ditetapkan dan melaporkannya keAmazon GameLift Servers.

Atur rentang port koneksi

Konfigurasikan armada kontainer Anda dengan satu set port koneksi. Port koneksi menyediakan akses eksternal ke instans armada yang menjalankan kontainer Anda. Amazon GameLift Serversmenetapkan port koneksi dan memetakannya ke port kontainer sesuai kebutuhan.

Secara default, Amazon GameLift Servers menghitung jumlah port yang diperlukan untuk semua grup kontainer dan menetapkan rentang port untuk mengakomodasi mereka. Kami sangat menyarankan Anda menggunakan nilai yang Amazon GameLift Servers dihitung, yang diperbarui saat Anda menerapkan pembaruan ke definisi grup kontainer. Jika Anda perlu menyesuaikan rentang port koneksi, gunakan panduan berikut.

Saat Anda membuat armada kontainer, tentukan rentang port koneksi (lihat ContainerFleet:InstanceConnectionPortRange). Pastikan jangkauan memiliki cukup port untuk dipetakan ke setiap port kontainer yang ditentukan di semua kontainer di kedua grup kontainer dalam armada. Untuk menghitung port koneksi minimum yang diperlukan, gunakan rumus berikut:

[Total number of container ports defined for containers in the game server container group] * [Number of game server container groups per instance] + [Total number of container ports defined for containers in the per-instance container group]

Sebagai praktik terbaik, gandakan jumlah minimum port koneksi.

catatan

Jumlah port koneksi berpotensi membatasi jumlah grup kontainer server game per instance. Jika armada hanya memiliki port koneksi yang cukup untuk satu grup kontainer server game per instance, hanya Amazon GameLift Servers akan menerapkan satu grup kontainer server game, bahkan jika instans memiliki daya komputasi yang cukup untuk beberapa grup kontainer server game.

Tetapkan izin masuk

Izin masuk mengontrol akses eksternal ke armada kontainer dengan menentukan port koneksi mana yang akan dibuka untuk lalu lintas masuk. Anda dapat menggunakan pengaturan ini untuk mengaktifkan dan menonaktifkan akses jaringan armada sesuai kebutuhan.

Saat Anda membuat armada kontainer, tentukan sekumpulan izin masuk (lihat ContainerFleet:InstanceInboundPermissions). Port izin masuk harus sesuai dengan rentang port koneksi armada.

catatan

Karena port kontainer dipilih secara acak dari InstanceConnectionPortRange, untuk menjamin bahwa koneksi sesi dapat dibuat, semua port di InstanceConnectionPortRange harus ditutupi oleh port di InstanceInboundPermissions

Contoh skenario

Contoh ini menggambarkan cara mengatur ketiga properti koneksi jaringan.

Grup kontainer server game armada kami memiliki 1 kontainer, yang menjalankan 1 proses server game.

Dalam definisi grup wadah server game, kami menetapkan PortConfiguration parameter untuk wadah ini sebagai berikut:
```
"PortConfiguration": {
  "ContainerPortRanges": [ { "FromPort": 10, "ToPort": 20, "Protocol": "TCP"} ]  } 
```
Armada kami juga memiliki grup kontainer per instans dengan 1 kontainer. Ini memiliki 1 proses yang membutuhkan akses jaringan. Dalam definisi container per instance, kita menetapkan PortConfiguration parameter untuk wadah ini sebagai berikut:
```
"PortConfiguration": {
  "ContainerPortRanges": [ { "FromPort": 25, "ToPort": 25, "Protocol": "TCP"} ]  }
```

Armada kami dikonfigurasi dengan 20 grup kontainer server game per instance armada. Dengan informasi ini, kita dapat menggunakan rumus untuk menghitung jumlah port koneksi yang kita butuhkan:
- Minimum: 21 port [1 port kontainer server game* 20 grup kontainer server game per instance+1 port kontainer per instans]
- Praktik terbaik: 42 port [port minimum* 2]
Saat membuat armada kontainer, kami mengatur InstanceConnectionPortRange parameter sebagai berikut:
```
"InstanceConnectionPortRange": { "FromPort": 1010, "ToPort": 1071 }
```
Kami ingin mengizinkan akses ke semua port koneksi yang tersedia. Saat membuat armada kontainer, kami mengatur InstanceInboundPermissions parameter sebagai berikut:
```
"InstanceInboundPermissions": [ 
  {"FromPort": 1010, "ToPort": 1071, "IpRange": "10.24.34.0/23", "Protocol": "TCP"} ]
```

Menyiapkan pemeriksaan kesehatan untuk kontainer

Sebuah wadah secara otomatis memulai ulang jika mengalami kegagalan terminal dan berhenti berjalan. Jika wadah dianggap penting, itu meminta seluruh grup kontainer untuk memulai ulang.

Semua wadah server game secara otomatis dianggap penting. Wadah pendukung dapat ditetapkan penting, tetapi mereka harus memiliki mekanisme untuk melaporkan kesehatan. Anda juga dapat mengatur pemeriksaan kesehatan untuk wadah dukungan yang tidak penting.

Anda dapat menentukan kriteria khusus tambahan untuk mengukur kesehatan wadah dan menggunakan pemeriksaan kesehatan untuk menguji kriteria tersebut. Untuk mengatur pemeriksaan kesehatan kontainer, Anda dapat mendefinisikannya dalam gambar kontainer Docker atau dalam definisi wadah Anda. Jika Anda menetapkan pemeriksaan kesehatan dalam definisi wadah, pemeriksaan tersebut akan menggantikan pengaturan apa pun dalam gambar wadah.

Tetapkan SupportContainerDefinition properti berikut untuk pemeriksaan kesehatan wadah:

Command- Berikan perintah yang memeriksa beberapa aspek kesehatan wadah. Anda memutuskan kriteria apa yang digunakan untuk mengukur kesehatan. Perintah harus menghasilkan nilai keluar 1 (tidak sehat) atau 0 (sehat).
StartPeriod— Tentukan penundaan awal sebelum kegagalan pemeriksaan kesehatan mulai dihitung. Penundaan ini memberikan waktu wadah untuk mem-bootstrap prosesnya.
Interval— Putuskan seberapa sering menjalankan perintah pemeriksaan kesehatan. Seberapa cepat Anda ingin mendeteksi dan menyelesaikan kegagalan kontainer?
Timeout— Putuskan berapa lama menunggu keberhasilan atau kegagalan sebelum mencoba kembali perintah pemeriksaan kesehatan. Berapa lama waktu yang dibutuhkan perintah pemeriksaan kesehatan untuk diselesaikan?
Retries— Berapa kali perintah pemeriksaan kesehatan harus dicoba ulang sebelum mendaftarkan kegagalan?

Tetapkan dependensi kontainer

Dalam setiap grup kontainer Anda dapat mengatur dependensi antar kontainer berdasarkan status kontainer. Ketergantungan berdampak ketika wadah dependen dapat memulai atau dimatikan berdasarkan status wadah lain.

Kasus penggunaan utama untuk dependensi adalah membuat urutan startup dan shutdown untuk grup kontainer.

Misalnya, Anda mungkin ingin Kontainer A dimulai terlebih dahulu dan selesai dengan sukses sebelum Kontainer B dan C dimulai. Untuk mencapai hal ini, pertama-tama buat dependensi untuk Kontainer B pada Wadah A, dengan syarat bahwa Kontainer A harus berhasil diselesaikan. Kemudian buat dependensi untuk Container C pada Container A dengan kondisi yang sama. Urutan startup terjadi dalam urutan terbalik untuk shutdown.

Konfigurasikan armada kontainer

Saat Anda membuat armada kontainer, pertimbangkan poin keputusan berikut. Sebagian besar poin ini tergantung pada arsitektur kontainer dan konfigurasi Anda.

Tentukan di mana Anda ingin menyebarkan armada Anda

Secara umum, Anda ingin menyebarkan armada Anda secara geografis di dekat pemain Anda untuk meminimalkan latensi. Anda dapat menyebarkan armada kontainer Anda ke mana pun Wilayah AWS yang Amazon GameLift Servers mendukung. Jika Anda ingin menyebarkan server game yang sama ke lokasi geografis tambahan, Anda dapat menambahkan lokasi jarak jauh ke armada termasuk Wilayah AWS dan Zona Lokal. Untuk armada multi-lokasi, Anda dapat menyesuaikan kapasitas secara independen di setiap lokasi armada. Untuk informasi selengkapnya tentang lokasi armada yang didukung, lihatGameLift Server Amazon lokasi layanan.

Pertimbangkan UDP ping beacon untuk menggunakan untuk mengumpulkan data latensi jaringan di berbagai lokasi geografis untuk mengantisipasi latensi antara perangkat pemain dan lokasi armada potensial. Titik akhir khusus ini menerima pesan UDP, alih-alih ping ICMP konvensional, sehingga memberikan pengukuran latensi yang akurat untuk membantu Anda memilih lokasi armada yang optimal.

Pilih jenis dan ukuran instans untuk armada Anda

Amazon GameLift Serversmendukung berbagai jenis instans Amazon EC2, yang semuanya tersedia untuk digunakan dengan armada kontainer. Ketersediaan jenis instans dan harga bervariasi menurut lokasi. Anda dapat melihat daftar jenis instans yang didukung, difilter berdasarkan lokasi, di Amazon GameLift Servers konsol (di bawah Kuota Sumber Daya, Instans, dan layanan).

Saat memilih jenis instance, pertama-tama pertimbangkan keluarga instance. Keluarga instans menawarkan berbagai kombinasi kemampuan CPU, memori, penyimpanan, dan jaringan. Dapatkan informasi selengkapnya tentang keluarga instans EC2. Dalam setiap keluarga, Anda memiliki berbagai ukuran instance untuk dipilih. Pertimbangkan masalah berikut saat memilih ukuran instance:

Berapa ukuran instans minimum yang dapat mendukung beban kerja Anda? Gunakan informasi ini untuk menghilangkan semua jenis instans yang terlalu kecil.
Ukuran tipe instance apa yang cocok untuk arsitektur kontainer Anda? Idealnya, Anda ingin memilih ukuran yang dapat menampung beberapa salinan grup wadah server game Anda dengan ruang yang terbuang minimal.
Rincian penskalaan apa yang masuk akal untuk game Anda? Kapasitas armada skala melibatkan penambahan atau penghapusan instance, dan setiap instance mewakili kemampuan untuk meng-host sejumlah sesi game tertentu. Pertimbangkan berapa banyak kapasitas yang ingin Anda tambahkan atau hapus dengan setiap instance. Jika permintaan pemain bervariasi ribuan dari menit ke menit, maka mungkin masuk akal untuk menggunakan instance yang sangat besar yang dapat menampung ratusan atau ribuan sesi permainan. Sebaliknya, Anda mungkin lebih suka kontrol penskalaan yang lebih halus dengan jenis instance yang lebih kecil.
Apakah ada penghematan biaya yang tersedia berdasarkan ukuran? Anda mungkin menemukan bahwa biaya jenis instans tertentu bervariasi menurut lokasi karena ketersediaan.

Mengatur pengaturan armada opsional lainnya

Anda dapat menggunakan fitur opsional berikut saat mengonfigurasi armada kontainer:

Siapkan server game Anda untuk mengakses AWS sumber daya lain. Lihat Hubungkan Anda GameLift Server Amazon server game yang di-host ke yang lain AWS sumber daya.
Lindungi sesi permainan dengan pemain aktif agar tidak berakhir sebelum waktunya selama acara yang diperkecil.
Batasi jumlah sesi permainan yang dapat dibuat satu individu pada armada dalam rentang waktu terbatas.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Pilih sumber daya komputasi

Kurangi biaya hosting dengan armada Spot