diff --git a/README.md b/README.md index df61d1321c3..c89151e50a2 100644 --- a/README.md +++ b/README.md @@ -17,6 +17,8 @@ Garnet is a new remote cache-store from Microsoft Research, that offers several This repo contains the code to build and run Garnet. For more information and documentation, check out our website at [https://microsoft.github.io/garnet](https://microsoft.github.io/garnet). +**Looking for a fully managed service?** [Azure Cosmos DB Garnet Cache](https://microsoft.github.io/garnet/docs/azure/overview) provides Garnet as a fully managed, enterprise-ready caching solution with built-in high availability, performance guarantees and zero infrastructure management. + ## Feature Summary Garnet implements a wide range of APIs including raw strings (e.g., gets, sets, and key expiration), analytical (e.g., HyperLogLog and Bitmap), and object (e.g., sorted sets and lists) diff --git a/website/docs/azure/api-compatibility.md b/website/docs/azure/api-compatibility.md new file mode 100644 index 00000000000..ec709869035 --- /dev/null +++ b/website/docs/azure/api-compatibility.md @@ -0,0 +1,286 @@ +--- +id: api-compatibility +sidebar_label: API Compatibility +title: API compatibility for Azure Cosmos DB Garnet Cache +--- + +# API compatibility for Azure Cosmos DB Garnet Cache + +Below is the full list of API commands and their implementation status in Azure Cosmos DB Garnet Cache. There is compatibility with Redis clients and support for a subset of Redis data types and commands. The maximum size for a key value pair is 32MB. For the lowest latency, it’s recommended to keep the size of a key value pair to around 1KB. + +## Command Categories + +The Azure Cosmos DB Garnet Cache implements a growing subset of the [open-source Garnet commands](../commands/api-compatibility.md). Categories with at least one supported command are listed here. + +1. [CLIENT](#client) +2. [CLUSTER](#cluster) +3. [COMMAND](#command) +4. [CONNECTION](#connection) +5. [GENERIC](#generic) +6. [HASH](#hash) +7. [KEYS](#keys) +8. [LATENCY](#latency) +9. [PUB/SUB](#pubsub) +10. [SCRIPTING](#scripting) +11. [SERVER](#server) +12. [SET](#set) +13. [SORTED SET](#sorted-set) +14. [STRING](#string) + +## Full Commands List + +| Category | Command | Implemented in Azure Cosmos DB Garnet Cache | Notes | +| ------------- | ------------- | ------------- | ------------- | +| **CLIENT** | CACHING | ➖ | | +| | [GETNAME](../commands/client.md#client-getname) | ➖ | | +| | GETREDIR | ➖ | | +| | HELP | ➖ | | +| | [ID](../commands/client.md#client-id) | ➕ | | +| | [INFO](../commands/client.md#client-info) | ➕ | | +| | [KILL](../commands/client.md#client-kill) | ➖ | | +| | [LIST](../commands/client.md#client-list) | ➖ | | +| | NO-EVICT | ➖ | | +| | NO-TOUCH | ➖ | | +| | PAUSE | ➖ | | +| | REPLY | ➖ | | +| | [SETINFO](../commands/client.md#client-setinfo) | ➖ | | +| | [SETNAME](../commands/client.md#client-setname) | ➖ | | +| | TRACKING | ➖ | | +| | TRACKINGINFO | ➖ | | +| | [UNBLOCK](../commands/client.md#client-unblock) | ➖ | | +| | UNPAUSE | ➖ | | +| **CLUSTER** | [ADDSLOTS](../commands/cluster.md#cluster-addslots) | ➖ | | +| | [ADDSLOTSRANGE](../commands/cluster.md#cluster-addslotsrange) | ➖ | | +| | [ASKING](../commands/cluster.md#asking) | ➖ | | +| | [BUMPEPOCH](../commands/cluster.md#cluster-bumpepoch) | ➖ | | +| | COUNT-FAILURE-REPORTS | ➖ | | +| | [COUNTKEYSINSLOT](../commands/cluster.md#cluster-countkeysinslot) | ➖ | | +| | [DELSLOTS](../commands/cluster.md#cluster-delslots) | ➖ | | +| | [DELSLOTSRANGE](../commands/cluster.md#cluster-delslotsrange) | ➖ | | +| | [FAILOVER](../commands/cluster.md#cluster-failover) | ➖ | | +| | FLUSHSLOTS | ➖ | | +| | [FORGET](../commands/cluster.md#cluster-forget) | ➖ | | +| | [GETKEYINSLOT](../commands/cluster.md#cluster-getkeysinslot) | ➖ | | +| | [INFO](../commands/cluster.md#cluster-info) | ➖ | | +| | [KEYSLOT](../commands/cluster.md#cluster-keyslot) | ➕ | | +| | LINKS | ➖ | | +| | [MEET](../commands/cluster.md#cluster-meet) | ➖ | | +| | [MYID](../commands/cluster.md#cluster-myid) | ➖ | | +| | MYSHARDID | ➖ | | +| | [NODES](../commands/cluster.md#cluster-nodes) | ➕ | | +| | [READONLY](../commands/cluster.md#readonly) | ➕ | | +| | [READWRITE](../commands/cluster.md#readwrite) | ➕ | | +| | [REPLICAS](../commands/cluster.md#cluster-replicas) | ➖ | | +| | [REPLICATE](../commands/cluster.md#cluster-replicate) | ➖ | | +| | [RESET](../commands/cluster.md#reset) | ➖ | | +| | SAVECONFIG | ➖ | | +| | [SET-CONFIG-EPOCH](../commands/cluster.md#cluster-set-config-epoch) | ➖ | | +| | [SETSLOT](../commands/cluster.md#cluster-setslot) | ➖ | | +| | SHARDS | ➖ | | +| | [SLAVES](../commands/cluster.md#slaves) | ➖ | (Deprecated) | +| | [SLOTS](../commands/cluster.md#cluster-slots) | ➕ | (Deprecated) | +| **COMMAND** | [COMMAND](../commands/server.md#command) | ➖ | | +| | [COUNT](../commands/server.md#command-count) | ➖ | | +| | [DOCS](../commands/server.md#command-docs) | ➖ | | +| | [GETKEYS](../commands/server.md#command-getkeys) | ➖ | | +| | [GETKEYSANDFLAGS](../commands/server.md#command-getkeysandflags) | ➖ | | +| | HELP | ➖ | | +| | [INFO](../commands/server.md#command-info) | ➕ | | +| | LIST | ➖ | | +| **CONNECTION** | [AUTH](../commands/generic-commands.md#auth) | ➖ | | +| | [ECHO](../commands/generic-commands.md#echo) | ➕ | | +| | [HELLO](../commands/generic-commands.md#hello) | ➖ | | +| | [PING](../commands/generic-commands.md#ping) | ➕ | | +| | [QUIT](../commands/generic-commands.md#quit) | ➖ | (Deprecated) | +| | [SELECT](../commands/generic-commands.md#select) | ➖ | | +| **GENERIC** | [PERSIST](../commands/generic-commands.md#persist) | ➖ | | +| | [PEXPIRE](../commands/generic-commands.md#pexpire) | ➖ | | +| | [PEXPIREAT](../commands/generic-commands.md#pexpireat) | ➖ | | +| | [PEXPIRETIME](../commands/generic-commands.md#pexpiretime) | ➖ | | +| | [PTTL](../commands/generic-commands.md#pttl) | ➖ | | +| | RANDOMKEY | ➖ | | +| | [RENAME](../commands/generic-commands.md#rename) | ➖ | | +| | [RENAMENX](../commands/generic-commands.md#renamenx) | ➖ | | +| | [RESTORE](../commands/generic-commands.md#restore) | ➖ | +| | [SCAN](../commands/generic-commands.md#scan) | ➖ | | +| | SORT | ➖ | | +| | SORT_RO | ➖ | | +| | TOUCH | ➖ | | +| | [TTL](../commands/generic-commands.md#ttl) | ➖ | | +| | [TYPE](../commands/generic-commands.md#type) | ➖ | | +| | [UNLINK](../commands/generic-commands.md#unlink) | ➕ | | +| | WAIT | ➖ | | +| | WAITAOF | ➖ | | +| **HASH** | [HDEL](../commands/data-structures.md#hdel) | ➕ | | +| | [HEXISTS](../commands/data-structures.md#hexists) | ➕ | | +| | [HEXPIRE](../commands/data-structures.md#hexpire) | ➕ | | +| | [HEXPIREAT](../commands/data-structures.md#hexpireat) | ➕ | | +| | [HEXPIRETIME](../commands/data-structures.md#hexpiretime) | ➕ | | +| | [HGET](../commands/data-structures.md#hget) | ➕ | | +| | [HGETALL](../commands/data-structures.md#hgetall) | ➕ | | +| | [HINCRBY](../commands/data-structures.md#hincrby) | ➕ | | +| | [HINCRBYFLOAT](../commands/data-structures.md#hincrbyfloat) | ➕ | | +| | [HKEYS](../commands/data-structures.md#hkeys) | ➕ | | +| | [HLEN](../commands/data-structures.md#hlen) | ➕ | | +| | [HMGET](../commands/data-structures.md#hmget) | ➕ | | +| | [HMSET](../commands/data-structures.md#hmset) | ➕ | (Deprecated) | +| | [HPERSIST](../commands/data-structures.md#hpersist) | ➕ | | +| | [HPEXPIRE](../commands/data-structures.md#hpexpire) | ➕ | | +| | [HPEXPIREAT](../commands/data-structures.md#hpexpireat) | ➕ | | +| | [HPEXPIRETIME](../commands/data-structures.md#hepxpiretime) | ➕ | | +| | [HPTTL](../commands/data-structures.md#hpttl) | ➕ | | +| | [HRANDFIELD](../commands/data-structures.md#hrandfield) | ➕ | | +| | [HSCAN](../commands/data-structures.md#hscan) | ➕ | | +| | [HSET](../commands/data-structures.md#hset) | ➕ | | +| | [HSETNX](../commands/data-structures.md#hsetnx) | ➕ | | +| | [HSTRLEN](../commands/data-structures.md#hstrlen) | ➕ | | +| | [HTTL](../commands/data-structures.md#httl) | ➕ | | +| | [HVALS](../commands/data-structures.md#hvals) | ➕ | | +| **KEYS** | COPY | ➖ | | +| | [DEL](../commands/generic-commands.md#del) | ➕ | | +| | [DUMP](../commands/generic-commands.md#dump) | ➖ | +| | [EXISTS](../commands/generic-commands.md#exists) | ➕ | | +| | [EXPIRE](../commands/generic-commands.md#expire) | ➕ | | +| | [EXPIREAT](../commands/generic-commands.md#expireat) | ➖ | | +| | [EXPIRETIME](../commands/generic-commands.md#expiretime) | ➖ | | +| | [KEYS](../commands/generic-commands.md#keys) | ➖ | | +| | [MIGRATE](../commands/generic-commands.md#migrate) | ➖ | | +| | MOVE | ➖ | | +| **LATENCY** | DOCTOR | ➖ | | +| | GRAPH | ➖ | | +| | HELP | ➖ | | +| | [HISTOGRAM](../commands/server.md#latency-histogram) | ➕ | | +| | HISTORY | ➖ | | +| | LATEST | ➖ | | +| | [RESET](../commands/server.md#latency-reset) | ➕ | | +| **PUB/SUB** | [PSUBSCRIBE](../commands/analytics.md#psubscribe) | ➕ | | +| | [PUBLISH](../commands/analytics.md#publish) | ➕ | | +| | [PUBSUB CHANNELS](../commands/analytics.md#pubsub-channels) | ➕ | | +| | PUBSUB HELP | ➖ | | +| | [PUBSUB NUMPAT](../commands/analytics.md#pubsub-numpat) | ➕ | | +| | [PUBSUB NUMSUB](../commands/analytics.md#pubsub-numsub) | ➕ | | +| | PUBSUB SHARDCHANNELS | ➖ | | +| | PUBSUB SHARDNUMSUB | ➖ | | +| | [PUNSUBSCRIBE](../commands/analytics.md#punsubscribe) | ➕ | | +| | [SUBSCRIBE](../commands/analytics.md#subscribe) | ➕ | | +| | [UNSUBSCRIBE](../commands/analytics.md#unsubscribe) | ➕ | | +| **SCRIPTING** | [EVAL](../commands/scripting-and-functions.md#eval) | ➕ | | +| | EVAL_RO | ➖ | | +| | [EVALSHA](../commands/scripting-and-functions.md#evalsha) | ➕ | | +| | EVALSHA_RO | ➖ | | +| | SCRIPT DEBUG | ➖ | | +| | [SCRIPT EXISTS](../commands/scripting-and-functions.md#script-exists) | ➕ | | +| | [SCRIPT FLUSH](../commands/scripting-and-functions.md#script-flush) | ➕ | | +| | SCRIPT HELP | ➖ | | +| | SCRIPT KILL | ➖ | | +| | [SCRIPT LOAD](../commands/scripting-and-functions.md#script-load) | ➕ | | +| **SERVER** | ACL | ➖ | | +| | BGREWRITEAOF | ➖ | | +| | [BGSAVE](../commands/checkpoint.md#bgsave) | ➖ | | +| | [COMMITAOF](../commands/server.md#commitaof) | ➖ | | +| | [CONFIG GET](../commands/server.md#config-get) | ➕ | | +| | CONFIG HELP | ➖ | | +| | CONFIG RESETSTAT | ➖ | | +| | CONFIG REWRITE | ➖ | | +| | [CONFIG SET](../commands/server.md#config-set) | ➖ | | +| | [DBSIZE](../commands/server.md#dbsize) | ➖ | | +| | [DEBUG](../commands/server.md#debug) | ➖ | Internal command | +| | [FLUSHALL](../commands/server.md#flushall) | ➖ | | +| | [FLUSHDB](../commands/server.md#flushdb) | ➕ | | +| | [LASTSAVE](../commands/checkpoint.md#lastsave) | ➖ | | +| | LOLWUT | ➖ | | +| | [MONITOR](../commands/server.md#monitor) | ➖ | | +| | PSYNC | ➖ | | +| | REPLCONF | ➖ | | +| | [REPLICAOF](../commands/server.md#replicaof) | ➖ | | +| | RESTORE-ASKING | ➖ | | +| | [ROLE](../commands/server.md#role) | ➖ | | +| | [SAVE](../commands/checkpoint.md#save) | ➖ | | +| | SHUTDOWN | ➖ | | +| | [SLAVEOF](../commands/server.md#slaveof) | ➖ | (Deprecated) | +| | [SWAPDB](../commands/server.md#swapdb) | ➖ | | +| | SYNC | ➖ | | +| | [TIME](../commands/server.md#time) | ➖ | | +| **SET** | [SADD](../commands/data-structures.md#sadd) | ➕ | | +| | [SCARD](../commands/data-structures.md#scard) | ➕ | | +| | [SDIFF](../commands/data-structures.md#sdiff) | ➕ | | +| | [SDIFFSTORE](../commands/data-structures.md#sdiffstore) | ➕ | | +| | [SINTER](../commands/data-structures.md#sinter) | ➕ | | +| | [SINTERSTORE](../commands/data-structures.md#sinterstore) | ➕ | | +| | [SINTERCARD](../commands/data-structures.md#sintercard) | ➕ | | +| | [SISMEMBER](../commands/data-structures.md#sismember) | ➕ | | +| | [SMEMBERS](../commands/data-structures.md#smembers) | ➕ | | +| | [SMISMEMBER](../commands/data-structures.md#smismember) | ➕ | | +| | [SMOVE](../commands/data-structures.md#smove) | ➕ | | +| | [SPOP](../commands/data-structures.md#spop) | ➕ | | +| | SPUBLISH | ➖ | | +| | [SRANDMEMBER](../commands/data-structures.md#srandmember) | ➕ | | +| | [SREM](../commands/data-structures.md#srem) | ➕ | | +| | [SSCAN](../commands/data-structures.md#sscan) | ➕ | | +| | SSUBSCRIBE | ➖ | | +| | [SUNION](../commands/data-structures.md#sunion) | ➕ | | +| | [SUNIONSTORE](../commands/data-structures.md#sunionstore) | ➕ | | +| | SUNSUBSCRIBE | ➖ | | +| **SORTED SET** | [BZMPOP](../commands/data-structures.md#bzmpop) | ➕ | | +| | [BZPOPMAX](../commands/data-structures.md#bzpopmax) | ➕ | | +| | [BZPOPMIN](../commands/data-structures.md#bzpopmin) | ➕ | | +| | [ZADD](../commands/data-structures.md#zadd) | ➕ | | +| | [ZCARD](../commands/data-structures.md#zcard) | ➕ | | +| | [ZCOUNT](../commands/data-structures.md#zcount) | ➕ | | +| | [ZDIFF](../commands/data-structures.md#zdiff) | ➕ | | +| | [ZDIFFSTORE](../commands/data-structures.md#zdiffstore) | ➕ | | +| | [ZINCRBY](../commands/data-structures.md#zincrby) | ➕ | | +| | [ZINTER](../commands/data-structures.md#zinter) | ➕ | | +| | [ZINTERCARD](../commands/data-structures.md#zintercard) | ➕ | | +| | [ZINTERSTORE](../commands/data-structures.md#zinterstore) | ➕ | | +| | [ZLEXCOUNT](../commands/data-structures.md#zlexcount) | ➕ | | +| | [ZMPOP](../commands/data-structures.md#zmpop) | ➕ | | +| | [ZMSCORE](../commands/data-structures.md#zmscore) | ➕ | | +| | [ZPOPMAX](../commands/data-structures.md#zpopmax) | ➕ | | +| | [ZPOPMIN](../commands/data-structures.md#zpopmin) | ➕ | | +| | [ZRANDMEMBER](../commands/data-structures.md#zrandmember) | ➕ | | +| | [ZRANGE](../commands/data-structures.md#zrange) | ➕ | | +| | [ZRANGEBYLEX](../commands/data-structures.md#zrangebylex) | ➕ | (Deprecated) | +| | [ZRANGEBYSCORE](../commands/data-structures.md#zrangebyscore) | ➕ | (Deprecated) | +| | [ZRANGESTORE](../commands/data-structures.md#zrangestore) | ➕ | | +| | [ZRANK](../commands/data-structures.md#zrank) | ➕ | | +| | [ZREM](../commands/data-structures.md#zrem) | ➕ | | +| | [ZREMRANGEBYLEX](../commands/data-structures.md#zremrangebylex) | ➕ | | +| | [ZREMRANGEBYRANK](../commands/data-structures.md#zremrangebyrank) | ➕ | | +| | [ZREMRANGEBYSCORE](../commands/data-structures.md#zremrangebyscore) | ➕ | | +| | [ZREVRANGE](../commands/data-structures.md#zrevrange) | ➕ | (Deprecated) | +| | [ZREVRANGEBYLEX](../commands/data-structures.md#zrevrangebylex) | ➕ | (Deprecated) | +| | [ZREVRANGEBYSCORE](../commands/data-structures.md#zrevrangebyscore) | ➕ | (Deprecated) | +| | [ZREVRANK](../commands/data-structures.md#zrevrank) | ➕ | | +| | [ZSCAN](../commands/data-structures.md#zscan) | ➕ | | +| | [ZSCORE](../commands/data-structures.md#zscore) | ➕ | | +| | [ZUNION](../commands/data-structures.md#zunion) | ➕ | | +| | [ZUNIONSTORE](../commands/data-structures.md#zunionstore) | ➕ | | +| **STRING** | [APPEND](../commands/raw-string.md#append) | ➕ | | +| | [DECR](../commands/raw-string.md#decr) | ➕ | | +| | [DECRBY](../commands/raw-string.md#decrby) | ➕ | | +| | [GET](../commands/raw-string.md#get) | ➕ | | +| | [GETDEL](../commands/raw-string.md#getdel) | ➕ | | +| | [GETEX](../commands/raw-string.md#getex) | ➕ | | +| | [GETRANGE](../commands/raw-string.md#getrange) | ➕ | | +| | [GETSET](../commands/raw-string.md#getset) | ➕ | | +| | [INCR](../commands/raw-string.md#incr) | ➕ | | +| | [INCRBY](../commands/raw-string.md#incrby) | ➕ | | +| | [INCRBYFLOAT](../commands/raw-string.md#incrbyfloat) | ➕ | | +| | [LCS](../commands/raw-string.md#lcs) | ➕ | | +| | [MGET](../commands/raw-string.md#mget) | ➕ | | +| | [MSET](../commands/raw-string.md#mset) | ➕ | | +| | [MSETNX](../commands/raw-string.md#msetnx) | ➕ | | +| | [PSETEX](../commands/raw-string.md#psetex) | ➕ | (Deprecated) | +| | [SET](../commands/raw-string.md#set) | ➕ | | +| | [SETEX](../commands/raw-string.md#setex) | ➕ | (Deprecated) | +| | [SETNX](../commands/raw-string.md#setnx) | ➕ | | +| | [SETRANGE](../commands/raw-string.md#setrange) | ➕ | | +| | [STRLEN](../commands/raw-string.md#strlen) | ➕ | | +| | [SUBSTR](../commands/raw-string.md#substr) | ➕ | (Deprecated) | + + +## Learn More + +- [Getting Started](./quickstart.md) +- [Cluster Configuration](./cluster-configuration.md) diff --git a/website/docs/azure/cluster-configuration.md b/website/docs/azure/cluster-configuration.md new file mode 100644 index 00000000000..2bace60c0bc --- /dev/null +++ b/website/docs/azure/cluster-configuration.md @@ -0,0 +1,191 @@ +--- +id: cluster-configuration +sidebar_label: Cluster Configuration +title: Cluster Configuration for Azure Cosmos DB Garnet Cache +--- + +# Cluster Configuration for Azure Cosmos DB Garnet Cache + +## Available Tiers + +Azure Cosmos DB Garnet Cache lets you choose the underlying [Azure Virtual Machine](https://learn.microsoft.com/azure/virtual-machines/sizes/overview) that your cache nodes will be provisioned on. The specs offered by cache nodes mirror the Azure virtual machine itself. Garnet doesn't limit the number of client connections that can be made on any node for any SKU. When choosing the right tier and SKU for your workload, consider that roughly 30% of memory on each node will be reserved for metadata and processing requests. Smaller SKUs in each tier are classified as [dev/test](#dev-test) while larger SKUs are designed for [production](#production) workloads. + +Every node also has a [Premium SSD Managed Disk](https://learn.microsoft.com/azure/virtual-machines/disks-types#premium-ssds) provisioned for [data persistence](./resiliency.md#data-persistence). The disk size is not configurable and represents 2x the total memory of each node. The Managed Disk SKU provisioned for each option is in the table below, and is priced at the [Azure Managed Disk price](https://azure.microsoft.com/pricing/details/managed-disks). + +The pricing model for cache nodes is instance-based and there are no licensing fees. For information about pricing for specific SKUs, reach out to [ManagedGarnet@service.microsoft.com](mailto:ManagedGarnet@service.microsoft.com). + +### General Purpose + +Balanced performance tier suitable for most caching workloads with a good balance of compute, memory, and network resources. + +- **Use Cases**: Balanced workloads, general caching, development and testing + +|SKU |vCPUs |Memory (GB) |Network bandwidth (MB/s) |Premium SSD Managed Disk |Cluster Type | +|----|------|------------|-------------------------|-------------------------|-------------| +|Standard_B2ls_v2 |2 |4 |6250 |P2 |Dev/ Test | +|Standard_B2als_v2|2 |4 |6250 |P2 |Dev/ Test | +|Standard_D2s_v5 |2 |8 |12500 |P3 |Dev/ Test | +|Standard_D4s_v5 |4 |16 |12500 |P4 |Dev/ Test | +|Standard_D8s_v5 |8 |32 |12500 |P6 |Production | +|Standard_D16s_v5 |16 |64 |12500 |P10 |Production | +|Standard_D32s_v5 |32 |128 |16000 |P15 |Production | +|Standard_D2as_v5 |2 |8 |12500 |P3 |Dev/ Test | +|Standard_D4as_v5 |4 |16 |12500 |P4 |Dev/ Test | +|Standard_D8as_v5 |8 |32 |12500 |P6 |Production | +|Standard_D16as_v5|16 |64 |12500 |P10 |Production | +|Standard_D32as_v5|32 |128 |16000 |P15 |Production | +|Standard_D2s_v4 |2 |8 |5000 |P3 |Dev/ Test | +|Standard_D4s_v4 |4 |16 |10000 |P4 |Dev/ Test | +|Standard_D8s_v4 |8 |32 |12500 |P6 |Production | +|Standard_D16s_v4 |16 |64 |12500 |P10 |Production | +|Standard_D32s_v4 |32 |128 |16000 |P15 |Production | + +### Memory Optimized + +High-memory tier designed for workloads requiring large in-memory datasets with optimized memory-to-CPU ratios. + +- **Use Cases**: Large datasets, gaming leaderboards, vector search workloads + +|SKU |vCPUs |Memory (GB) |Network bandwidth (MB/s) |Premium SSD Managed Disk | +|----|------|------------|-------------------------|-------------------------| +|Standard_E2s_v5 |2 |16 |12500 |P4 |Dev/ Test | +|Standard_E4s_v5 |4 |32 |12500 |P6 |Dev/ Test | +|Standard_E8s_v5 |8 |64 |12500 |P10 |Production | +|Standard_E16s_v5 |16 |128 |12500 |P15 |Production | +|Standard_E20s_v5 |20 |160 |12500 |P20 |Production | +|Standard_E32s_v5 |32 |256 |16000 |P20 |Production | +|Standard_E2as_v5 |2 |16 |12500 |P4 |Dev/ Test | +|Standard_E4as_v5 |4 |32 |12500 |P6 |Dev/ Test | +|Standard_E8as_v5 |8 |64 |12500 |P10 |Production | +|Standard_E16as_v5|16 |128 |12500 |P15 |Production | +|Standard_E20as_v5|20 |160 |12500 |P20 |Production | +|Standard_E32as_v5|32 |256 |16000 |P20 |Production | +|Standard_E2s_v4 |2 |16 |5000 |P4 |Dev/ Test | +|Standard_E4s_v4 |4 |32 |10000 |P6 |Dev/ Test | +|Standard_E8s_v4 |8 |64 |12500 |P10 |Production | +|Standard_E16s_v4 |16 |128 |12500 |P50 |Production | +|Standard_E20s_v4 |20 |160 |10000 |P20 |Production | +|Standard_E32s_v4 |32 |256 |16000 |P20 |Production | + + +### Cluster Types + +There are two cluster types to choose from which determine the SKUs available and the performance guarantees offered. + +#### Dev/ Test + +Development and testing SKUs are designed for non-production workloads with cost optimization and flexibility in mind. They are a good fit for feature testing and integration validation and are offered without SLAs. You may see lower throughput and higher latencies when using these SKUs. All features, including scaling out across shards, are available on Dev/ Test SKUs. + +#### Production + +Production SKUs are configured for high availability, performance, and reliability. They are a good fit for mission critical applications that need high throughput and consistent low latency. + + +## Scaling Options + +Azure Cosmos DB Garnet Cache provides flexible scaling options to meet your application's changing demands. Understanding when and how to scale your cache cluster is essential for maintaining optimal performance while controlling costs. + +### Choosing Your Scaling Strategy + +The decision between vertical and horizontal scaling depends on your specific workload characteristics and performance requirements. Vertical scaling offers simplicity and is ideal when you need more resources per node, while horizontal scaling provides better distribution and resilience for high-throughput scenarios. + +#### Vertical Scaling (Scale Up/Down) + +Vertical scaling involves changing the SKU of your existing cache nodes to increase or decrease their individual capacity. This approach maintains your current cluster topology while providing more or fewer resources per node. You can scale up SKU size in place within the same tier and generation. + +**When to Scale Up:** +Vertical scaling is most effective when your workload benefits from having more resources concentrated on fewer nodes. This approach reduces network overhead between nodes and simplifies data management. Consider scaling up when you need increased memory capacity for larger datasets or higher CPU performance for complex operations. + +Vector search workloads are particularly well-suited for vertical scaling because they benefit significantly from having the entire dataset available on a single node. Vector similarity searches require access to large portions of the dataset to compute accurate results, and distributing vectors across multiple nodes can introduce latency and complexity. By scaling up to larger SKUs, vector search applications can maintain all vectors in memory on a single node, enabling faster index traversal and more efficient similarity computations. + +**Benefits of Vertical Scaling:** +The primary advantage of vertical scaling is operational simplicity, as it maintains your existing cluster topology while providing enhanced performance. + +#### Horizontal Scaling (Scale Out/In) + +Horizontal scaling involves adding or removing nodes from your cluster to distribute load across more instances. You can scale horizontally by adding more shards to increase memory footprint and write throughput, or by increasing the replication factor to improve read throughput and availability. + +**When to Scale Out:** +Horizontal scaling becomes essential when your workload exceeds the capacity limits of individual nodes or when you need to distribute load for better performance. This approach is particularly effective for applications with high concurrent user loads or when you need to improve read performance through additional replica. + +**Scaling with Shards vs Replicas:** +Adding shards increases your total memory capacity and write throughput by distributing data across multiple primary nodes. Each shard handles a portion of your keyspace, allowing for parallel processing of operations. Alternatively, adding replicas primarily improves read throughput and provides better availability, as read operations can be distributed across multiple copies of your data. The [replication factor](./resiliency.md#replication) you choose directly impacts both performance and resiliency characteristics of your cluster. + +**Benefits of Horizontal Scaling:** +Horizontal scaling provides superior fault tolerance since the failure of individual nodes has less impact on overall system availability. This approach also offers better resource utilization efficiency and can handle virtually unlimited growth by continuously adding nodes. + +### How to Scale + +The **Settings > Cluster Explorer** page of the [Azure portal](https://aka.ms/garnet-portal) allows you to scale your cluster both vertically and horizontally. The Azure Cosmos DB Garnet Cache is in an expanded Private Preview and you must access the Azure portal through this link to manage your caches. + +![Cluster Explorer](../../static/img/azure/cluster-explorer.png) + +You can increase the shard count to scale in/ out, or change the SKU size to scale down/ up. Replication factor can only be configured during cluster provisioning and cannot be updated in place on existing clusters. + +![Scale Cluster](../../static/img/azure/scale-cluster.png) + +### Right-Sizing Your Deployment + +You can optimize the size of your Azure Cosmos DB Garnet Cache by monitoring and adjusting based on actual usage patterns. Starting with conservative estimates and scaling based on observed metrics typically provides the most cost-effective approach while ensuring performance requirements are met. + +We recommend beginning your deployment with a smaller tier that meets your initial requirements, then monitor key metrics such as memory utilization, CPU usage, and command processing rates. Regular review of these metrics allows you to make informed decisions about when and how to scale your deployment. Watch for sustained high memory utilization that might indicate a need for additional capacity, increased latency that could benefit from more processing power, or uneven load distribution that might be addressed through horizontal scaling. The key is to identify trends before they impact user experience, allowing for proactive scaling rather than reactive responses to performance issues. + + +## Regional availability + +Each Azure Cosmos DB Garnet Cache can be provisioned in a single region. It is available in multiple Azure regions worldwide, with ongoing expansion to additional regions. The availability of each SKU in a given region depends on the Azure Virtual Machine regional availability. You can verify which SKUs are available in each region [here](https://azure.microsoft.com/explore/global-infrastructure/products-by-region/table). + + Additionally, you can configure availability zones during provisioning in supported Azure regions where there is capacity for your chosen SKU. See the list of [Azure regions with availability zone support](https://learn.microsoft.com/azure/reliability/regions-list). + +| Geography | Region | Region Name | +|-----------|--------|-------------| +| **Americas** | canadacentral | Canada Central | +| | canadaeast | Canada East | +| | centralus | Central US | +| | eastus | East US | +| | eastus2 | East US 2 | +| | northcentralus | North Central US | +| | southcentralus | South Central US | +| | westcentralus | West Central US | +| | westus | West US | +| | westus2 | West US 2 | +| | westus3 | West US 3 | +| | brazilsouth | Brazil South | +| | brazilsoutheast | Brazil Southeast | +| **Europe** | northeurope | North Europe | +| | westeurope | West Europe | +| | francecentral | France Central | +| | germanynorth | Germany North | +| | germanywestcentral | Germany West Central | +| | italynorth | Italy North | +| | norwayeast | Norway East | +| | norwaywest | Norway West | +| | swedencentral | Sweden Central | +| | swedensouth | Sweden South | +| | switzerlandnorth | Switzerland North | +| | switzerlandwest | Switzerland West | +| | uksouth | UK South | +| | ukwest | UK West | +| **Africa** | southafricanorth | South Africa North | +| | southafricawest | South Africa West | +| **Middle East** | uaecentral | UAE Central | +| | uaenorth | UAE North | +| **Asia Pacific** | australiaeast | Australia East | +| | australiasoutheast | Australia Southeast | +| | centralindia | Central India | +| | southindia | South India | +| | westindia | West India | +| | eastasia | East Asia | +| | southeastasia | Southeast Asia | +| | japaneast | Japan East | +| | japanwest | Japan West | +| | koreacentral | Korea Central | +| | koreasouth | Korea South | + + +## Learn More + +- [Getting Started](./quickstart.md) +- [Resiliency](./resiliency.md) +- [Security](./security.md) +- [Monitoring](./monitoring.md) diff --git a/website/docs/azure/faq.md b/website/docs/azure/faq.md new file mode 100644 index 00000000000..44f37924bd9 --- /dev/null +++ b/website/docs/azure/faq.md @@ -0,0 +1,107 @@ +--- +id: faq +sidebar_label: FAQ +title: Frequently Asked Questions +--- + +# Frequently Asked Questions + +## General Questions + +### What is Azure Cosmos DB Garnet Cache? +Azure Cosmos DB Garnet Cache is a fully managed, high-performance caching service built on the Garnet remote cache-store from Microsoft Research. It provides Redis protocol compatibility with ultra-low latency and enterprise-grade security, scalability, and reliability. + +### How can I access the Preview? +Azure Cosmos DB Garnet Cache is currently in an expanded Private Preview. Please [sign up](https://aka.ms/cosmos-db-garnet-preview) to join the preview. + +### How is it different from self-hosted Garnet? +As a fully managed service, Azure Cosmos DB Garnet Cache handles infrastructure provisioning, scaling, patching, and monitoring automatically. Self-hosted Garnet requires you to manage the infrastructure, updates, and operations yourself. + +### Does it only work with Azure Cosmos DB? +No, Azure Cosmos DB Garnet Cache can be used to accelerate data access for any application, including but not limited to use with Azure Cosmos DB. It doesn't use the Azure Cosmos DB SDKs or have any automatic syncing. + +### Is it compatible with Redis clients? +Yes, Azure Cosmos DB Garnet Cache uses the Redis RESP protocol, making it compatible with existing Redis clients in all major programming languages without code changes. + +### What Redis version is supported? +Azure Cosmos DB Garnet Cache supports the RESP protocol and doesn't have full support for any specific Redis version. Visit the list of [supported Redis commands](./api-compatibility.md). + +### How is Azure Cosmos DB Garnet Cache priced? +Azure Cosmos DB Garnet Cache clusters are billed per instance per hour with no licensing fees. Each node will be billed for the chosen SKU plus an attached disk, used for [data persistence](./resiliency.md#data-persistence), with 4x the storage available for the SKU. Pricing per SKU is set at different rates than the underlying Azure VM and is subject to change between our extended Private Preview and Public Preview. + +For information about pricing for specific SKUs, reach out to [ManagedGarnet@service.microsoft.com](mailto:ManagedGarnet@service.microsoft.com). + + +## Performance and Scalability + +### What performance can I expect? +Latency is typically sub-millisecond and is around 3ms the 99th percentile. Performance and throughput varies by tier, key/ value size, and number of concurrent requests, among other factors. + +### Can I scale my cache? +Yes, you can [scale out](./cluster-configuration.md#horizontal-scaling-scale-outin) by adding shards, or [scale up](./cluster-configuration.md#vertical-scaling-scale-updown) by changing SKU size within a VM family and generation with no downtime. + +### How many connections are supported? +Garnet doesn't limit the number of client connections that can be made on any node for any SKU. In practice, connection limits vary by SKU. See the [virtual machine limits](https://learn.microsoft.com/azure/virtual-machines/sizes/overview#list-of-vm-size-families-by-type) corresponding to the [Azure Cosmos DB Garnet Cache SKU](./api-compatibility.md) you choose. + + +## Development and Integration + +### Which client libraries are supported? +All Redis client libraries are supported. Ensure you visit the list of [supported commands](./api-compatibility.md). Popular libraries by language include: +- **C#**: [StackExchange.Redis](https://github.com/StackExchange/StackExchange.Redis) +- **Java**: [Jedis](https://github.com/redis/jedis), [Redisson](https://github.com/redisson/redisson) +- **Python**: [redis-py](https://github.com/redis/redis-py) +- **Node.js**: [node_redis](https://github.com/redis/node-redis) +- **Go**: [go-redis](https://github.com/redis/go-redis) + +### Can I test it locally? +For local development, you can use the self-hosted Garnet server. + + +## Regional Availability + +### Which regions is it available in? +Azure Cosmos DB Garnet Cache is available in many Azure regions. Check our [supported regions list](./cluster-configuration.md#regional-availability). + +### Which regions support Availability Zones? +Azure Cosmos DB Garnet Cache can be configured with availability zones during provisioning in supported Azure regions where there is capacity for your chosen SKU. See the list of [Azure regions with availability zone support](https://learn.microsoft.com/azure/reliability/regions-list). + + +## Troubleshooting + +### My application can't connect to the cache +Check these common issues: +1. **VNet configuration**: Verify your client application is in the [same virtual network](./security.md#network-security) as your cache +2. **Authentication**: Verify you've configured [role based access control](./security.md#authentication-and-access-control), which is required for data plane access +3. **SSL/TLS**: Ensure your client supports [TLS](./security.md#data-encryption) + +### Cache performance is slower than expected +Common causes and solutions: +1. **Connection pooling**: Ensure proper connection pool configuration +2. **Hot keys**: Check for key access patterns causing bottlenecks +3. **Memory pressure**: [Monitor memory usage](./monitoring.md#high-memory-usage) and consider scaling up +4. **Network latency**: Test from the same region as your cache + +### I'm getting timeout errors +Troubleshooting steps: +1. **Check timeout settings**: Verify client timeout configuration +2. **Monitor CPU/memory**: [High resource usage](./monitoring.md#high-cpu-usage) can cause timeouts +4. **Network issues**: Test network connectivity between client and cache + + +## Getting Help + +### Where can I get technical support? +- [**Documentation**](./overview.md): For conceptual guidance and tutorials +- **Azure Support**: Create support tickets for technical issues +- **Community**: Stack Overflow and Azure forums + +### How do I report bugs or request features? +- **Azure Support** for bugs and critical issues +- [**Feedback Form**](https://aka.ms/garnet-feedback) for feature requests or suggestions + + +## Next Steps + +- [Garnet Overview](./overview.md) +- [Getting Started](./quickstart.md) diff --git a/website/docs/azure/monitoring.md b/website/docs/azure/monitoring.md new file mode 100644 index 00000000000..7d4fd323ca7 --- /dev/null +++ b/website/docs/azure/monitoring.md @@ -0,0 +1,134 @@ +--- +id: monitoring +sidebar_label: Monitoring +title: Monitoring Azure Cosmos DB Garnet Cache +--- + +# Monitoring Azure Cosmos DB Garnet Cache + +Azure Cosmos DB Garnet Cache provides comprehensive monitoring capabilities through Azure Monitor, enabling you to track performance, troubleshoot issues, and optimize your cache deployment. + + +## Azure Monitor + +### Metrics + +Azure Cosmos DB Garnet Cache automatically collects metrics and sends them to Azure Monitor. Most metrics have **Min**, **Max**, and **Average** aggregations as well as the ability to split by **Node** for detailed insights into cluster performance. + +![Azure Monitor Metrics](../../static/img/azure/metrics.png) + +#### Garnet Client Metrics + +| Metric | Additional Information | +|--------|------------------------| +| Connected Clients | | + +#### Query Performance Metrics + +| Metric | Additional Information | +|--------|------------------------| +| Command Process Rate | The total number of commands processed per second. | +| Query Latency P99 | The P99 latency of processing per network call received server-side, considering only non-admin requests. Reported in microseconds. | +| Query Latency Mean| The mean latency of processing per network call received server-side, considering only non-admin requests. Reported in microseconds. | +| Read Command Process Rate | The number of read commands processed. | +| Write Command Process Rate | The number of write commands processed. | + +#### Garnet Store Metrics + +| Metric | Additional Information | +|--------|------------------------| +| Index Size | The size of the index in the main store in bytes. | +| Log Size| The size of the log in the main store in bytes. | +| Main Store Size | Total size of the main store including index, log, and overflow in bytes. | +| Read Cache Size | Size of read cache in the main store in bytes. | + +#### System Metrics + +| Metric | Additional Information | +|--------|------------------------| +| Average CPU Usage Active | Average active CPU usage across all CPUs. | +| CPU Usage Active | | +| Memory Utilization| | +| Network Received Bytes | | +| Network Received Packets | | +| Network Transmitted Bytes | | +| Network Transmitted Packets | | + +### Activity log + +The [Azure Monitor activity log](https://learn.microsoft.com/azure/azure-monitor/platform/activity-log) contains entries for control plane events from Azure Cosmos DB Garnet Cache resources. It includes information like when a cache cluster is created, when scaling operations occur, or when RBAC permissions are granted. Use the activity log to review or audit administrative actions on your Azure Cosmos DB Garnet Cache resources, or create alerts to be proactively notified when control plane events occur. + + +## Troubleshooting Common Issues + +### High CPU Usage + +High CPU usage can indicate various performance bottlenecks in your cluster. Use the **Average CPU Usage Active** and **CPU Usage Active** metrics to identify and resolve CPU-related issues. + +#### Symptoms +- **Average CPU Usage Active** consistently above 80% +- **CPU Usage Active** showing spikes during peak usage +- Increased **Query Latency P99** and **Query Latency Mean** values +- Degraded **Command Process Rate** performance + +#### Resolution Steps +1. **Analyze Command Patterns**: Review **Command Process Rate** trends to identify peak usage periods causing high CPU load +2. **Monitor Node Distribution**: Use the Node split feature to identify if specific nodes are experiencing higher CPU usage than others +3. **Scale Compute Resources**: Consider increasing the replication factor if **Read Command Process Rate** is high, or increase the shard count if **Write Command Process Rate** is high + +### High Memory Usage + +Memory utilization issues can lead to performance degradation and potential data eviction. Monitor **Memory Utilization** alongside store-specific metrics to maintain optimal performance. + +#### Symptoms +- **Memory Utilization** approaching or exceeding 85% +- **Main Store Size** growing rapidly or unexpectedly +- **Index Size** or **Log Size** consuming excessive memory +- Increased cache misses or eviction events + +#### Resolution Steps +1. **Analyze Memory Distribution**: Review **Main Store Size**, **Index Size**, **Log Size**, and **Read Cache Size** to identify which component is consuming the most memory +2. **Implement TTL Strategies**: Set appropriate time-to-live values for cached data to ensure automatic cleanup +3. **Optimize Data Structures**: Use more memory-efficient data types where appropriate +4. **Scale Memory Resources**: Consider increasing the shard count for more memory, or scale-up to a higher SKU + +### Connection Issues + +Connection problems can manifest through various network and client metrics. Use **Connected Clients**, **Network Received/Transmitted Bytes**, and **Network Received/Transmitted Packets** to diagnose connectivity issues. + +#### Symptoms +- **Connected Clients** count dropping unexpectedly or remaining at zero +- **Network Received Bytes** or **Network Transmitted Bytes** showing irregular patterns +- Client applications reporting connection timeouts or failures +- Inconsistent **Command Process Rate** despite steady application load + +#### Resolution Steps +1. **Verify Network Connectivity**: Test basic network connectivity from client applications to the cache endpoint +2. **Review Authentication**: Verify that authentication credentials are valid and have appropriate permissions +3. **Monitor Connection Patterns**: Analyze **Connected Clients** trends to identify if connection issues are intermittent or persistent +4. **Review Client Configuration**: Ensure client applications are using appropriate connection timeout and retry settings + +### Performance Degradation + +Performance issues can affect various aspects of your cache operations. Use latency and throughput metrics to identify and resolve performance bottlenecks. + +#### Symptoms +- **Query Latency P99** exceeding SLA thresholds (consistently above 3ms) +- **Query Latency Mean** showing consistent increases +- **Command Process Rate** declining despite steady or increased demand +- **Read Command Process Rate** or **Write Command Process Rate** not meeting expected throughput + +#### Resolution Steps +1. **Analyze Latency Patterns**: Compare **Query Latency P99** and **Query Latency Mean** to identify if performance issues are persistent +2. **Check Resource Utilization**: Review **CPU Usage Active** and **Memory Utilization** to identify resource constraints +3. **Evaluate Network Performance**: Check **Network Received/Transmitted Bytes** and **Packets** for signs of network congestion +4. **Review Command Distribution**: Analyze **Read Command Process Rate** vs **Write Command Process Rate** to understand workload characteristics +5. **Identify Node Hotspots**: Use Node-level metrics to detect if specific nodes are experiencing disproportionate load +6. **Scale Appropriately**: Consider upgrading to higher performance tiers or adding more nodes based on the specific bottleneck identified + + +## Learn More + +- [Getting Started](./quickstart.md) +- [Cluster Configuration](./cluster-configuration.md) +- [Security](./security.md) diff --git a/website/docs/azure/overview.md b/website/docs/azure/overview.md new file mode 100644 index 00000000000..ae476d9d249 --- /dev/null +++ b/website/docs/azure/overview.md @@ -0,0 +1,95 @@ +--- +id: overview +sidebar_label: Overview +title: Azure Cosmos DB Garnet Cache Overview +--- + +# What is Azure Cosmos DB Garnet Cache (preview)? + +Azure Cosmos DB Garnet Cache is a fully managed, high-performance caching service built on the Garnet remote cache-store from Microsoft Research. It provides enterprise-grade reliability, security, and scalability without the operational overhead of managing your own cache infrastructure. With consistent low latency and high throughput even with many client connections, Azure Cosmos DB Garnet Cache accelerates data access and leads to cost savings for large apps and services. + +The Azure Cosmos DB Garnet Cache is currently in an expanded Private Preview. Please [sign up here](https://aka.ms/cosmos-db-garnet-preview). + +## Key Benefits + +Azure Cosmos DB Garnet Cache is a cloud-native caching service that combines the performance advantages of Garnet with Azure's managed service capabilities. It offers: + +- **Ultra-Low Latency**: Sub-millisecond latency with 3ms at the 99th percentile. +- **Performance**: Supports millions of operations per second with linear scalability across multiple nodes. +- **Cost Optimization**: Per node pricing with multiple performance tiers and no licensing fees. +- **Fully Managed**: No infrastructure to manage, patch, or maintain while delivering enterprise features like high availability and data persistence. + +## Common Use Cases + +Azure Cosmos DB Garnet Cache is ideal for distributed caching across multiple application instances and a wide range of caching scenarios: + +### Application Cache +Cache frequently accessed database queries, API responses, and computed results to reduce backend load and improve response times. + +### Session Store +Store user session data, shopping carts, and user preferences. + +### Gaming & Leaderboards +Leverage sorted sets for leaderboards, player rankings, and game state management. + +### Vector Search & AI Applications +Store and search high-dimensional vectors for recommendation engines, similarity search, and AI-powered features using VectorSet data structures with DiskANN indexing. + +### Content Delivery +Cache static content, configuration data, and frequently accessed information close to your users for faster delivery. + +### Rate Limiting & Counters +Implement distributed rate limiting, usage quotas, and real-time counters across multiple application instances. + +### Pub/Sub Messaging +Enable real-time communication between applications with Redis-compatible publish/subscribe messaging patterns for event-driven architectures, notifications, and live updates. + +## Features + +| Feature | Support | +|-----------------------|----------------------| +| **Latency** | 3ms P99, < 1ms P50 | +| **Size** | 5TB+ with clustering | +| [**Scaling**](./cluster-configuration.md#scaling-options) | Horizontal scaling with sharding and replication or scale up SKU size | +| [**Availability**](./resiliency.md#high-availability) | 99.99%* | +| [**Data persistence**](./resiliency.md#data-persistence) | Append only file (AOF) checkpointing | +| **Vector search** | VectorSet support with DiskANN indexing | +| [**Authentication**](./security.md#authentication-and-access-control) | Microsoft Entra ID RBAC | +| [**Network isolation**](./security.md#network-security) | Virtual network support with no public internet access | +| [**Encryption**](./security.md#encryption-at-rest) | At rest and in transit with TLS | +| [**Monitoring**](./monitoring.md) | Azure Monitor Metrics | +| **Updates** | Automatic updates with zero downtime | + +*This is an estimated value. Actual availability varies depending on configuration. See [high availability](./resiliency.md#high-availability) for more information. + +### Available Tiers + +Azure Cosmos DB Garnet Cache offers two performance tiers to match your workload requirements. An overview of single-node specs is below for each tier based on the [available SKUs](./cluster-configuration.md#available-tiers). Each cluster can be scaled to have one or more nodes of the same SKU determined by the shard count and replication factor configured. This allows for custom cache sizes up to 5TB+ that match your specific workload needs. + +#### General Purpose +Recommended for balanced workloads, general caching, development and testing. Single-node specs ranging from: +- **Memory**: 4 GB - 128 GB +- **vCPUs**: 2-32 cores +- **Network**: Up to 16 Gbps + +#### Memory Optimized +Recommended for in-memory databases, large datasets, gaming leaderboards, vector search workloads. Single-node specs ranging from: +- **Memory**: 16 GB - 256 GB +- **vCPUs**: 2-32 cores +- **Network**: Up to 16 Gbps + + +## Compatible with Redis clients + +Just like self-hosted Garnet, Azure Cosmos DB Garnet Cache uses the Redis RESP protocol, making it compatible with existing Redis clients and tools. You can migrate from Redis or other cache solutions with minimal code changes. Azure Cosmos DB Garnet Cache supports a subset of the self-hosted Garnet commands. See the full list of [supported commands](./api-compatibility.md). + +## Getting Started + +Ready to get started? Check out our [quick start guide](./quickstart.md) to create your first Azure Cosmos DB Garnet Cache instance in minutes. + +## Learn More + +- [Cluster Configuration](./cluster-configuration.md) +- [Resiliency](./resiliency.md) +- [Security](./security.md) +- [Monitoring](./monitoring.md) diff --git a/website/docs/azure/quickstart.md b/website/docs/azure/quickstart.md new file mode 100644 index 00000000000..6bc35f9cec1 --- /dev/null +++ b/website/docs/azure/quickstart.md @@ -0,0 +1,187 @@ +--- +id: quickstart +sidebar_label: Quick Start +title: Create an Azure Cosmos DB Garnet Cache +--- + +# Quick Start: Create Your First Azure Cosmos DB Garnet Cache + +This guide will walk you through creating and connecting to your first Azure Cosmos DB Garnet Cache. + +## Prerequisites + +- An active Azure subscription +- Confirmed registration to the expanded Private Preview. If your subscription isn't already enrolled, [sign up](https://aka.ms/cosmos-db-garnet-preview). +- Access to the Azure portal and the [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest) +- Required role assignment permissions. + - For successful provisioning, you must have **Microsoft.Authorization/roleAssignments/write** permissions at either the *Subscription* or *Resource Group* scope. Example built-in roles are [Owner](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles/privileged#owner) and [User Access Administrator](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#user-access-administrator), or you can use a custom role with this permission. + +## Step 1: Create an Azure Cosmos DB Garnet Cache + +During provisioning, you must either create a new virtual network for your cache or use an existing one. All application access to the cache must be from within this virtual network. + +1. Sign in to the [Azure portal](https://aka.ms/garnet-portal). The Azure Cosmos DB Garnet Cache is in an expanded Private Preview and you must access the Azure portal through this link to create caches. +2. Click **Create a resource** and search for **Azure Cosmos DB Garnet Cache**. +3. Select **Azure Cosmos DB Garnet Cache** and click **Create**. +4. Fill in the required information: + - **Subscription**: Select your Azure subscription. This subscription must be enrolled in the expanded Private Preview. For access, [sign up here](https://aka.ms/cosmos-db-garnet-preview). + - **Resource Group**: Create new or select existing. + - **Region**: Select the region closest to your application. See the list of [supported regions](./cluster-configuration.md#regional-availability). + - **Cluster Name**: Choose a unique name for your cache. + - **Virtual Network**: Select *Create a new virtual network* then enter your network name, and optionally, customize the address space and subnet. If you're using an existing virtual network, ensure the proper [outbound network rules](./security.md#required-outbound-network-rules) are configured. + - **Assign Roles**: Leave this option checked for successful provisioning. During provisioning, the *Network Contributor* role will be assigned to *Azure Cosmos DB* on both the virtual network and subnet. Ensure you have **Microsoft.Authorization/roleAssignments/write** permissions at either the *Subscription* or *Resource Group* scope for this operation to succeed. + - **System Assigned Identity**: Optional. This will create a managed identity for the cache. + - **Availability Zone**: Optional. Select to enable availability zones, meaning nodes will be distributed across zones. See [availability zone support](./resiliency.md#multi-availability-zone-deployment). + - **Cluster Type**: Either Dev/Test or Production. This determines the SKUs that will be available and the performance characteristics to expect from your cache. See [cluster configuration](./cluster-configuration.md#cluster-types). + - **SKU Size**: Once cluster type is selected, you can select your SKU. All nodes in the cluster will be provisioned on a Virtual Machine of this SKU. See [SKU details](./cluster-configuration.md#available-tiers). + - **Shard Count**: The number of shards in your cluster, corresponding to the number of primary nodes. The memory footprint of your cache is determined by the total memory across all primary nodes. Learn when to [scale out vs. scale up](./cluster-configuration.md#choosing-your-scaling-strategy). + - **Replication Factor**: Not currently configurable. The default replication factor is 2x meaning there are 2 nodes per shard, one primary and one replica. + - **Total Node Count**: To modify, adjust the *Shard Count*. The total number of nodes in the cluster is calculated by *Shard Count x Replication Factor*. +5. Click **Review + Create** and then **Create** + + +## Step 2: Configure Data Access with RBAC + +Azure Cosmos DB Garnet Cache uses Azure RBAC to grant access to supported Redis commands. Assigning Microsoft Entra ID RBAC roles is required to use data plane operations. No roles are assigned by default, including to the resource creator. There are several built-in roles, see [data plane built-in roles](./security.md#authentication-and-access-control) to choose the most appropriate role assignments for each user. Role assignments can take 5-10 minutes to become effective. + +Roles can be assigned at various scopes, in both examples below we will assign the **Garnet Data Contributor** role at the Azure Cosmos DB Garnet Cache resource scope. To assign Azure roles, you must have **Microsoft.Authorization/roleAssignments/write permissions**, such as [Owner](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles/privileged#owner) or [User Access Administrator](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#user-access-administrator). + +### Set up in the Azure Portal +You can assign data access roles for the Azure Cosmos DB Garnet Cache clusters using the **Access control (IAM)** page. + +1. Sign in to the [Azure portal](https://aka.ms/garnet-portal). The Azure Cosmos DB Garnet Cache is in an expanded Private Preview and you must access the Azure portal through this link to see your caches. +2. Navigate to the **Access control (IAM)** page of your Azure Cosmos DB Garnet Cache resource and select **Add > Add role assignment**. + +![Configure Azure Cosmos DB Garnet Cache RBAC](../../static/img/azure/configure-rbac.png) + +3. In the **Add role assignment** page, enter **garnet** in the search box. +4. Select the role you would like to assign and then select **Next**. In this example, we’re adding the **Garnet Data Contributor** role. See details for all [built-in roles](./security.md#built-in-roles). + +![Add Azure Cosmos DB Garnet Cache RBAC roles](../../static/img/azure/add-role-assignment.png) + +5. On the **Members** page, select **User, group or service principal** to assign the selected role to one or more Microsoft Entra users, groups or service principals (applications). Select **Managed identity** to assign the selected role to one or more managed identities. + +![Add Azure Cosmos DB Garnet Cache RBAC members](../../static/img/azure/add-rbac-members.png) + +6. Click **Select members** to search for users, groups, service principals, or managed identities for role assignment. +7. After adding all security principles, select **Review + assign**. + + +### Set up using the Azure CLI + +You can assign data access roles for the Azure Cosmos DB Garnet Cache clusters using the Azure CLI. + +1. Sign in the the Azure CLI. + +```bash +az login +``` + +2. Find your user Object ID. + +```bash +# Get your own Object ID +az ad signed-in-user show --query id -o tsv + +# Or get another user's Object ID +az ad user show --id "user@company.com" --query id -o tsv +``` + +2. Assign RBAC Roles. This example uses the **Garnet Data Contributor** role. See details for all [built-in roles](./security.md#built-in-roles). + +```bash +# Set your parameters +userObjectId="your-object-id-from-step-1" +subscriptionId="your-subscription-id" +resourceGroup="your-garnet-cache-resource-group" +cacheName="your-garnet-cache-name" + +# Assign Garnet Data Contributor to yourself +az role assignment create \ + --assignee $userObjectId \ + --role "Garnet Data Contributor" \ + --scope "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.DocumentDB/garnetClusters/$cacheName" +``` + +## Step 3: Set Up Network Access + +Azure Cosmos DB Garnet Cache does not provide public IP addresses or DNS and can't be accessed from the public internet. Cache nodes are provisioned on the virtual network provided during cluster creation. They are accessible via the internal IP addresses from the same virtual network. Your client machine must use the same network. + +### Create a New Virtual Machine + +You can create a new virtual machine in the same virtual network as your Azure Cosmos DB Garnet cache. +- [Create a Linux VM](https://learn.microsoft.com/azure/virtual-machines/linux/quick-create-portal?tabs=ubuntu) +- [Create a Windows VM](https://learn.microsoft.com/azure/virtual-machines/windows/quick-create-portal) + +### Use Existing Infrastructure + +You can use an existing VM or host machine in the same virtual network as your Azure Cosmos DB Garnet Cache. If your VM is in a different virtual network, [set up virtual network peering](https://learn.microsoft.com/azure/virtual-network/tutorial-connect-virtual-networks?tabs=portal). Ensure that the IP address spaces of the two virtual networks do not overlap. Once peering is established successfully, the client application in one virtual network can access the cache endpoints on the other network using their local IP addresses. + +## Step 4: Connect and Test + +Now you're ready to connect to your Azure Cosmos DB Garnet Cache! + +1. Find your user Object ID. Save this for a future step. + +```bash +# Get your own Object ID +az login +az ad signed-in-user show --query id -o tsv +``` + +2. Get an access token, and save this for a future step. Access tokens have an expiry window. Regenerate the token if it has expired. You can learn more about access tokens [here](https://docs.azure.cn/entra/identity-platform/access-tokens#token-lifetime). + +```bash +az account get-access-token --scope https://cosmos.azure.com/.default --query accessToken -o tsv +``` + +3. Find the IP address of your cache nodes. Redis clients can connect to one of the node IP addresses and get the list of all replicas and ports automatically. + 1. Sign in to the [Azure portal](https://aka.ms/garnet-portal). The Azure Cosmos DB Garnet Cache is in an expanded Private Preview and you must access the Azure portal through this link to see your caches. + 2. Navigate to the **Settings > Cluster Explorer** page of your Azure Cosmos DB Garnet Cache resource. + 3. Find the IP addresses of all nodes in your cluster. Save them for a future step. + + ![Find Azure Cosmos DB Garnet Cache node IP addresses](../../static/img/azure/cluster-ip-addresses.png) + +4. Connect using a Redis client. You can use any Redis client of your choice to connect to the cluster. Connecting with the [Redis CLI](https://redis.io/docs/latest/develop/tools/cli/) is optional, and it provides a quick way to test data access for your cache. + 1. [Install the Redis CLI](https://redis.io/docs/latest/develop/tools/cli/#install-redis-cli) on your machine. If you're using a Linux machine, run the following command. + + ```bash + sudo apt-get install redis-tools + ``` + + 2. Connect to your cluster using the Redis CLI. + + ```bash + # Replace with your actual values + export USER_OBJECT_ID="your-object-id-from-step-1" + export ACCESS_TOKEN="your-access-token-from-step-2" + export GARNET_HOST="10.0.0.5" # Any IP from step 3 + export GARNET_PORT="6379" + + # Connect + redis-cli -h $GARNET_HOST -p $GARNET_PORT --tls -c --user $USER_OBJECT_ID --pass $ACCESS_TOKEN + ``` + + 3. Test basic operations using the Redis CLI. Once connected, try these commands. Explore the list of [supported commands](./api-compatibility.md). + ```redis + # Test connection + PING + + # Set and get values + SET mykey "Hello Garnet Cache!" + GET mykey + + # Explore cluster topology + CLUSTER NODES + CLUSTER INFO + + # Test data types + HSET user:1 name "John" age 30 + HGET user:1 name + ``` + +## Learn More + +- [Monitoring](./monitoring.md) +- [Security](./security.md) +- [Cluster Configuration](./cluster-configuration.md) diff --git a/website/docs/azure/resiliency.md b/website/docs/azure/resiliency.md new file mode 100644 index 00000000000..ce28e20c500 --- /dev/null +++ b/website/docs/azure/resiliency.md @@ -0,0 +1,74 @@ +--- +id: resiliency +sidebar_label: Resiliency +title: Resiliency in Azure Cosmos DB Garnet Cache +--- + +# Resiliency in Azure Cosmos DB Garnet Cache + +Azure Cosmos DB Garnet Cache is designed for high availability and resilience, providing enterprise-grade uptime, data persistence, and automatic recovery capabilities. The service offers multiple layers of protection to ensure your cache remains available and your data is preserved even during infrastructure failures, maintenance events, or unexpected outages. + +## Architecture Overview + +Azure Cosmos DB Garnet Cache implements a distributed architecture with built-in redundancy and data persistence, deployed in a single Azure region. + +- **Primary-Replica Architecture**: Each cache cluster consists of one or more shards with primary node and replica nodes +- **Asynchronous Replication**: Data is asynchronously replicated from primaries +- **AOF Persistence**: Append-Only File snapshots provide durable data storage to disk +- **Automatic Failover**: Fast failover for minimal service interruption +- **Automatic Recovery**: Failed nodes recover using AOF snapshots and replication + +![Architecture](../../static/img/azure/architecture.png) + +### Data Distribution and Sharding + +Azure Cosmos DB Garnet Cache uses a consistent hashing approach to distribute data across the cluster for optimal availability and load distribution. The cluster's key space is divided into 16,384 hash slots, with each slot owned by a single primary node. Any given key maps to exactly one slot, ensuring predictable data placement and efficient retrieval. + +When you have multiple shards in your cluster, hash slots are evenly distributed across all primary nodes. This distribution ensures that data and load are balanced across the cluster, preventing hotspots and maximizing resource utilization. Replica nodes serve read-only requests for the keys hashing to slots owned by their corresponding primary nodes, enabling read scaling while maintaining data consistency. + +This sharding strategy provides several resiliency benefits: if a primary node fails, only the keys in its assigned slots are affected, while the rest of the cluster continues operating normally. Automatic slot reassignment ensures that when nodes become unavailable, their hash slots can be redistributed to healthy nodes, maintaining cluster availability even during node failures. + + +## High Availability + +### Replication + +Azure Cosmos DB Garnet Cache supports configurable replication factors to balance availability requirements with cost. You can configure replication during cluster provisioning and it can't be changed on existing clusters. + +| Configuration | Replication Factor | Total Nodes Per Shard | Use Cases | +|---------------|--------------------|-----------------------|-----------| +| **No Replication** | 1x | 1, primary only | Development, testing, cost-optimized production | +| **High Availability** | 2x | 2, one replica per primary | Mission-critical applications | +| **Optimized Read Performance** | 3x-5x* | 3-5, two to four replicas per primary | Mission-critical applications requiring high read throughput | + +*Reach out to [ManagedGarnet@service.microsoft.com](mailto:ManagedGarnet@service.microsoft.com) if you need a higher replication factor. + +The replication process is as follows + +1. **Write Operations**: All writes go to the primary node first +2. **Asynchronous Replication**: The write is acknowledged once written in the primary and is asynchronously replicated to all replicas in the shard +3. **Consistency**: Eventual consistency between replicas +4. **Read Distribution**: Read operations can be distributed across primary and replica nodes + +### Automatic Failovers + +A failover can be either planned, such as system updates or management operations, or it can be unplanned, such as hardware failure or unexpected outages. The Azure Cosmos DB Garnet Cache automatically handles failovers for you and will promote a replica to primary after detecting one of these events. + +### Multi Availability Zone Deployment + +Azure Cosmos DB Garnet Cache can be configured with availability zones during provisioning in [supported Azure regions](./cluster-configuration.md#regional-availability) where there is capacity for your chosen SKU. See the list of [Azure regions with availability zone support](https://learn.microsoft.com/azure/reliability/regions-list). + +If enabled, nodes are automatically distributed across multiple availability zones within the region. Primary and replica nodes are not guaranteed to be in different availability zones. If a zone goes down and all replicas for a given shard are unhealthy, the hash slots assigned to it will automatically be reassigned to healthy shards. + +## Data Persistence + +Azure Cosmos DB Garnet Cache uses append only file (AOF) persistence to ensure data durability. Every write operation is appended to a persistent log file stored on an attached locally redundant [Premium Managed Disk](https://learn.microsoft.com/azure/virtual-machines/disks-types#premium-ssds). Checkpoints are stored every second. The disk size is automatically provisioned for each node based on 2x the total amount of memory for the SKU. See the [disks provisioned for each SKU](./cluster-configuration.md#available-tiers). + +Data on nodes is restored from the latest data checkpoint upon restart, including from automatic failovers. It is possible to experience data loss after a failover for the portion of data that hasn't been replicated or wasn't included in the latest checkpoint. + +## Learn More + +- [Getting Started](./quickstart.md) +- [Cluster Configuration](./cluster-configuration.md) +- [Security](./security.md) +- [Monitoring](./monitoring.md) diff --git a/website/docs/azure/security.md b/website/docs/azure/security.md new file mode 100644 index 00000000000..fadd30e779e --- /dev/null +++ b/website/docs/azure/security.md @@ -0,0 +1,77 @@ +--- +id: security +sidebar_label: Security +title: Secure your Azure Cosmos DB Garnet Cache +--- + +# Secure your Azure Cosmos DB Garnet Cache + +Azure Cosmos DB Garnet Cache provides enterprise-grade security features to protect your data. This guide covers the security capabilities and best practices for securing your cache. + + +## Network Security + +Azure Cosmos DB Garnet Cache does not provide public IP addresses or DNS, meaning it can't be accessed from the public internet. Cache nodes are provisioned on the virtual network provided during cluster creation. They are accessible via the internal IP addresses from the same VNet. + +There are the 2 options to connect to the cache: +1. Deploy the clients connecting to the cache on the same virtual network with either the same subnet, or a different one. The Redis clients can use the internal IP address of the cache instances to connect. Learn how to [find your internal IP addresses](./quickstart.md#step-4-connect-and-test). +2. If the client applications are deployed in a separate virtual network, then you can use [virtual network peering](https://learn.microsoft.com/azure/virtual-network/virtual-network-peering-overview) to connect the two. Follow the steps in this [tutorial](https://learn.microsoft.com/azure/virtual-network/tutorial-connect-virtual-networks?tabs=portal). Ensure that the IP address space of the two virtual networks does not overlap. Once peering is established successfully, the client application in one virtual network can access the cache endpoints on the other network using their local IP addresses. + +### Required outbound network rules + +If you use Azure Firewall to restrict outbound access from the existing subnet, we highly recommend that you use [virtual network service tags](https://learn.microsoft.com/azure/virtual-network/service-tags-overview). The tags in the following table are required to make the Azure Cosmos DB Garnet Cache function properly. + +|Destination service tag |Protocol |Port |Use | +|------------------------|---------|-----|----| +|Storage |HTTPS |443 |Required for secure communication between the nodes and Azure Storage for Control Plane communication and configuration. | +|AzureKeyVault |HTTPS |443 |Required for secure communication between the nodes and Azure Key Vault. Certificates and keys are used to secure communication inside the cache. | +|EventHub |HTTPS |443 |Required to forward logs to Azure. | +|AzureMonitor |HTTPS |443 |Required to forward metrics to Azure. | +|AzureActiveDirectory |HTTPS |443 |Required for Microsoft Entra authentication. | +|AzureResourceManager |HTTPS |443 |Required to gather information about and manage Garnet nodes (for example, reboot). | +|AzureFrontDoor.Firstparty |HTTPS |443 |Required for logging operations. | +|GuestAndHybridManagement |HTTPS |443 |Required to gather information about and manage Garnet nodes (for example, reboot). | +|ApiManagement |HTTPS |443 |Required to gather information about and manage Garnet nodes (for example, reboot). | + +In addition to the tags table, you need to add the following address prefixes because a service tag doesn't exist for the relevant service: +- 104.40.0.0/13 +- 13.104.0.0/14 +- 40.64.0.0/10 + + +## Authentication and Access Control + +Azure Cosmos DB Garnet Cache uses Azure RBAC to secure your data by granting permissions for supported Redis commands. Microsoft Entra ID RBAC roles define fine-grained permissions and are required to use data plane operations. No roles are assigned by default, including to the resource creator. You can assign roles to users, groups, service principals or managed identities for data access. + +### Built-in Roles + +There are several built-in roles to help you manage data access. Learn how to [assign roles](./quickstart.md#step-2-configure-data-access-with-rbac) using the Azure portal or Azure CLI. + +| Role | Use Case | Access Level | +|------|----------|--------------| +| `Garnet Data Reader` | Read-only applications, monitoring | GET, EXISTS etc. | +| `Garnet Data Contributor` | Most applications | Read/write string, hash, set, sorted set | +| `Garnet Data Owner` | Admin access, full control | All operations including destructive ones | +| `Garnet Script Data Contributor` | Script execution and management | All scripting | +| `Garnet PubSub Data Reader` | Reading pub/sub messages | Read access to pub/sub channels | +| `Garnet PubSub Data Contributor` | All pub/sub messaging | Publish/subscribe operations | + +To see detailed permissions associated with each role, navigate to the **Access control (IAM)** page of your Garnet Cache resource in the [Azure portal](https://aka.ms/garnet-portal). The Azure Cosmos DB Garnet Cache is in an expanded Private Preview and you must access the Azure portal through this link to manage your caches. The **Roles** tab has all available roles. Search for **garnet** and view the details for each role. + +![Built-in Roles](../../static/img/azure/built-in-roles.png) + +See a detailed list of allowed commands for each role under **Permissions > DataActions**. + +![Garnet Data Contributor permissions](../../static/img/azure/garnet-data-contributor.png) + + +## Data Encryption + +Azure Cosmos DB Garnet Cache implements comprehensive data protection measures to ensure your data remains secure both at rest and in transit, giving you end-to-end encryption. TLS 1.2 or higher and node-to-node encryption are enforced. + + +## Learn More + +- [Cluster Configuration](./cluster-configuration.md) +- [Resiliency](./resiliency.md) +- [Monitoring](./monitoring.md) diff --git a/website/docs/welcome/intro.md b/website/docs/welcome/intro.md index c86bb245be0..8accd9c8980 100644 --- a/website/docs/welcome/intro.md +++ b/website/docs/welcome/intro.md @@ -71,6 +71,34 @@ storage layer is called Tsavorite, which supports for various backing storage de local SSD drives and Azure Storage. It has devices optimized for Windows and Linux as well. Finally, Garnet supports TLS for secure connections. +## Deployment Options + +### Azure Cosmos DB Garnet Cache (preview) +For production workloads, **Azure Cosmos DB Garnet Cache** provides a fully managed experience with enterprise-grade security, +automatic scaling, global distribution, and comprehensive monitoring. This managed service eliminates infrastructure management +overhead while delivering the performance advantages of Garnet. It's currently in an expanded Private Preview. + +**Key benefits:** +- Fully managed infrastructure and operations +- High availability and seamless scaling +- Enterprise security and compliance +- Integration with Azure monitoring and diagnostics + +[Get started with Azure Cosmos DB Garnet Cache →](../azure/overview.md) + +### Self-Hosted Garnet +For development, research, or custom deployments, the open-source Garnet server provides complete control over your +infrastructure. Garnet is a research project from Microsoft Research that has been deployed by several +first-party and platform teams at Microsoft for many months. + +**Key benefits:** +- Complete control over infrastructure +- Customizable configurations and extensions +- Cost-effective for development and testing +- Direct access to latest research features + +[Learn about self-hosted Garnet →](../getting-started/build.md) + Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by Microsoft is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and Microsoft. diff --git a/website/sidebars.js b/website/sidebars.js index ba17286c718..d17c996a281 100644 --- a/website/sidebars.js +++ b/website/sidebars.js @@ -41,6 +41,7 @@ const sidebars = { {type: 'category', label: 'Diagnostics', items: ["logger", "metrics"]}, "research", */ + {type: 'category', label: 'Azure', items: ["azure/overview", "azure/quickstart", "azure/api-compatibility", "azure/cluster-configuration", "azure/resiliency", "azure/security", "azure/monitoring", "azure/faq"]}, {type: 'category', label: 'Research', items: ["research/papers"]}, {type: 'category', label: 'Other Links', items: [ {type: 'link', label: 'Releases', href: 'https://github.com/microsoft/garnet/releases'}, diff --git a/website/static/img/azure/add-rbac-members.png b/website/static/img/azure/add-rbac-members.png new file mode 100644 index 00000000000..aed11ae8516 Binary files /dev/null and b/website/static/img/azure/add-rbac-members.png differ diff --git a/website/static/img/azure/add-role-assignment.png b/website/static/img/azure/add-role-assignment.png new file mode 100644 index 00000000000..e3a74f796ef Binary files /dev/null and b/website/static/img/azure/add-role-assignment.png differ diff --git a/website/static/img/azure/architecture.png b/website/static/img/azure/architecture.png new file mode 100644 index 00000000000..9b11f711e48 Binary files /dev/null and b/website/static/img/azure/architecture.png differ diff --git a/website/static/img/azure/built-in-roles.png b/website/static/img/azure/built-in-roles.png new file mode 100644 index 00000000000..ac5afd03eb5 Binary files /dev/null and b/website/static/img/azure/built-in-roles.png differ diff --git a/website/static/img/azure/cluster-explorer.png b/website/static/img/azure/cluster-explorer.png new file mode 100644 index 00000000000..93e3a6b91d0 Binary files /dev/null and b/website/static/img/azure/cluster-explorer.png differ diff --git a/website/static/img/azure/cluster-ip-addresses.png b/website/static/img/azure/cluster-ip-addresses.png new file mode 100644 index 00000000000..e6259a38cfe Binary files /dev/null and b/website/static/img/azure/cluster-ip-addresses.png differ diff --git a/website/static/img/azure/configure-rbac.png b/website/static/img/azure/configure-rbac.png new file mode 100644 index 00000000000..9ab67d66a97 Binary files /dev/null and b/website/static/img/azure/configure-rbac.png differ diff --git a/website/static/img/azure/garnet-data-contributor.png b/website/static/img/azure/garnet-data-contributor.png new file mode 100644 index 00000000000..55d46265655 Binary files /dev/null and b/website/static/img/azure/garnet-data-contributor.png differ diff --git a/website/static/img/azure/metrics.png b/website/static/img/azure/metrics.png new file mode 100644 index 00000000000..12ca3727018 Binary files /dev/null and b/website/static/img/azure/metrics.png differ diff --git a/website/static/img/azure/scale-cluster.png b/website/static/img/azure/scale-cluster.png new file mode 100644 index 00000000000..0c213c54cdb Binary files /dev/null and b/website/static/img/azure/scale-cluster.png differ