mirror of
https://github.com/cgrates/cgrates.git
synced 2026-02-24 08:38:45 +05:00
Remove Balancer
This commit is contained in:
alin104n
@@ -5,7 +5,7 @@ The general steps to get CGRateS operational are:
|
||||
|
||||
#. Create CSV files containing the initial data for CGRateS.
|
||||
#. Load the data in the databases using the Loader application.
|
||||
#. Start the a Balancer or a Rater. If Balancer is used, start one or more Raters serving that Balancer.
|
||||
#. Start the SessionManager talking to your VoIP Switch or directly make API calls to the Balancer/Rater.
|
||||
#. Make API calls to the Balancer/Rater or just let the SessionManager do the work.
|
||||
#. Start a Rater.
|
||||
#. Start the SessionManager talking to your VoIP Switch or directly make API calls to the Rater.
|
||||
#. Make API calls to the Rater or just let the SessionManager do the work.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
API Calls
|
||||
=========
|
||||
The general API usage of the CGRateS involves creating a CallDescriptor structure sending it to the balancer via JSON/GOB RPC and getting a response from the balancer in form of a CallCost structure or a numeric value for requested information.
|
||||
The general API usage of the CGRateS involves creating a CallDescriptor structure sending it to the rater via JSON/GOB RPC and getting a response from the rater in form of a CallCost structure or a numeric value for requested information.
|
||||
|
||||
CallDescriptor structure
|
||||
------------------------
|
||||
@@ -48,11 +48,11 @@ Cost
|
||||
ConnectFee
|
||||
The requested connection cost
|
||||
Timespans
|
||||
The timespans in witch the initial TimeStart-TimeEnd was split in for cost determination with all pricing and cost information attached.
|
||||
The timespans in witch the initial TimeStart-TimeEnd was split in for cost determination with all pricing and cost information attached.
|
||||
|
||||
As stated before the balancer (or the rater directly) can be accesed via json rpc.
|
||||
As stated before the rater can be accesed via json rpc.
|
||||
|
||||
The smallest python snippet to access the CGRateS balancer is this:
|
||||
The smallest python snippet to access the CGRateS rater is this:
|
||||
|
||||
::
|
||||
|
||||
@@ -76,7 +76,7 @@ In the stress folder you can find a better example of python client using a clas
|
||||
rpc =JSONClient(("127.0.0.1", 2001))
|
||||
result = rpc.call("Responder.Get", cd)
|
||||
print result
|
||||
|
||||
|
||||
Call API
|
||||
--------
|
||||
GetCost
|
||||
@@ -102,7 +102,7 @@ DebitSeconds
|
||||
The amount filed has to be filled in call descriptor.
|
||||
|
||||
GetMaxSessionTime
|
||||
Returns the approximate max allowed session for user budget. It will try the max amount received in the call descriptor
|
||||
Returns the approximate max allowed session for user budget. It will try the max amount received in the call descriptor
|
||||
and will decrease it by 10% for nine times. So if the user has little credit it will still allow 10% of the initial amount.
|
||||
If the user has no credit then it will return 0.
|
||||
|
||||
@@ -336,7 +336,7 @@ SetAcount
|
||||
Type string // <*prepaid|*postpaid>
|
||||
ActionTimingsId string
|
||||
}
|
||||
|
||||
|
||||
Example
|
||||
AddAccount(attr \*AttrAddAccount, reply \*string)
|
||||
|
||||
|
||||
@@ -72,24 +72,7 @@ it will start on demand **one or more** service(s), outlined below.
|
||||
.. hint:: # cgr-engine -config_dir=/etc/cgrates
|
||||
|
||||
|
||||
2.1.1. Balancer service
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
*Optional* component, used as proxy/balancer to a pool of RAL workers.
|
||||
The RALs will register their availability to the Balancer thus implementing **dynamic HA functionality**.
|
||||
**HA functionality** can be archived also *without* the **Balancer**.
|
||||
|
||||
- Communicates via:
|
||||
- RPC
|
||||
- internal/in-process *within the same running* **cgr-engine** process.
|
||||
|
||||
- Operates with the following CGRateS database(s): ::
|
||||
|
||||
- none
|
||||
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"balancer": {...}``
|
||||
|
||||
2.1.2. RALs service
|
||||
2.1.1. RALs service
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
Responsible with the following tasks:
|
||||
|
||||
@@ -110,7 +93,7 @@ Responsible with the following tasks:
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"rals": {...}``
|
||||
|
||||
2.1.3. Scheduler service
|
||||
2.1.2. Scheduler service
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Used to execute periodic/scheduled tasks.
|
||||
|
||||
@@ -124,7 +107,7 @@ Used to execute periodic/scheduled tasks.
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"scheduler": {...}``
|
||||
|
||||
2.1.4. SessionManager service
|
||||
2.1.3. SessionManager service
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Responsible with call control on the Telecommunication Switch side. Operates in two different modes (per call or globally):
|
||||
|
||||
@@ -164,7 +147,7 @@ Right now there are **five** session manager types.
|
||||
- ``"sm_asterisk": {...}``
|
||||
- ``"sm_generic": {...}``
|
||||
|
||||
2.1.5. DiameterAgent service
|
||||
2.1.4. DiameterAgent service
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Responsible for the communication with Diameter server via diameter protocol.
|
||||
Despite the name it is a flexible **Diameter Server**.
|
||||
@@ -180,7 +163,7 @@ Despite the name it is a flexible **Diameter Server**.
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"diameter_agent": {...}``
|
||||
|
||||
2.1.6. CDRS service
|
||||
2.1.5. CDRS service
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
Centralized CDR server and CDR (raw or rated) **replicator**.
|
||||
|
||||
@@ -196,7 +179,7 @@ Centralized CDR server and CDR (raw or rated) **replicator**.
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"cdrs": {...}``
|
||||
|
||||
2.1.7. CDRStats service
|
||||
2.1.6. CDRStats service
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Computes real-time CDR stats. Capable with real-time fraud detection and mitigation with actions triggered.
|
||||
|
||||
@@ -211,7 +194,7 @@ Computes real-time CDR stats. Capable with real-time fraud detection and mitigat
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"cdrstats": {...}``
|
||||
|
||||
2.1.8. CDRC service
|
||||
2.1.7. CDRC service
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
Gathers offline CDRs and post them to CDR Server - (CDRS component)
|
||||
|
||||
@@ -226,7 +209,7 @@ Gathers offline CDRs and post them to CDR Server - (CDRS component)
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"cdrc": {...}``
|
||||
|
||||
2.1.9. History service
|
||||
2.1.8. History service
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
Archives rate changes in human readable JSON format using **GIT**.
|
||||
|
||||
@@ -241,7 +224,7 @@ Archives rate changes in human readable JSON format using **GIT**.
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"historys": {...}``
|
||||
|
||||
2.1.10. Aliases service
|
||||
2.1.9. Aliases service
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Generic purpose **aliasing** system.
|
||||
|
||||
@@ -261,7 +244,7 @@ Possible applications:
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"aliases": {...}``
|
||||
|
||||
2.1.11. User service
|
||||
2.1.10. User service
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
Generic purpose **user** system to maintain user profiles (LDAP similarity).
|
||||
|
||||
@@ -276,7 +259,7 @@ Generic purpose **user** system to maintain user profiles (LDAP similarity).
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"users": {...}``
|
||||
|
||||
2.1.12. PubSub service
|
||||
2.1.11. PubSub service
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
PubSub service used to expose internal events to interested external components (eg: balance ops)
|
||||
|
||||
@@ -292,7 +275,7 @@ PubSub service used to expose internal events to interested external components
|
||||
- ``"pubsubs": {...}``
|
||||
|
||||
|
||||
2.1.13. Resource Limiter service
|
||||
2.1.12. Resource Limiter service
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Resource Limiter service used to limit resources during authorization (eg: maximum calls per destination for an account)
|
||||
|
||||
@@ -307,7 +290,7 @@ Resource Limiter service used to limit resources during authorization (eg: maxim
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"rls": {...}``
|
||||
|
||||
2.1.14. APIER RPC service
|
||||
2.1.13. APIER RPC service
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
RPC service used to expose external access towards internal components.
|
||||
|
||||
@@ -316,7 +299,7 @@ RPC service used to expose external access towards internal components.
|
||||
- JSON over HTTP
|
||||
- JSON over WebSocket
|
||||
|
||||
2.1.15. Cdre
|
||||
2.1.14. Cdre
|
||||
~~~~~~~~~~~~
|
||||
Component to retrieve rated CDRs from internal CDRs database.
|
||||
|
||||
@@ -329,7 +312,7 @@ Component to retrieve rated CDRs from internal CDRs database.
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"cdre": {...}``
|
||||
|
||||
2.1.16. Mailer
|
||||
2.1.15. Mailer
|
||||
~~~~~~~~~~~~~~
|
||||
TBD
|
||||
|
||||
@@ -340,7 +323,7 @@ TBD
|
||||
- Config section in the CGRateS configuration file:
|
||||
- ``"mailer": {...}``
|
||||
|
||||
2.1.17. Suretax
|
||||
2.1.16. Suretax
|
||||
~~~~~~~~~~~~~~~
|
||||
TBD
|
||||
|
||||
@@ -446,7 +429,7 @@ Can be used to:
|
||||
|
||||
2.3. cgr-console
|
||||
----------------
|
||||
Command line tool used to interface with the RALs (and/or Balancer) service. Able to execute **sub-commands**.
|
||||
Command line tool used to interface with the RALs service. Able to execute **sub-commands**.
|
||||
|
||||
::
|
||||
|
||||
|
||||
@@ -3,11 +3,11 @@
|
||||
|
||||
`CGRateS`_ is a *very fast* and *easily scalable* **(charging, rating, accounting, lcr, mediation, billing, authorization)** *ENGINE* targeted especially for ISPs and Telecom Operators.
|
||||
|
||||
It is written in `Go`_ programming language and is accessible from any programming language via JSON RPC.
|
||||
It is written in `Go`_ programming language and is accessible from any programming language via JSON RPC.
|
||||
The code is well documented (**go doc** compliant `API docs`_) and heavily tested. (also **1300+** tests are part of the build system).
|
||||
|
||||
After testing various databases like `Kyoto Cabinet`_, `Apache Cassandra`_, `Redis`_ and `MongoDB`_,
|
||||
the project focused on **Redis** as it delivers the best trade-off between speed, configuration and scalability.
|
||||
After testing various databases like `Kyoto Cabinet`_, `Apache Cassandra`_, `Redis`_ and `MongoDB`_,
|
||||
the project focused on **Redis** as it delivers the best trade-off between speed, configuration and scalability.
|
||||
|
||||
.. important:: `MongoDB`_ **full** support is now added.
|
||||
|
||||
@@ -26,17 +26,17 @@ To better understand the CGRateS architecture, below are some logical configurat
|
||||
.. note:: **RALs** - is a CGRateS component and stands for RatingAccountingLCR service.
|
||||
|
||||
.. image:: images/Simple.png
|
||||
This scenario fits most of the simple installations. The **Balancer** can be left out and the **RALs** can be queried directly.
|
||||
This scenario fits most of the simple installations.
|
||||
|
||||
.. image:: images/Normal.png
|
||||
While the network grows more **RALs** can be thrown into the stack to offer more requests per seconds workload.
|
||||
While the network grows more **RALs** can be thrown into the stack to offer more requests per seconds workload.
|
||||
This implies the usage of the **Balancer** to distribute the requests to the **RALs** running on the *different machines*.
|
||||
|
||||
.. image:: images/Normal_ha.png
|
||||
Without Balancer using HA (broadcast) ....
|
||||
Without Balancer using HA (broadcast) ....
|
||||
|
||||
.. image:: images/Complicated.png
|
||||
Of course more **SessionManagers** can serve *multiple Telecom Switches* and all of them are connected to the same **Balancer**.
|
||||
Of course more **SessionManagers** can serve *multiple Telecom Switches* and all of them are connected to the same **Balancer**.
|
||||
|
||||
.. image:: images/Complicated_ha.png
|
||||
Without Balancer using HA (broadcast) ....
|
||||
@@ -51,10 +51,9 @@ Without Balancer using HA (broadcast) ....
|
||||
- Using most modern programming concepts like multiprocessor support, asynchronous code execution within microthreads.
|
||||
- Built-in data caching system per call duration.
|
||||
- In-Memory database with persistence over restarts.
|
||||
- Use of Balancer assures High-Availability of RALs as well as increase of processing performance where that is required.
|
||||
- Use of Linux enterprise ready tools to assure High-Availability of the Balancer where that is required (*Supervise* for Application level availability and *LinuxHA* for Host level availability).
|
||||
- High-Availability of main components is now part of CGRateS core.
|
||||
|
||||
- High-Availability of main components is now part of CGRateS core.
|
||||
|
||||
- Modular architecture
|
||||
- Easy to enhance functionality by writing custom session managers or mediators.
|
||||
- Flexible API accessible via both **Gob** (Golang specific, increased performance) or **JSON** (platform independent, universally accessible).
|
||||
|
||||
@@ -2,33 +2,32 @@
|
||||
|
||||
1. Overview
|
||||
===========
|
||||
Starting as a pure **billing engine**, CGRateS has evolved over the years into a reliable **real-time charging framework** able to accommodate various business cases in a *generic way*.
|
||||
Meant to be pluggable into existing billing infrastructure and as non-intrusive as possible,
|
||||
Starting as a pure **billing engine**, CGRateS has evolved over the years into a reliable **real-time charging framework** able to accommodate various business cases in a *generic way*.
|
||||
Meant to be pluggable into existing billing infrastructure and as non-intrusive as possible,
|
||||
CGRateS passes the decisions about logic flow to system administrators and incorporates as less as possible business logic.
|
||||
|
||||
Being an *"engine style"* the project focuses on providing best ratio between **functionality** (
|
||||
over 15 daemons/services implemented,
|
||||
Multi-tenancy,
|
||||
derived charging - eg: chaining of the business resellers,
|
||||
account bundles,
|
||||
LCR,
|
||||
CDRStatS,
|
||||
Diameter Server,
|
||||
A-Number rating,
|
||||
over 15 daemons/services implemented,
|
||||
Multi-tenancy,
|
||||
derived charging - eg: chaining of the business resellers,
|
||||
account bundles,
|
||||
LCR,
|
||||
CDRStatS,
|
||||
Diameter Server,
|
||||
A-Number rating,
|
||||
built-in High-Availability support
|
||||
agile in developing new features
|
||||
)
|
||||
agile in developing new features
|
||||
)
|
||||
and **performance** (
|
||||
dedicated benchmark tool,
|
||||
asynchronous request processing,
|
||||
own transactional cache with majority of handled data loaded on start or reloaded during runtime,
|
||||
built-in balancer
|
||||
)
|
||||
dedicated benchmark tool,
|
||||
asynchronous request processing,
|
||||
own transactional cache with majority of handled data loaded on start or reloaded during runtime,
|
||||
)
|
||||
however not loosing focus of **quality** (over 1300 tests part of the build environment).
|
||||
|
||||
Modular and flexible, CGRateS provides APIs over a variety of simultaneously accessible communication interfaces:
|
||||
- **In-process** : optimal when there is no need to split services over different processes.
|
||||
- **JSON over TCP** : most preferred due to its simplicity and readability.
|
||||
- **JSON over TCP** : most preferred due to its simplicity and readability.
|
||||
- **JSON over HTTP** : popular due to fast interoperability development.
|
||||
- **JSON over Websockets** : useful where 2 ways interaction over same TCP socket is required.
|
||||
- **GOB over TCP** : slightly faster than JSON one but only accessible for the moment out of Go (`<https://golang.org/>`_).
|
||||
@@ -46,7 +45,7 @@ CGRateS is capable of four charging modes
|
||||
- Session authorization via events
|
||||
- Charging done at the end of the session out of CDR received
|
||||
- Advantage: less CPU intensive due to less events processed
|
||||
- Disadvantage: as balance updates happen only at the end of the session there can be costs discrepancy in case of multiple sessions out of same account
|
||||
- Disadvantage: as balance updates happen only at the end of the session there can be costs discrepancy in case of multiple sessions out of same account
|
||||
(including going on negative balance).
|
||||
|
||||
- \*postpaid
|
||||
@@ -67,16 +66,16 @@ CGRateS is capable of four charging modes
|
||||
- Primary component, offering the most functionality out of the subsystems.
|
||||
- Computes replies based on static list of "rules" defined in TariffPlan.
|
||||
|
||||
2.1.1. Rater
|
||||
2.1.1. Rater
|
||||
~~~~~~~~~~~~
|
||||
- Defines the performance of the system as a whole being the "heart" component
|
||||
- Support for multiple TypeOfRecord (**\*voice**, **\*data**, **\*sms**, **\*generic**)
|
||||
- Time based calculations (activation time in the future/rate-destination timely coupled) with granular time definitions (year, month, month day, weekday, time in seconds)
|
||||
- Compressed destination prefixes, helping on faster destination match as well as memory consumption
|
||||
- Advanced Rating capabilities:
|
||||
ConnectFee (charged at beginning of the session);
|
||||
RateUnit (automatic divider for the cost);
|
||||
RateIncrement (increase verbosity of the charging interval);
|
||||
- Advanced Rating capabilities:
|
||||
ConnectFee (charged at beginning of the session);
|
||||
RateUnit (automatic divider for the cost);
|
||||
RateIncrement (increase verbosity of the charging interval);
|
||||
Grouped interval rating inside the call duration (charging each second within a session independently)
|
||||
- Per destination rounding: control number of decimals displayed in costs, decide rounding methods (**\*up**, **\*down**, **\*middle**)
|
||||
- Control of the MaxSessionCost with decision on action taken on threshold hit (**\*free**, **\*disconnect**)
|
||||
@@ -127,7 +126,7 @@ CGRateS is capable of four charging modes
|
||||
- In-memory / performance oriented
|
||||
- Unlimited StatQueues computing the same CDR event
|
||||
- Flexible queue configuration (QueueLength, TimeWindow, Metrics, CDR field filters)
|
||||
- Fraud detection with automatic mitigation through action triggers
|
||||
- Fraud detection with automatic mitigation through action triggers
|
||||
|
||||
2.4. AliaseS
|
||||
------------
|
||||
@@ -205,7 +204,7 @@ CGRateS is capable of four charging modes
|
||||
3. CGRateS Peripherals
|
||||
======================
|
||||
Packaged together due to common usage
|
||||
|
||||
|
||||
3.1. cgr-engine
|
||||
---------------
|
||||
- Configured via .json files, encorporating CGRateS subsystems mentioned above
|
||||
@@ -241,10 +240,10 @@ Packaged together due to common usage
|
||||
4.1. Fraud detection within Accounting:
|
||||
---------------------------------------
|
||||
- Events are happening in real-time, being available during updates (eg: every n seconds of a session).
|
||||
- Thresholds set by the administrator are reacting by calling a set of predefined actions **synchronously**
|
||||
- Thresholds set by the administrator are reacting by calling a set of predefined actions **synchronously**
|
||||
(with the advantage of having account in locked state, eg. no other events are possible until decision is made) or **asynchronously** (unlocking the accounts faster)
|
||||
- Two types of thresholds can be set
|
||||
- **min-/max-balance** monitoring balance values
|
||||
- Two types of thresholds can be set
|
||||
- **min-/max-balance** monitoring balance values
|
||||
- **min-/max-usage** counters (eg: amount of minutes to specific destination).
|
||||
- Middle session control (sessions can be disconnected as fraud is detected
|
||||
|
||||
|
||||
Reference in New Issue
Block a user